L'un des défis auxquels Ethereum est confronté est que, par défaut, l'expansion et la complexité de tout protocole de blockchain augmentent avec le temps. Cela se produit à deux endroits :
Données historiques : Toute transaction effectuée et tout compte créé à tout moment de l'histoire doivent être stockés de manière permanente par tous les clients et téléchargés par tout nouveau client, afin d'être complètement synchronisés avec le réseau. Cela entraînera une charge client et un temps de synchronisation qui augmentent avec le temps, même si la capacité de la chaîne reste inchangée.
Fonctionnalité de protocole : ajouter de nouvelles fonctionnalités est beaucoup plus facile que de supprimer d'anciennes fonctionnalités, ce qui entraîne une complexité du code croissante avec le temps.
Pour que l'Ethereum puisse se maintenir à long terme, nous devons exercer une forte contre-pression sur ces deux tendances, réduisant la complexité et l'expansion au fil du temps. Mais en même temps, nous devons préserver l'une des propriétés clés qui rendent la blockchain géniale : la pérennité. Vous pouvez mettre un NFT, une lettre d'amour dans les données d'un appel de transaction, ou un contrat intelligent contenant 1 million de dollars sur la chaîne, entrer dans une grotte pendant dix ans, et en sortir pour découvrir qu'il est toujours là, attendant que vous le lisiez et interagissiez. Pour que les DApps puissent se décentraliser complètement en toute confiance et supprimer les clés de mise à jour, ils doivent être sûrs que leurs dépendances ne seront pas mises à jour de manière à les perturber - en particulier L1 lui-même.
Il est absolument possible d'équilibrer ces deux besoins, de minimiser ou d'inverser le surpoids, la complexité et le déclin tout en maintenant la continuité. Les organismes vivants peuvent le faire : bien que la plupart des organismes vieillissent avec le temps, quelques chanceux ne le font pas. Même les systèmes sociaux peuvent avoir une très longue durée de vie. Dans certains cas, Ethereum a déjà réussi : la preuve de travail a disparu, l'opcode SELFDESTRUCT a principalement disparu, et les nœuds de la chaîne de balise ont stocké des données anciennes pendant jusqu'à six mois. Trouver ce chemin pour Ethereum de manière plus générale et se diriger vers un résultat final stable à long terme est le défi ultime pour la scalabilité à long terme d'Ethereum, la durabilité technique et même la sécurité.
The Purge : objectif principal.
Réduire les exigences de stockage des clients en diminuant ou en éliminant la nécessité pour chaque nœud de stocker de manière permanente tous les historiques, voire l'état final.
Réduire la complexité du protocole en éliminant les fonctionnalités inutiles.
Table des matières :
Historique d'expiration（历史记录到期）
Expiration de l'état（状态到期）
Nettoyage des fonctionnalités
Expiration de l'historique
résout quel problème ?
À la date de rédaction de cet article, un nœud Ethereum entièrement synchronisé nécessite environ 1,1 To d'espace disque pour exécuter le client, ainsi que plusieurs centaines de Go d'espace disque pour le client de consensus. La grande majorité de ces données est historique : il s'agit de données concernant les blocs historiques, les transactions et les reçus, dont la plupart ont plusieurs années. Cela signifie que même si la limite de Gas n'augmente pas du tout, la taille des nœuds continuera d'augmenter de plusieurs centaines de Go chaque année.
Qu'est-ce que c'est et comment ça fonctionne ?
Une caractéristique clé de simplification du problème de stockage historique est que, comme chaque bloc est lié au bloc précédent par un lien de hachage (et d'autres structures), il suffit d'atteindre un consensus sur le bloc actuel pour parvenir à un consensus sur l'historique. Tant que le réseau parvient à un consensus sur le dernier bloc, n'importe quel bloc, transaction ou état historique (solde de compte, nombre aléatoire, code, stockage) peut être fourni par un participant unique ainsi que par une preuve Merkle, et cette preuve permet à quiconque d'en vérifier la validité. Le consensus est un modèle de confiance N/2-of-N, tandis que l'historique est un modèle de confiance N-of-N.
Cela nous offre de nombreuses options sur la façon de stocker l'historique. Un choix naturel est un réseau où chaque nœud ne stocke qu'une petite partie des données. C'est ainsi que fonctionnent les réseaux de graines depuis des décennies : bien que le réseau stocke et distribue des millions de fichiers, chaque participant ne stocke et ne distribue que quelques fichiers parmi eux. Peut-être contre-intuitivement, cette méthode ne réduit même pas nécessairement la robustesse des données. Si nous pouvons rendre l'exécution des nœuds plus économique, nous pouvons établir un réseau de 100 000 nœuds, où chaque nœud stocke aléatoirement 10 % de l'historique, alors chaque donnée sera copiée 10 000 fois - exactement le même facteur de copie que dans un réseau de 10 000 nœuds, où chaque nœud stocke tout.
Aujourd'hui, Ethereum commence à se libérer du modèle où tous les nœuds stockent de manière permanente toute l'historique. Les blocs de consensus (c'est-à-dire la partie liée au consensus de preuve d'enjeu) ne stockent que pendant environ 6 mois. Les blobs ne sont stockés que pendant environ 18 jours. L'EIP-4444 vise à introduire une période de stockage d'un an pour les blocs historiques et les reçus. L'objectif à long terme est d'établir une période unifiée (probablement d'environ 18 jours) durant laquelle chaque nœud est responsable du stockage de tout, puis de créer un réseau pair à pair composé de nœuds Ethereum, qui stockera les anciennes données de manière distribuée.
Les codes d'effacement peuvent être utilisés pour améliorer la robustesse tout en maintenant le même facteur de réplication. En fait, le Blob a déjà été doté de codes d'effacement pour soutenir l'échantillonnage de la disponibilité des données. La solution la plus simple consistera probablement à réutiliser ces codes d'effacement et à intégrer également les données d'exécution et de consensus dans le blob.
a quels liens avec les recherches existantes ?
EIP-4444；
Torrents et EIP-4444；
réseau de porte
Portail réseau et EIP-4444 ;
Stockage et récupération distribués des objets SSZ dans Portal ;
Comment augmenter la limite de gaz (Paradigm).
que faut-il encore faire, quels compromis faut-il envisager ?
Le travail principal restant consiste à construire et à intégrer une solution distribuée concrète pour stocker les historiques ------ au moins l’historique des exécutions, mais finalement aussi le consensus et les blobs. La solution la plus simple est (i) d'introduire simplement des bibliothèques torrent existantes, ainsi que (ii) une solution native Ethereum appelée réseau Portal. Une fois l'un ou l'autre introduit, nous pouvons ouvrir l'EIP-4444. L'EIP-4444 lui-même ne nécessite pas de hard fork, mais il nécessite une nouvelle version du protocole réseau. Par conséquent, il est utile de l'activer pour tous les clients en même temps, sinon il existe un risque que les clients échouent en raison de la connexion à d'autres nœuds dans l'attente de télécharger l'historique complet mais ne l'obtiennent en réalité pas.
Les principaux compromis concernent nos efforts pour fournir des données historiques "anciennes". La solution la plus simple consiste à arrêter demain de stocker des histoires anciennes et à s'appuyer sur les nœuds d'archivage existants et divers fournisseurs centralisés pour la réplication. C'est facile, mais cela affaiblit la position d'Ethereum en tant que lieu d'enregistrement permanent. Une approche plus difficile mais plus sûre consiste d'abord à construire et à intégrer un réseau torrent pour stocker l'historique de manière distribuée. Ici, "combien nous nous efforçons" a deux dimensions :
Comment nous efforçons-nous de garantir que le plus grand ensemble de nœuds stocke effectivement toutes les données ?
Quelle est la profondeur de l'intégration de l'historique de stockage dans le protocole ?
Une méthode d'extrême paranoïa pour (1) impliquerait une preuve de garde : en réalité, cela exigerait que chaque validateur de preuve d'enjeu stocke une certaine proportion d'historique et vérifie régulièrement de manière cryptographique s'il le fait. Une méthode plus douce consisterait à établir une norme volontaire pour le pourcentage d'historique stocké par chaque client.
Pour (2), l'implémentation de base concerne uniquement le travail déjà accompli aujourd'hui : le Portal a déjà stocké un fichier ERA contenant toute l'histoire d'Ethereum. Une implémentation plus approfondie impliquerait de le connecter effectivement au processus de synchronisation, de sorte que si quelqu'un souhaite synchroniser un nœud de stockage d'historique complet ou un nœud d'archivage, même s'il n'y a pas d'autres nœuds d'archivage en ligne, il peut le faire en se synchronisant directement à partir du réseau Portal.
Comment interagit-il avec les autres parties de la feuille de route ?
Si nous voulons rendre l'exécution ou le démarrage des nœuds extrêmement facile, alors réduire les exigences de stockage historique peut être considéré comme plus important que la statelessness : sur les 1,1 To requis par le nœud, environ 300 Go sont des états, le reste, soit environ 800 Go, est devenu historique. Ce n'est qu'en réalisant la statelessness et l'EIP-4444 que nous pourrons atteindre la vision de faire fonctionner un nœud Ethereum sur une montre intelligente et de le configurer en quelques minutes.
La limitation du stockage historique rend également la mise en œuvre de nouveaux nœuds Ethereum plus viable, en ne supportant que la dernière version du protocole, ce qui les rend plus simples. Par exemple, il est maintenant possible de supprimer en toute sécurité de nombreuses lignes de code, car tous les slots de stockage vides créés pendant l'attaque DoS de 2016 ont été supprimés. Maintenant que la transition vers la preuve d'enjeu est devenue historique, les clients peuvent supprimer en toute sécurité tout le code lié à la preuve de travail.
Expiration de l'état
résout quel problème ?
Même si nous éliminons le besoin de stockage de l'historique par le client, les besoins de stockage du client continueront de croître, d'environ 50 Go par an, car l'état continue de croître : les soldes de compte et les nombres aléatoires, le code de contrat et le stockage de contrat. Les utilisateurs peuvent payer des frais uniques, ce qui imposera un fardeau aux clients Ethereum actuels et futurs.
L'état est plus difficile à "expirer" que l'historique, car l'EVM est fondamentalement conçu autour de l'hypothèse que, une fois qu'un objet d'état est créé, il existera toujours et pourra être lu à tout moment par n'importe quelle transaction. Si nous introduisons la non-état, certains pensent que ce problème n'est peut-être pas si grave : seuls des types de constructeurs de blocs spécialisés doivent réellement stocker l'état, tandis que tous les autres nœuds (y compris ceux générant des listes !) peuvent fonctionner sans état. Cependant, il existe un point de vue selon lequel nous ne voulons pas trop dépendre de la non-état, et finalement, nous pourrions vouloir faire expirer l'état pour maintenir la décentralisation d'Ethereum.
Qu'est-ce que c'est et comment ça fonctionne
Aujourd'hui, lorsque vous créez un nouvel objet d'état (ce qui peut se produire de l'une des trois manières suivantes : (i) envoyer de l'ETH à un nouveau compte, (ii) créer un nouveau compte en utilisant du code, (iii) configurer un emplacement de stockage qui n'a pas été touché auparavant), cet objet d'état reste dans cet état indéfiniment. En revanche, ce que nous voulons, c'est que l'objet expire automatiquement au fil du temps. Le défi clé est de le faire de manière à atteindre trois objectifs :
Efficacité : Aucun calcul supplémentaire important n'est nécessaire pour exécuter le processus d'expiration.
Facilité d'utilisation : si quelqu'un entre dans une grotte pendant cinq ans et revient, il ne devrait pas perdre l'accès à ses positions en ETH, ERC20, NFT et CDP...
Amabilité pour les développeurs : Les développeurs n'ont pas à passer à un modèle de pensée complètement inconnu. De plus, les applications qui sont actuellement figées et non mises à jour devraient continuer à fonctionner normalement.
Ne pas atteindre ces objectifs rend la résolution des problèmes très facile. Par exemple, vous pouvez faire en sorte que chaque objet d'état stocke également un compteur de date d'expiration (qui peut être prolongé en brûlant de l'ÉTH, ce qui pourrait se produire automatiquement à tout moment lors de la lecture ou de l'écriture), et avoir un processus pour parcourir l'état afin de supprimer les objets d'état de date d'expiration. Cependant, cela introduit des calculs supplémentaires (voire des besoins de stockage), et cela ne peut certainement pas répondre aux exigences de convivialité. Il est également difficile pour les développeurs de raisonner sur les cas limites où les valeurs de stockage sont parfois réinitialisées à zéro. Si vous définissez un minuteur d'expiration dans la portée du contrat, cela rendra techniquement la vie des développeurs plus facile, mais cela rendra l'économie plus difficile : les développeurs doivent réfléchir à la manière de "transférer" le coût de stockage continu aux utilisateurs.
Ces problèmes sont ceux que la communauté des développeurs principaux d'Ethereum s'efforce de résoudre depuis des années, y compris des propositions comme "la rente blockchain" et "la régénération". Au final, nous avons combiné les meilleures parties des propositions et nous nous sommes concentrés sur deux catégories de "solutions connues comme étant les moins mauvaises" :
Solutions pour l'expiration de certains états
Suggestions d'expiration d'état basées sur le cycle d'adresse.
Expiration partielle de l'état
Certaines propositions d'état expirées suivent les mêmes principes. Nous divisons l'état en blocs. Chacun stocke de manière permanente la "carte de niveau supérieur".
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
13 J'aime
Récompense
13
7
Reposter
Partager
Commentaire
0/400
Hash_Bandit
· 08-06 19:58
déjà vu... comme à l'époque du minage où nous avons optimisé la synchronisation des nœuds. l'eth a besoin de plus d'efficacité de style hashrate à vrai dire
Voir l'originalRépondre0
ILCollector
· 08-04 07:11
Il est conseillé d'utiliser L2 pour emballer les données.
Voir l'originalRépondre0
TokenomicsTrapper
· 08-03 21:09
a appelé ce problème de bloat il y a des mois... classique spirale de dettes techniques mortelle à venir
Voir l'originalRépondre0
HackerWhoCares
· 08-03 21:09
L'expansion du stockage reste un problème majeur.
Voir l'originalRépondre0
DefiPlaybook
· 08-03 21:07
Analyse des données montre que le problème d'explosion d'état a déjà affecté 87% des Nœuds off-chain.
Vitalik analyse le développement futur d'Ethereum : Analyse du plan The Purge
Vitalik : L'avenir possible d'Ethereum, The Purge
L'un des défis auxquels Ethereum est confronté est que, par défaut, l'expansion et la complexité de tout protocole de blockchain augmentent avec le temps. Cela se produit à deux endroits :
Données historiques : Toute transaction effectuée et tout compte créé à tout moment de l'histoire doivent être stockés de manière permanente par tous les clients et téléchargés par tout nouveau client, afin d'être complètement synchronisés avec le réseau. Cela entraînera une charge client et un temps de synchronisation qui augmentent avec le temps, même si la capacité de la chaîne reste inchangée.
Fonctionnalité de protocole : ajouter de nouvelles fonctionnalités est beaucoup plus facile que de supprimer d'anciennes fonctionnalités, ce qui entraîne une complexité du code croissante avec le temps.
Pour que l'Ethereum puisse se maintenir à long terme, nous devons exercer une forte contre-pression sur ces deux tendances, réduisant la complexité et l'expansion au fil du temps. Mais en même temps, nous devons préserver l'une des propriétés clés qui rendent la blockchain géniale : la pérennité. Vous pouvez mettre un NFT, une lettre d'amour dans les données d'un appel de transaction, ou un contrat intelligent contenant 1 million de dollars sur la chaîne, entrer dans une grotte pendant dix ans, et en sortir pour découvrir qu'il est toujours là, attendant que vous le lisiez et interagissiez. Pour que les DApps puissent se décentraliser complètement en toute confiance et supprimer les clés de mise à jour, ils doivent être sûrs que leurs dépendances ne seront pas mises à jour de manière à les perturber - en particulier L1 lui-même.
Il est absolument possible d'équilibrer ces deux besoins, de minimiser ou d'inverser le surpoids, la complexité et le déclin tout en maintenant la continuité. Les organismes vivants peuvent le faire : bien que la plupart des organismes vieillissent avec le temps, quelques chanceux ne le font pas. Même les systèmes sociaux peuvent avoir une très longue durée de vie. Dans certains cas, Ethereum a déjà réussi : la preuve de travail a disparu, l'opcode SELFDESTRUCT a principalement disparu, et les nœuds de la chaîne de balise ont stocké des données anciennes pendant jusqu'à six mois. Trouver ce chemin pour Ethereum de manière plus générale et se diriger vers un résultat final stable à long terme est le défi ultime pour la scalabilité à long terme d'Ethereum, la durabilité technique et même la sécurité.
The Purge : objectif principal.
Réduire les exigences de stockage des clients en diminuant ou en éliminant la nécessité pour chaque nœud de stocker de manière permanente tous les historiques, voire l'état final.
Réduire la complexité du protocole en éliminant les fonctionnalités inutiles.
Table des matières :
Historique d'expiration（历史记录到期）
Expiration de l'état（状态到期）
Nettoyage des fonctionnalités
Expiration de l'historique
résout quel problème ?
À la date de rédaction de cet article, un nœud Ethereum entièrement synchronisé nécessite environ 1,1 To d'espace disque pour exécuter le client, ainsi que plusieurs centaines de Go d'espace disque pour le client de consensus. La grande majorité de ces données est historique : il s'agit de données concernant les blocs historiques, les transactions et les reçus, dont la plupart ont plusieurs années. Cela signifie que même si la limite de Gas n'augmente pas du tout, la taille des nœuds continuera d'augmenter de plusieurs centaines de Go chaque année.
Qu'est-ce que c'est et comment ça fonctionne ?
Une caractéristique clé de simplification du problème de stockage historique est que, comme chaque bloc est lié au bloc précédent par un lien de hachage (et d'autres structures), il suffit d'atteindre un consensus sur le bloc actuel pour parvenir à un consensus sur l'historique. Tant que le réseau parvient à un consensus sur le dernier bloc, n'importe quel bloc, transaction ou état historique (solde de compte, nombre aléatoire, code, stockage) peut être fourni par un participant unique ainsi que par une preuve Merkle, et cette preuve permet à quiconque d'en vérifier la validité. Le consensus est un modèle de confiance N/2-of-N, tandis que l'historique est un modèle de confiance N-of-N.
Cela nous offre de nombreuses options sur la façon de stocker l'historique. Un choix naturel est un réseau où chaque nœud ne stocke qu'une petite partie des données. C'est ainsi que fonctionnent les réseaux de graines depuis des décennies : bien que le réseau stocke et distribue des millions de fichiers, chaque participant ne stocke et ne distribue que quelques fichiers parmi eux. Peut-être contre-intuitivement, cette méthode ne réduit même pas nécessairement la robustesse des données. Si nous pouvons rendre l'exécution des nœuds plus économique, nous pouvons établir un réseau de 100 000 nœuds, où chaque nœud stocke aléatoirement 10 % de l'historique, alors chaque donnée sera copiée 10 000 fois - exactement le même facteur de copie que dans un réseau de 10 000 nœuds, où chaque nœud stocke tout.
Aujourd'hui, Ethereum commence à se libérer du modèle où tous les nœuds stockent de manière permanente toute l'historique. Les blocs de consensus (c'est-à-dire la partie liée au consensus de preuve d'enjeu) ne stockent que pendant environ 6 mois. Les blobs ne sont stockés que pendant environ 18 jours. L'EIP-4444 vise à introduire une période de stockage d'un an pour les blocs historiques et les reçus. L'objectif à long terme est d'établir une période unifiée (probablement d'environ 18 jours) durant laquelle chaque nœud est responsable du stockage de tout, puis de créer un réseau pair à pair composé de nœuds Ethereum, qui stockera les anciennes données de manière distribuée.
Les codes d'effacement peuvent être utilisés pour améliorer la robustesse tout en maintenant le même facteur de réplication. En fait, le Blob a déjà été doté de codes d'effacement pour soutenir l'échantillonnage de la disponibilité des données. La solution la plus simple consistera probablement à réutiliser ces codes d'effacement et à intégrer également les données d'exécution et de consensus dans le blob.
a quels liens avec les recherches existantes ?
EIP-4444；
Torrents et EIP-4444；
réseau de porte
Portail réseau et EIP-4444 ;
Stockage et récupération distribués des objets SSZ dans Portal ;
Comment augmenter la limite de gaz (Paradigm).
que faut-il encore faire, quels compromis faut-il envisager ?
Le travail principal restant consiste à construire et à intégrer une solution distribuée concrète pour stocker les historiques ------ au moins l’historique des exécutions, mais finalement aussi le consensus et les blobs. La solution la plus simple est (i) d'introduire simplement des bibliothèques torrent existantes, ainsi que (ii) une solution native Ethereum appelée réseau Portal. Une fois l'un ou l'autre introduit, nous pouvons ouvrir l'EIP-4444. L'EIP-4444 lui-même ne nécessite pas de hard fork, mais il nécessite une nouvelle version du protocole réseau. Par conséquent, il est utile de l'activer pour tous les clients en même temps, sinon il existe un risque que les clients échouent en raison de la connexion à d'autres nœuds dans l'attente de télécharger l'historique complet mais ne l'obtiennent en réalité pas.
Les principaux compromis concernent nos efforts pour fournir des données historiques "anciennes". La solution la plus simple consiste à arrêter demain de stocker des histoires anciennes et à s'appuyer sur les nœuds d'archivage existants et divers fournisseurs centralisés pour la réplication. C'est facile, mais cela affaiblit la position d'Ethereum en tant que lieu d'enregistrement permanent. Une approche plus difficile mais plus sûre consiste d'abord à construire et à intégrer un réseau torrent pour stocker l'historique de manière distribuée. Ici, "combien nous nous efforçons" a deux dimensions :
Comment nous efforçons-nous de garantir que le plus grand ensemble de nœuds stocke effectivement toutes les données ?
Quelle est la profondeur de l'intégration de l'historique de stockage dans le protocole ?
Une méthode d'extrême paranoïa pour (1) impliquerait une preuve de garde : en réalité, cela exigerait que chaque validateur de preuve d'enjeu stocke une certaine proportion d'historique et vérifie régulièrement de manière cryptographique s'il le fait. Une méthode plus douce consisterait à établir une norme volontaire pour le pourcentage d'historique stocké par chaque client.
Pour (2), l'implémentation de base concerne uniquement le travail déjà accompli aujourd'hui : le Portal a déjà stocké un fichier ERA contenant toute l'histoire d'Ethereum. Une implémentation plus approfondie impliquerait de le connecter effectivement au processus de synchronisation, de sorte que si quelqu'un souhaite synchroniser un nœud de stockage d'historique complet ou un nœud d'archivage, même s'il n'y a pas d'autres nœuds d'archivage en ligne, il peut le faire en se synchronisant directement à partir du réseau Portal.
Comment interagit-il avec les autres parties de la feuille de route ?
Si nous voulons rendre l'exécution ou le démarrage des nœuds extrêmement facile, alors réduire les exigences de stockage historique peut être considéré comme plus important que la statelessness : sur les 1,1 To requis par le nœud, environ 300 Go sont des états, le reste, soit environ 800 Go, est devenu historique. Ce n'est qu'en réalisant la statelessness et l'EIP-4444 que nous pourrons atteindre la vision de faire fonctionner un nœud Ethereum sur une montre intelligente et de le configurer en quelques minutes.
La limitation du stockage historique rend également la mise en œuvre de nouveaux nœuds Ethereum plus viable, en ne supportant que la dernière version du protocole, ce qui les rend plus simples. Par exemple, il est maintenant possible de supprimer en toute sécurité de nombreuses lignes de code, car tous les slots de stockage vides créés pendant l'attaque DoS de 2016 ont été supprimés. Maintenant que la transition vers la preuve d'enjeu est devenue historique, les clients peuvent supprimer en toute sécurité tout le code lié à la preuve de travail.
Expiration de l'état
résout quel problème ?
Même si nous éliminons le besoin de stockage de l'historique par le client, les besoins de stockage du client continueront de croître, d'environ 50 Go par an, car l'état continue de croître : les soldes de compte et les nombres aléatoires, le code de contrat et le stockage de contrat. Les utilisateurs peuvent payer des frais uniques, ce qui imposera un fardeau aux clients Ethereum actuels et futurs.
L'état est plus difficile à "expirer" que l'historique, car l'EVM est fondamentalement conçu autour de l'hypothèse que, une fois qu'un objet d'état est créé, il existera toujours et pourra être lu à tout moment par n'importe quelle transaction. Si nous introduisons la non-état, certains pensent que ce problème n'est peut-être pas si grave : seuls des types de constructeurs de blocs spécialisés doivent réellement stocker l'état, tandis que tous les autres nœuds (y compris ceux générant des listes !) peuvent fonctionner sans état. Cependant, il existe un point de vue selon lequel nous ne voulons pas trop dépendre de la non-état, et finalement, nous pourrions vouloir faire expirer l'état pour maintenir la décentralisation d'Ethereum.
Qu'est-ce que c'est et comment ça fonctionne
Aujourd'hui, lorsque vous créez un nouvel objet d'état (ce qui peut se produire de l'une des trois manières suivantes : (i) envoyer de l'ETH à un nouveau compte, (ii) créer un nouveau compte en utilisant du code, (iii) configurer un emplacement de stockage qui n'a pas été touché auparavant), cet objet d'état reste dans cet état indéfiniment. En revanche, ce que nous voulons, c'est que l'objet expire automatiquement au fil du temps. Le défi clé est de le faire de manière à atteindre trois objectifs :
Efficacité : Aucun calcul supplémentaire important n'est nécessaire pour exécuter le processus d'expiration.
Facilité d'utilisation : si quelqu'un entre dans une grotte pendant cinq ans et revient, il ne devrait pas perdre l'accès à ses positions en ETH, ERC20, NFT et CDP...
Amabilité pour les développeurs : Les développeurs n'ont pas à passer à un modèle de pensée complètement inconnu. De plus, les applications qui sont actuellement figées et non mises à jour devraient continuer à fonctionner normalement.
Ne pas atteindre ces objectifs rend la résolution des problèmes très facile. Par exemple, vous pouvez faire en sorte que chaque objet d'état stocke également un compteur de date d'expiration (qui peut être prolongé en brûlant de l'ÉTH, ce qui pourrait se produire automatiquement à tout moment lors de la lecture ou de l'écriture), et avoir un processus pour parcourir l'état afin de supprimer les objets d'état de date d'expiration. Cependant, cela introduit des calculs supplémentaires (voire des besoins de stockage), et cela ne peut certainement pas répondre aux exigences de convivialité. Il est également difficile pour les développeurs de raisonner sur les cas limites où les valeurs de stockage sont parfois réinitialisées à zéro. Si vous définissez un minuteur d'expiration dans la portée du contrat, cela rendra techniquement la vie des développeurs plus facile, mais cela rendra l'économie plus difficile : les développeurs doivent réfléchir à la manière de "transférer" le coût de stockage continu aux utilisateurs.
Ces problèmes sont ceux que la communauté des développeurs principaux d'Ethereum s'efforce de résoudre depuis des années, y compris des propositions comme "la rente blockchain" et "la régénération". Au final, nous avons combiné les meilleures parties des propositions et nous nous sommes concentrés sur deux catégories de "solutions connues comme étant les moins mauvaises" :
Expiration partielle de l'état
Certaines propositions d'état expirées suivent les mêmes principes. Nous divisons l'état en blocs. Chacun stocke de manière permanente la "carte de niveau supérieur".