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 blockchain augmentent avec le temps. Cela se produit de deux manières : les données historiques et les fonctionnalités du protocole. Pour permettre à Ethereum de se maintenir à long terme, nous devons exercer une forte contre-pression sur ces deux tendances afin de réduire la complexité et l'expansion au fil du temps. Mais en même temps, nous devons conserver l'une des propriétés clés qui rendent la blockchain formidable : la durabilité.

L'objectif principal de The Purge est :

• Réduire les exigences de stockage du client en diminuant ou en éliminant le besoin pour chaque nœud de conserver de manière permanente tous les historiques, voire l'état final.
• Réduire la complexité du protocole en éliminant les fonctionnalités inutiles.

Expiration de l'historique

résout quel problème ?

Au moment de la 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 plusieurs centaines de Go d'espace disque supplémentaires pour le client de consensus. La grande majorité de cela est historique : des 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, comment ça fonctionne ?

Une caractéristique clé de simplification du problème de stockage historique est que, puisque chaque bloc est lié par un hachage à ( et à d'autres structures ) pointant vers le bloc précédent, 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 historique, transaction ou état ( comme le solde des comptes, le nombre aléatoire, le code, le stockage ) peut être fourni par n'importe quel 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 les réseaux de pépins fonctionnent 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 n'entraîne même pas nécessairement une diminution de 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 aléatoirement 10 % de l'historique, alors chaque donnée sera copiée 10 000 fois - ce qui est exactement le même facteur de copie que celui d'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 par preuve d'enjeu qui stocke seulement environ 6 mois. Les Blob ne stockent 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 être d'environ 18 jours (, pendant laquelle chaque nœud serait responsable du stockage de tout le contenu, 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, Blob a déjà effectué des codes d'effacement pour soutenir l'échantillonnage de la disponibilité des données. La solution la plus simple consiste probablement à réutiliser ces codes d'effacement et à incorporer l'exécution et les données de blocs de consensus également dans le blob.

![Vitalik : l'avenir potentiel d'Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp(

) que faut-il encore faire, quels compromis faut-il envisager?

Les travaux restants comprennent la construction et l'intégration d'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 une bibliothèque torrent existante, ainsi que )ii( appelée solution native Ethereum du réseau Portal. Une fois l'une d'elles introduite, nous pouvons ouvrir l'EIP-4444. L'EIP-4444 lui-même ne nécessite pas de hard fork, mais il nécessite effectivement une nouvelle version du protocole réseau. Par conséquent, il est utile de l'activer simultanément pour tous les clients, sinon il existe un risque que les clients échouent en s'attendant à télécharger un historique complet en se connectant à d'autres nœuds, mais ne l'obtenant pas réellement.

Les principaux compromis concernent nos efforts pour fournir des données historiques "anciennes". La solution la plus simple est d'arrêter de stocker l'histoire ancienne demain et de s'appuyer sur les nœuds d'archive 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 voie 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, "à quel point 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 du stockage historique dans le protocole?

Une méthode extrême de paranoïa pour ) impliquerait la preuve de garde : exigeant en fait que chaque validateur de preuve d'enjeu stocke une certaine proportion d'historique et vérifie régulièrement de manière cryptographique s'ils le font. Une méthode plus modérée consiste à établir un standard 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 Portail a déjà stocké un fichier ERA contenant l'intégralité de l'histoire 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'archivage, même s'il n'y a pas d'autres nœuds d'archivage en ligne, il pourrait le faire par synchronisation directe à partir du réseau du Portail.

( Comment cela interagit-il avec d'autres parties de la feuille de route ?

Si nous voulons rendre l'exécution ou le démarrage des nœuds extrêmement faciles, alors réduire les exigences de stockage historique peut être considéré comme plus important que l'absence d'état : parmi les 1,1 To nécessaires pour les nœuds, 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 nous pourrons réaliser 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 des nœuds Ethereum plus viable, ne prenant en charge 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 emplacements de stockage vides créés lors de l'attaque par déni de service (DoS) de 2016 ont été supprimés. Maintenant que le passage à la preuve d'enjeu est devenu une histoire, les clients peuvent supprimer en toute sécurité tout le code lié à la preuve de travail.

![Vitalik : l'avenir potentiel d'Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp###

Expiration de l'état

( résout quel problème ?

Même si nous éliminons le besoin de stockage des historiques sur le client, la demande de stockage du client continuera 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 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 cette hypothèse : une fois qu'un objet d'état est créé, il existe toujours et peut être lu à tout moment par toute transaction. Si nous introduisons l'absence d'état, certaines personnes pensent que ce problème n'est peut-être pas si grave : seules les classes de 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 vouloir rendre l'état obsolète 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 avec du code, ( iii ) définir un emplacement de stockage qui n'a jamais été touché auparavant (, cet objet d'état reste dans cet état pour toujours. En revanche, ce que nous voulons, c'est que l'objet expire automatiquement avec le temps. Le défi clé est de le faire d'une manière qui réalise les trois objectifs :

• Efficacité : il n'est pas nécessaire d'effectuer de nombreux calculs supplémentaires 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, 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 actuellement rigides et non mises à jour devraient pouvoir 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. ) peut être prolongé en brûlant de l'ETH, ce qui peut se produire automatiquement à tout moment lors de la lecture ou de l'écriture. ), et il y a un processus pour parcourir l'état afin de supprimer les objets d'état de date d'expiration. Cependant, cela introduit des besoins de calcul supplémentaires ( et même de stockage ), et cela ne peut certainement pas répondre aux exigences de convivialité. Les développeurs ont également du mal à raisonner sur les cas limites impliquant des valeurs de stockage qui se réinitialisent parfois à zéro. Si vous définissez un minuteur d'expiration dans le 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" les coûts de stockage continus aux utilisateurs.

Ces problèmes sont ceux auxquels la communauté des développeurs principaux d'Ethereum a travaillé pendant de nombreuses années, y compris des propositions telles que "loyer de blockchain" et "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 pour l'expiration de certaines statuts
• Recommandation de l'expiration de l'état basée sur le cycle d'adresse.

(# Expiration partielle de l'état

Certaines propositions d'état expirent selon les mêmes principes. Nous divisons l'état en blocs. Chacun stocke de manière permanente la "carte principale", 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" qui s'active 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 l'EIP-7736, qui est basée sur le design "feuille" introduit pour l'arbre Verkle ( bien qu'il soit compatible avec toute forme d'état sans état, comme un arbre binaire ). Dans ce design, les en-têtes, le code et les emplacements de stockage adjacents sont stockés sous le même "tronc". Les données stockées sous un tronc peuvent atteindre un maximum de 256 * 31 = 7 936 octets. Dans de nombreux cas, l'ensemble des en-têtes et du code d'un compte ainsi que de nombreux emplacements de stockage de clés seront stockés sous le même tronc. Si les données sous le tronc donné n'ont pas été lues ou écrites pendant 6 mois, ces données ne seront plus stockées, mais uniquement un engagement de 32 octets de ces données, un "stub" (. Les transactions futures accédant à ces données devront "résusciter" les données et fournir une preuve de vérification basée sur le stub.

Il existe d'autres moyens de réaliser des idées similaires. Par exemple, si le niveau de granularité au niveau du compte n'est pas suffisant, nous pouvons élaborer un plan dans lequel chaque 1/232 de l'arbre est contrôlé par un mécanisme de tiges et de feuilles similaire.

En raison des incitations, cela devient plus délicat : les attaquants peuvent "mettre à jour l'arbre" en plaçant une grande quantité de données dans un seul sous-arbre et en envoyant une seule transaction par an, ce qui oblige le client à stocker de manière permanente un grand nombre d'états. Si vous rendez le coût de renouvellement proportionnel à la taille de l'arbre ) ou inversement proportionnel à la durée de renouvellement (, alors quelqu'un pourrait nuire à d'autres utilisateurs en plaçant une grande quantité de données dans le même sous-arbre qu'eux. Les gens peuvent essayer de limiter ces deux problèmes en dynamisant la granularité en fonction de la taille du sous-arbre : par exemple, chaque ensemble continu de 216 = 65536 objets d'état peut être considéré comme un "groupe". Cependant, ces idées sont plus complexes ; l'approche basée sur le rejeton est simple et les incitations peuvent être ajustées, car généralement sous le rejeton.