L'avenir potentiel 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 à deux endroits:

Données historiques : toutes les transactions effectuées et tous les comptes créés à tout moment dans le passé doivent être stockés de manière permanente par tous les clients et téléchargés par tout nouveau client, afin de se synchroniser complètement avec le réseau. Cela entraînera une augmentation continue de la charge des clients et du temps de synchronisation au fil du temps, 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 Ethereum puisse se maintenir à long terme, nous devons exercer une forte pression inverse 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 formidable : la durabilité. Vous pouvez mettre un NFT, une lettre d'amour dans les données d'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 ressortir en découvrant qu'il est toujours là, attendant que vous le lisiez et interagissiez. Pour que les DApps puissent être totalement décentralisés en toute confiance et supprimer les clés de mise à jour, ils doivent être convaincus que leurs dépendances ne seront pas mises à jour de manière à les détruire - en particulier L1 lui-même.

Si nous nous engageons à équilibrer ces deux besoins et à minimiser ou inverser l'encombrement, la complexité et le déclin tout en maintenant la continuité, c'est absolument possible. 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 durée de vie très longue. Dans certains cas, Ethereum a réussi : la preuve de travail a disparu, le code d'opération SELFDESTRUCT a principalement disparu, et les nœuds de la chaîne de balises ont stocké des données anciennes pendant un maximum de 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 l'évolutivité à 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 la nécessité pour chaque nœud de conserver en permanence tous les historiques, voire l'état final.

Réduire la complexité du protocole en éliminant les fonctionnalités non nécessaires.

Table des matières:

Historique d'expiration( historique enregistré à expiration)

État d'expiration( état d'expiration)

Nettoyage des fonctionnalités ( nettoyage des caractéristiques )

Historique d'expiration

résout quel problème ?

À la date de rédaction de cet article, un nœud Ethereum complètement synchronisé nécessite environ 1,1 To d'espace disque pour exécuter le client, et des centaines de Go d'espace disque supplémentaires pour le client de consensus. La grande majorité de ces données sont historiques : elles concernent des données sur des blocs historiques, des transactions et des 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, 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, tout bloc historique, transaction ou état (, solde de compte, nombre aléatoire, code, stockage ) peut être fourni par n'importe quel participant individuel ainsi qu'une preuve Merkle, et cette preuve permet à quiconque d'en vérifier l'exactitude. 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 fonctionne le réseau de semences depuis des décennies : bien que le réseau ait stocké et distribué 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, 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 qu'un réseau de 10 000 nœuds, où chaque nœud stocke tout.

Aujourd'hui, Ethereum a commencé à se défaire du modèle où tous les nœuds stockent de façon permanente toute l'histoire. Le bloc de consensus ( est lié à la preuve d'enjeu et ne stocke que les parties pertinentes pendant environ 6 mois. Le Blob ne stocke 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, puis de créer un réseau pair-à-pair composé de nœuds Ethereum pour stocker les anciennes données de manière distribuée.

![Vitalik : l'avenir possible d'Ethereum, The Purge])ian/2024/10/27/images/f62684c615eed31373c7711933176f43.jpg(

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à mis en œuvre des codes d'effacement pour supporter l'échantillonnage de disponibilité des données. La solution la plus simple est probablement de réutiliser ces codes d'effacement et d'inclure également les données de bloc d'exécution et de consensus dans le blob.

) est en relation avec les recherches existantes ?

EIP-4444;

Torrents et EIP-4444;

Portail réseau;

Portail réseau et EIP-4444;

Stockage et récupération distribués des objets SSZ dans le portail;

Comment augmenter la limite de gas ### Paradigm (.

) Que faut-il encore faire, quels sont les compromis à considérer ?

Le travail principal restant consiste à construire et à intégrer une solution distribuée concrète pour stocker l'historique ------ au moins l'historique d'exécution, mais finalement aussi le consensus et le blob. 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 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 de défaillance des clients qui s'attendent à télécharger l'historique complet en se connectant à d'autres nœuds mais qui ne l'obtiennent pas réellement.

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 demain 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 les historiques de manière distribuée. Ici, "à quel point nous nous efforçons" a deux dimensions :

Comment nous assurons-nous 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 approche extrême et paranoïaque concernant ) impliquerait une preuve de garde : exigeant en réalité 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 approche plus modérée consisterait à é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 Portail a déjà stocké le fichier ERA contenant l'ensemble 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'archives, même s'il n'y a pas d'autre nœud d'archives en ligne, il pourrait le faire en synchronisant directement depuis le réseau du portail.

( 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 faciles, alors réduire les exigences de stockage historique peut être considéré comme plus important que la sans état : sur les 1,1 To nécessaires pour le nœud, environ 300 Go sont l'état, le reste d'environ 800 Go étant devenu historique. Ce n'est qu'en réalisant la sans état 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 seulement quelques minutes.

La limitation du stockage historique rend également l'implémentation 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 DoS de 2016 ont été supprimés. Puisque la transition vers la preuve d'enjeu est désormais une histoire, les clients peuvent supprimer en toute sécurité tout le code lié à la preuve de travail.

![Vitalik : l'avenir possible d'Ethereum, The Purge])ian/2024/10/27/images/b3e2c5d4e7e1d40234643b84b51b43c1.jpg###

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 d'augmenter, d'environ 50 Go par an, car l'état continue de croître : soldes des comptes et nombres aléatoires, code des contrats et stockage des contrats. Les utilisateurs peuvent payer des frais uniques, ce qui imposera un fardeau permanent 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 suivante : 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 une absence d'état, certains pensent que ce problème n'est peut-être pas si grave : seules les classes de constructeurs de blocs spécialisés doivent réellement stocker l'état, tandis que tous les autres nœuds ), y compris ceux qui génèrent des listes ! ###, 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 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'ÉTH à 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 au fil du temps. Le défi clé est de le faire de manière à atteindre trois objectifs :

Efficacité : Pas besoin d'un grand nombre de 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 sur 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 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. ) 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 avec des dates d'expiration. Cependant, cela introduit des besoins de calcul supplémentaires ( et même des besoins de stockage ), et cela ne peut certainement pas satisfaire 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 compteur de date d'expiration dans la portée du contrat, cela rendrait techniquement la vie des développeurs plus facile, mais cela rendrait 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 sur lesquels la communauté de développement central d'Ethereum s'efforce de travailler depuis des 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 les états expirés partiels
• Suggestions de délai d'expiration de l'é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", où les blocs sont vides ou non vides. Les données dans chaque bloc ne sont stockées que si elles ont été récemment consultées. Il existe un mécanisme de "résurrection", si elles ne sont plus stockées.

![Vitalik : l'avenir possible d'Ethereum, The Purge])