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 de deux manières :
Données historiques : toutes les transactions effectuées et les comptes créés à tout moment doivent être stockés de manière permanente par tous les clients et être téléchargés par tout nouveau client pour se synchroniser complètement avec le réseau. Cela entraîne une augmentation continue de la charge des clients et du temps de synchronisation, même si la capacité de la chaîne reste inchangée.
Fonctionnalité du 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 qui augmente avec le temps.
Pour que l'Ethereum puisse maintenir sa durabilité à long terme, nous devons exercer une forte contre-pression sur ces deux tendances, réduisant progressivement 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 grande : la durabilité. Vous pouvez mettre un NFT, une lettre d'amour ou un contrat intelligent contenant un million de dollars sur la chaîne, entrer dans une grotte pendant dix ans, et en sortant, découvrir qu'il est toujours là, attendant que vous le lisiez et interagissiez. Pour que les DApps soient complètement décentralisés et suppriment les clés de mise à jour, ils doivent être convaincus que leurs dépendances ne seront pas mises à niveau de manière à les perturber - en particulier L1 lui-même.
Si nous nous engageons à équilibrer ces deux besoins et à minimiser ou inverser l'enflure, la complexité et le déclin tout en maintenant la continuité, c'est absolument possible. Les organismes biologiques peuvent le faire : bien que la plupart des organismes biologiques vieillissent avec le temps, quelques heureux élus ne le font pas. Même les systèmes sociaux peuvent avoir une durée de vie très longue. Dans certains cas, Ethereum a réussi : la preuve de travail a disparu, l'opcode SELFDESTRUCT a presque disparu, et les nœuds de la chaîne de balisage 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, sa durabilité technique et même sa sécurité.
The Purge : objectif principal.
Réduire les exigences de stockage des clients en diminuant ou en éliminant le besoin pour chaque nœud de stocker de façon 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 ( historique enregistré jusqu'à expiration )
État d'expiration( état d'expiration)
Nettoyage des fonctionnalités(特征清理)
Historique d'expiration
Quel problème est résolu ?
À 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, et il faut également plusieurs centaines de Go d'espace disque pour le client de consensus. La majeure partie de cela est historique : des données sur 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 du nœud continuera d'augmenter de plusieurs centaines de Go chaque année.
Qu'est-ce que c'est, comment ça fonctionne?
Une caractéristique clé de la simplification des problèmes de stockage historique est que, comme chaque bloc est lié au bloc précédent par un hachage ( et d'autres structures ), il suffit d'atteindre un consensus sur l'état 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 n'importe quel participant unique ainsi que par une preuve de Merkle, et cette preuve permet à tout autre de vérifier sa validité. Le consensus est un modèle de confiance N/2-sur-N, tandis que l'historique est un modèle de confiance N-sur-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 fonctionne le réseau de semences depuis des décennies : bien que le réseau stocke et distribue des millions de fichiers au total, 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, en rendant l'exécution des nœuds plus économique, nous pouvons établir un réseau de 100 000 nœuds, chacun stockant 10 % de l'historique au hasard, alors chaque donnée sera copiée 10 000 fois - exactement le même facteur de duplication que dans un réseau de 10 000 nœuds, où chaque nœud stocke tout.
Aujourd'hui, Ethereum a commencé à se débarrasser du modèle où tous les nœuds stockent de manière permanente toute l'historique. Le bloc de consensus ( est lié à la partie du consensus de preuve d'enjeu, qui ne stocke 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 ) qui pourrait durer environ 18 jours (, pendant laquelle chaque nœud est responsable du stockage de tout, puis d'établir un réseau pair-à-pair composé de nœuds Ethereum, stockant 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é codé avec des codes d'effacement pour soutenir l'échantillonnage de la disponibilité des données. La solution la plus simple sera probablement de réutiliser ces codes d'effacement et d'inclure les données d'exécution et de consensus dans le blob.
)# Quelles sont les relations avec les recherches existantes ?
EIP-4444;
Torrents et EIP-4444;
réseau de portail;
réseau de porte 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 l'historique ------ 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 une bibliothèque torrent existante, ainsi que )ii( une solution native à Ethereum appelée réseau Portal. Une fois l'un de ces deux introduits, 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 des clients échouent en raison de la connexion à d'autres nœuds s'attendant à télécharger l'historique complet mais ne l'obtenant en réalité pas.
Les principaux compromis concernent nos efforts pour fournir des données historiques "anciennes". La solution la plus simple consiste à cesser de stocker les anciennes données historiques demain et à dépendre des nœuds d'archivage existants et de 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. Un moyen plus difficile mais plus sûr consiste d'abord à construire et à intégrer un réseau torrent pour stocker les historiques de manière distribuée. Ici, "à quel point nous nous efforçons" a deux dimensions :
Comment veillons-nous à ce que le plus grand ensemble de nœuds stocke effectivement toutes les données ?
Quelle est la profondeur de l'intégration du stockage historique dans le protocole ?
Une méthode d'extrême paranoïa pour ) impliquerait une preuve de garde : exigeant en réalité que chaque vérificateur de preuve d'enjeu stocke un certain pourcentage d'historique et vérifie régulièrement de manière cryptographique s'il le fait. Une méthode plus douce consiste à établir une norme volontaire pour le pourcentage d'historique stocké par chaque client.
Pour (2), la mise en œuvre de base ne concerne que le travail déjà accompli aujourd'hui : le Portal a stocké un fichier ERA contenant l'ensemble de l'historique d'Ethereum. Une mise en œuvre plus complète impliquerait de le connecter réellement 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'archive, même si aucun autre nœud d'archive n'est en ligne, il puisse le faire par synchronisation directe via le réseau Portal.
(# Comment cela interagit-il avec les autres parties de la feuille de route ?
Si nous voulons que le fonctionnement ou le démarrage des nœuds soit extrêmement facile, alors réduire les besoins de stockage historique peut être considéré comme plus important que l'absence d'état : sur les 1,1 To nécessaires au nœud, environ 300 Go sont des états, le reste, soit environ 800 Go, est devenu historique. Ce n'est qu'en réalisant l'absence d'état et l'EIP-4444 que la vision de faire fonctionner un nœud Ethereum sur une montre intelligente et de le configurer en quelques minutes peut être atteinte.
La limitation du stockage historique rend également l'implémentation des nœuds Ethereum plus réalisable, ne supportant que la dernière version du protocole, ce qui les rend plus simples. Par exemple, il est désormais possible de supprimer en toute sécurité de nombreuses lignes de code, car tous les slots de stockage vides créés lors de l'attaque DoS de 2016 ont été supprimés. Maintenant que le passage à la preuve d'enjeu est devenu historique, les clients peuvent supprimer en toute sécurité tout le code lié à la preuve de travail.
) État d'expiration
Quel problème résoudre ?
Même si nous éliminons le besoin d'historique de stockage côté client, les besoins de stockage côté client continueront d'augmenter, d'environ 50 Go par an, car l'état continue de croître : les soldes des comptes et les nombres aléatoires, le code des contrats et le stockage des contrats. Les utilisateurs peuvent payer des frais uniques, ce qui alourdira éternellement les clients Ethereum actuels et futurs.
L’état est plus difficile à "expirer" que l’histoire, car l'EVM est fondamentalement conçu autour de l'hypothèse suivante : une fois qu'un objet d'état est créé, il existe toujours et peut être lu à tout moment par n'importe quelle transaction. Si nous introduisons l'absence d'état, certains pensent que ce problème n'est peut-être pas si grave : seuls les constructeurs de blocs spécialisés ont réellement besoin de stocker l'état, tandis que tous les autres nœuds ### même ceux contenant des listes générées ! ### peuvent fonctionner sans état. Cependant, il y a un point de vue selon lequel nous ne voulons pas trop dépendre de l'absence d'état, et finalement, nous pourrions souhaiter faire expirer l'état pour maintenir la décentralisation d'Ethereum.
(# Qu'est-ce que c'est, comment ça fonctionne
Aujourd'hui, lorsque vous créez un nouvel objet d'état, ) 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 à l'aide de code, ( iii ) configurer un emplacement de stockage jamais touché auparavant (, cet objet d'état reste toujours dans cet état. 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 d'une manière qui atteigne les trois objectifs :
Efficacité : pas besoin de calculs supplémentaires importants pour exécuter le processus d'expiration.
Facilité d'utilisation : Si quelqu'un entre dans la grotte pendant cinq ans et revient, il ne devrait pas perdre l'accès à ETH, ERC20, NFT, CDP.
Amabilité pour les développeurs : les développeurs n'ont pas besoin de passer à un modèle de pensée totalement inconnu. De plus, les applications qui sont actuellement rigides et non mises à jour devraient pouvoir continuer à fonctionner normalement.
Il est très facile de résoudre des problèmes si ces objectifs ne sont pas atteints. Par exemple, vous pouvez faire en sorte que chaque objet d'état stocke également un compteur de date d'expiration. Le ) peut être prolongé en brûlant de l'ETH, ce qui peut se produire automatiquement lors de la lecture ou de l'écriture à tout moment, et il existe un processus de parcours des états pour supprimer les objets d'état avec une date d'expiration. Cependant, cela introduit des exigences de calcul et de stockage supplémentaires, et cela ne peut certainement pas répondre aux exigences de convivialité. Les développeurs ont également du mal à raisonner sur les cas aux limites impliquant des valeurs de stockage 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 compliquera l'économie : les développeurs doivent réfléchir à la manière de "répercuter" les coûts de stockage continus sur les 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 telles que "le loyer de la blockchain" et "la régénération". Finalement, 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 de statut partiellement expirées
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 en permanence la "carte de niveau supérieur", où les blocs peuvent être vides ou non. Les données dans chaque bloc ne sont stockées que si ces données ont été récemment consultées. Il existe un mécanisme de "résurrection", si elles ne sont plus stockées.
La principale différence entre ces propositions est : (i) comment nous définissons "récemment", et (ii) comment nous définissons "bloc" ? Une proposition concrète est EIP-7736, qui est basée sur la conception "tige-feuille" introduite pour les arbres Verkle ### bien qu'elle soit compatible avec toute forme d'état sans état, comme les arbres binaires (. Dans cette conception, les en-têtes, le code et les emplacements de stockage adjacents sont stockés sous la même "tige". Les données stockées sous une tige peuvent aller jusqu'à 256 * 31 = 7,936.
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.
11 J'aime
Récompense
11
7
Partager
Commentaire
0/400
NotGonnaMakeIt
· 07-16 18:58
La massive Blockchain a épuisé les nouvelles machines, n'est-ce pas ?
Voir l'originalRépondre0
MysteryBoxBuster
· 07-15 00:26
Cette chaîne devient de plus en plus lourde.
Voir l'originalRépondre0
SquidTeacher
· 07-14 03:56
C'est une bonne idée.
Voir l'originalRépondre0
GasFeeCrier
· 07-14 03:53
C'est maintenant le moment le plus gros, n'est-ce pas ?
Voir l'originalRépondre0
DefiOldTrickster
· 07-14 03:52
off-chain, on voit encore un grand prophète.
Voir l'originalRépondre0
GasBandit
· 07-14 03:47
Quand pourrai-je battre l'inflation ?
Voir l'originalRépondre0
StablecoinArbitrageur
· 07-14 03:29
*ajuste les tableurs* basé sur mon analyse de corrélation, l'efficacité de purge = durabilité du réseau * -0,89
Ethereum The Purge : construire un écosystème blockchain durable à long terme
L'avenir possible d'Ethereum : The Purge
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 de deux manières :
Données historiques : toutes les transactions effectuées et les comptes créés à tout moment doivent être stockés de manière permanente par tous les clients et être téléchargés par tout nouveau client pour se synchroniser complètement avec le réseau. Cela entraîne une augmentation continue de la charge des clients et du temps de synchronisation, même si la capacité de la chaîne reste inchangée.
Fonctionnalité du 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 qui augmente avec le temps.
Pour que l'Ethereum puisse maintenir sa durabilité à long terme, nous devons exercer une forte contre-pression sur ces deux tendances, réduisant progressivement 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 grande : la durabilité. Vous pouvez mettre un NFT, une lettre d'amour ou un contrat intelligent contenant un million de dollars sur la chaîne, entrer dans une grotte pendant dix ans, et en sortant, découvrir qu'il est toujours là, attendant que vous le lisiez et interagissiez. Pour que les DApps soient complètement décentralisés et suppriment les clés de mise à jour, ils doivent être convaincus que leurs dépendances ne seront pas mises à niveau de manière à les perturber - en particulier L1 lui-même.
Si nous nous engageons à équilibrer ces deux besoins et à minimiser ou inverser l'enflure, la complexité et le déclin tout en maintenant la continuité, c'est absolument possible. Les organismes biologiques peuvent le faire : bien que la plupart des organismes biologiques vieillissent avec le temps, quelques heureux élus ne le font pas. Même les systèmes sociaux peuvent avoir une durée de vie très longue. Dans certains cas, Ethereum a réussi : la preuve de travail a disparu, l'opcode SELFDESTRUCT a presque disparu, et les nœuds de la chaîne de balisage 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, sa durabilité technique et même sa sécurité.
The Purge : objectif principal.
Réduire les exigences de stockage des clients en diminuant ou en éliminant le besoin pour chaque nœud de stocker de façon 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 ( historique enregistré jusqu'à expiration ) État d'expiration( état d'expiration) Nettoyage des fonctionnalités(特征清理)
Historique d'expiration
Quel problème est résolu ?
À 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, et il faut également plusieurs centaines de Go d'espace disque pour le client de consensus. La majeure partie de cela est historique : des données sur 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 du nœud continuera d'augmenter de plusieurs centaines de Go chaque année.
Qu'est-ce que c'est, comment ça fonctionne?
Une caractéristique clé de la simplification des problèmes de stockage historique est que, comme chaque bloc est lié au bloc précédent par un hachage ( et d'autres structures ), il suffit d'atteindre un consensus sur l'état 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 n'importe quel participant unique ainsi que par une preuve de Merkle, et cette preuve permet à tout autre de vérifier sa validité. Le consensus est un modèle de confiance N/2-sur-N, tandis que l'historique est un modèle de confiance N-sur-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 fonctionne le réseau de semences depuis des décennies : bien que le réseau stocke et distribue des millions de fichiers au total, 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, en rendant l'exécution des nœuds plus économique, nous pouvons établir un réseau de 100 000 nœuds, chacun stockant 10 % de l'historique au hasard, alors chaque donnée sera copiée 10 000 fois - exactement le même facteur de duplication que dans un réseau de 10 000 nœuds, où chaque nœud stocke tout.
Aujourd'hui, Ethereum a commencé à se débarrasser du modèle où tous les nœuds stockent de manière permanente toute l'historique. Le bloc de consensus ( est lié à la partie du consensus de preuve d'enjeu, qui ne stocke 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 ) qui pourrait durer environ 18 jours (, pendant laquelle chaque nœud est responsable du stockage de tout, puis d'établir un réseau pair-à-pair composé de nœuds Ethereum, stockant 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é codé avec des codes d'effacement pour soutenir l'échantillonnage de la disponibilité des données. La solution la plus simple sera probablement de réutiliser ces codes d'effacement et d'inclure les données d'exécution et de consensus dans le blob.
)# Quelles sont les relations avec les recherches existantes ?
EIP-4444;
Torrents et EIP-4444;
réseau de portail;
réseau de porte 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 l'historique ------ 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 une bibliothèque torrent existante, ainsi que )ii( une solution native à Ethereum appelée réseau Portal. Une fois l'un de ces deux introduits, 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 des clients échouent en raison de la connexion à d'autres nœuds s'attendant à télécharger l'historique complet mais ne l'obtenant en réalité pas.
Les principaux compromis concernent nos efforts pour fournir des données historiques "anciennes". La solution la plus simple consiste à cesser de stocker les anciennes données historiques demain et à dépendre des nœuds d'archivage existants et de 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. Un moyen plus difficile mais plus sûr consiste d'abord à construire et à intégrer un réseau torrent pour stocker les historiques de manière distribuée. Ici, "à quel point nous nous efforçons" a deux dimensions :
Comment veillons-nous à ce que le plus grand ensemble de nœuds stocke effectivement toutes les données ?
Quelle est la profondeur de l'intégration du stockage historique dans le protocole ?
Une méthode d'extrême paranoïa pour ) impliquerait une preuve de garde : exigeant en réalité que chaque vérificateur de preuve d'enjeu stocke un certain pourcentage d'historique et vérifie régulièrement de manière cryptographique s'il le fait. Une méthode plus douce consiste à établir une norme volontaire pour le pourcentage d'historique stocké par chaque client.
Pour (2), la mise en œuvre de base ne concerne que le travail déjà accompli aujourd'hui : le Portal a stocké un fichier ERA contenant l'ensemble de l'historique d'Ethereum. Une mise en œuvre plus complète impliquerait de le connecter réellement 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'archive, même si aucun autre nœud d'archive n'est en ligne, il puisse le faire par synchronisation directe via le réseau Portal.
(# Comment cela interagit-il avec les autres parties de la feuille de route ?
Si nous voulons que le fonctionnement ou le démarrage des nœuds soit extrêmement facile, alors réduire les besoins de stockage historique peut être considéré comme plus important que l'absence d'état : sur les 1,1 To nécessaires au nœud, environ 300 Go sont des états, le reste, soit environ 800 Go, est devenu historique. Ce n'est qu'en réalisant l'absence d'état et l'EIP-4444 que la vision de faire fonctionner un nœud Ethereum sur une montre intelligente et de le configurer en quelques minutes peut être atteinte.
La limitation du stockage historique rend également l'implémentation des nœuds Ethereum plus réalisable, ne supportant que la dernière version du protocole, ce qui les rend plus simples. Par exemple, il est désormais possible de supprimer en toute sécurité de nombreuses lignes de code, car tous les slots de stockage vides créés lors de l'attaque DoS de 2016 ont été supprimés. Maintenant que le passage à la preuve d'enjeu est devenu historique, les clients peuvent supprimer en toute sécurité tout le code lié à la preuve de travail.
) État d'expiration
Quel problème résoudre ?
Même si nous éliminons le besoin d'historique de stockage côté client, les besoins de stockage côté client continueront d'augmenter, d'environ 50 Go par an, car l'état continue de croître : les soldes des comptes et les nombres aléatoires, le code des contrats et le stockage des contrats. Les utilisateurs peuvent payer des frais uniques, ce qui alourdira éternellement les clients Ethereum actuels et futurs.
L’état est plus difficile à "expirer" que l’histoire, car l'EVM est fondamentalement conçu autour de l'hypothèse suivante : une fois qu'un objet d'état est créé, il existe toujours et peut être lu à tout moment par n'importe quelle transaction. Si nous introduisons l'absence d'état, certains pensent que ce problème n'est peut-être pas si grave : seuls les constructeurs de blocs spécialisés ont réellement besoin de stocker l'état, tandis que tous les autres nœuds ### même ceux contenant des listes générées ! ### peuvent fonctionner sans état. Cependant, il y a un point de vue selon lequel nous ne voulons pas trop dépendre de l'absence d'état, et finalement, nous pourrions souhaiter faire expirer l'état pour maintenir la décentralisation d'Ethereum.
(# Qu'est-ce que c'est, comment ça fonctionne
Aujourd'hui, lorsque vous créez un nouvel objet d'état, ) 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 à l'aide de code, ( iii ) configurer un emplacement de stockage jamais touché auparavant (, cet objet d'état reste toujours dans cet état. 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 d'une manière qui atteigne les trois objectifs :
Efficacité : pas besoin de calculs supplémentaires importants pour exécuter le processus d'expiration.
Facilité d'utilisation : Si quelqu'un entre dans la grotte pendant cinq ans et revient, il ne devrait pas perdre l'accès à ETH, ERC20, NFT, CDP.
Amabilité pour les développeurs : les développeurs n'ont pas besoin de passer à un modèle de pensée totalement inconnu. De plus, les applications qui sont actuellement rigides et non mises à jour devraient pouvoir continuer à fonctionner normalement.
Il est très facile de résoudre des problèmes si ces objectifs ne sont pas atteints. Par exemple, vous pouvez faire en sorte que chaque objet d'état stocke également un compteur de date d'expiration. Le ) peut être prolongé en brûlant de l'ETH, ce qui peut se produire automatiquement lors de la lecture ou de l'écriture à tout moment, et il existe un processus de parcours des états pour supprimer les objets d'état avec une date d'expiration. Cependant, cela introduit des exigences de calcul et de stockage supplémentaires, et cela ne peut certainement pas répondre aux exigences de convivialité. Les développeurs ont également du mal à raisonner sur les cas aux limites impliquant des valeurs de stockage 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 compliquera l'économie : les développeurs doivent réfléchir à la manière de "répercuter" les coûts de stockage continus sur les 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 telles que "le loyer de la blockchain" et "la régénération". Finalement, 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 en permanence la "carte de niveau supérieur", où les blocs peuvent être vides ou non. Les données dans chaque bloc ne sont stockées que si ces données ont été récemment consultées. Il existe un mécanisme de "résurrection", si elles ne sont plus stockées.
La principale différence entre ces propositions est : (i) comment nous définissons "récemment", et (ii) comment nous définissons "bloc" ? Une proposition concrète est EIP-7736, qui est basée sur la conception "tige-feuille" introduite pour les arbres Verkle ### bien qu'elle soit compatible avec toute forme d'état sans état, comme les arbres binaires (. Dans cette conception, les en-têtes, le code et les emplacements de stockage adjacents sont stockés sous la même "tige". Les données stockées sous une tige peuvent aller jusqu'à 256 * 31 = 7,936.