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

L'objectif principal de The Purge:

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

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 plusieurs centaines de Go d'espace disque pour le client de consensus. La grande majorité de ces données sont historiques : 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 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 la simplification des problèmes de stockage historique est que, puisque chaque bloc est lié par un hachage ( et d'autres structures ) au bloc précédent, il suffit d'atteindre un consensus sur le présent pour atteindre un consensus sur l'historique. Tant que le réseau parvient à un consensus sur le dernier bloc, n'importe quel bloc ou transaction historique ou état ( solde de compte, nombre aléatoire, code, stockage ) peut être fourni par n'importe quel participant unique ainsi qu'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 fonctionne le réseau de graines 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 approche 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 10 % de l'historique de manière aléatoire, alors chaque donnée sera copiée 10 000 fois - exactement le même facteur de duplication 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 définitivement toute l'historique. Le bloc de consensus ( associé à la partie liée au consensus de preuve d'enjeu ne stocke que pendant environ 6 mois. Les Blob 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, ) pouvant être d'environ 18 jours, pendant laquelle chaque nœud est 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.

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, les blobs ont déjà utilisé 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 les données d'exécution et de consensus des blocs dans le blob.

( Que faut-il encore faire, quelles considérations doivent être prises en compte ?

Le travail principal restant consiste à construire et à intégrer une solution distribuée concrète pour stocker les historiques ------ au moins les historiques d'exécution, 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'un ou l'autre introduit, nous pouvons activer 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 pour tous les clients en même temps, sinon il existe un risque que les clients échouent en s'attendant à télécharger l'historique complet en se connectant à d'autres nœuds, 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 serait d'arrêter de stocker l'historique ancien demain et de 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 voie plus difficile mais plus sûre serait de d'abord construire et d'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 :

1. Comment nous efforçons-nous de garantir que le plus grand ensemble de nœuds stocke bien toutes les données ?

2. Quelle est la profondeur de l'intégration de l'historique de stockage dans le protocole?

Une méthode extrêmement paranoïaque pour ( impliquerait la preuve de garde : exigeant en fait que chaque validateur de preuve d'enjeu stocke un certain pourcentage de l'historique et vérifie régulièrement de manière cryptographique s'il le fait. Une méthode plus douce serait de fixer 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 déjà stocké des fichiers ERA contenant l'ensemble de l'historique d'Ethereum. Une mise en œuvre plus complète 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 si aucun autre nœud d'archivage n'est en ligne, il peut le faire par synchronisation directe via le 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 est sans doute plus important que la non-état : parmi les 1,1 To nécessaires pour le nœud, environ 300 Go sont l'état, et les 800 Go restants sont devenus historiques. Ce n'est qu'en réalisant la non-état et l'EIP-4444 que nous pourrons concrétiser la vision de faire fonctionner un nœud Ethereum sur une montre intelligente et de pouvoir le configurer en quelques minutes.

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

Expiration de l'état

résout quel problème?

Même si nous éliminons le besoin de stocker l'historique côté client, les besoins de stockage du client continueront à 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 alourdit définitivement le fardeau pour les 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 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 : seules des classes de constructeurs de blocs spécialisés doivent réellement 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 à l'aide de code, ) iii ( définir 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 de manière à atteindre trois objectifs :

• Efficacité : pas besoin de beaucoup de calculs supplémentaires pour exécuter le processus d'expiration.

• Convivialité: 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...

• Convivialité pour les développeurs : les développeurs ne doivent 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.

Il est 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 de boucle pour parcourir l'état afin de supprimer les objets d'état avec une date d'expiration. Cependant, cela introduit des besoins de calcul supplémentaires ) et même des exigences 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 impliquant des valeurs de stockage qui 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 telles que "la rente blockchain" et "la régénération". En fin de compte, 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
• Recommandations sur l'expiration de l'état basé sur le cycle d'adresse.

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

)# Expiration partielle de l'état

Certaines propositions d'état d'expiration suivent les mêmes principes. Nous divisons l'état en blocs. Chacun stocke de manière permanente la "carte principale", 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" 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 s'appuie 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 ce design, 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 octets. Dans de nombreux cas, l'ensemble de l'en-tête et du code d'un compte ainsi que de nombreux emplacements de stockage de clés seront stockés sous la même tige. Si les données sous une tige donnée ne sont pas lues ou écrites dans les 6 mois, ces données ne sont plus stockées, mais seulement un engagement de 32 octets des données, un "stub" ). Les transactions futures pour accéder à ces données devront "réveiller" les données et fournir une preuve de vérification selon 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 facteurs d'incitation, cela devient plus délicat : les attaquants peuvent "mettre à jour l'arbre" en insérant une grande quantité de données dans un seul sous-arbre et en envoyant une seule transaction par an, contraignant ainsi 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 insérant une grande quantité de données dans le même sous-arbre qu'eux. On peut essayer de limiter ces deux problèmes en dynamisant la granularité en fonction de la taille du sous-arbre : par exemple, chaque 216= 65536 objets d'état consécutifs peuvent être considérés comme un "groupe". Cependant, ces idées sont plus complexes ; la méthode basée sur les tiges est simple et peut ajuster les incitations, car généralement la tige.