L'avenir possible d'Ethereum : The Purge

Auteur : Vitalik Buterin

Compilation : Comment le faire

Un grand merci pour les retours et les examens de Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden et Tomasz Stanczak.

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 : 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 d'être complètement synchronisés 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 les anciennes, ce qui entraîne une complexité du code qui augmente avec le temps.

Pour que l'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 conserver l'une des propriétés clés qui rendent la blockchain géniale : la durabilité. Vous pouvez placer 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 ressortir 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 convaincus que leurs dépendances ne seront pas mises à niveau de manière à les endommager - en particulier L1 lui-même.

Si nous sommes déterminés à trouver un équilibre entre ces deux besoins et à minimiser ou inverser l'encombrement, la complexité et le déclin tout en maintenant la continuité, c'est tout à fait 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 longévité très longue. Dans certains cas, Ethereum a réussi : la preuve de travail a disparu, le code opération SELFDESTRUCT a en grande partie 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 tendre vers un résultat final stable à long terme est le défi ultime pour l'évolutivité à long terme d'Ethereum, la durabilité technique et même la sécurité.

La Purge : objectifs principaux.

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

État d'expiration（状态到期）

Nettoyage des fonctionnalités

Historique d'expiration

Quel problème résout-il ?

Au moment de la 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 il faut également plusieurs centaines de Go d'espace disque pour le client de consensus. La majorité de cela est historique : des données concernant les blocs, transactions et reçus historiques, 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 la simplification des problèmes de stockage historique est que, étant donné que chaque bloc pointe vers le bloc précédent par un lien de 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 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 fonctionnent les réseaux 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-uns de ces fichiers. Peut-être contre-intuitivement, cette approche ne réduit même pas nécessairement la robustesse des données. Si nous pouvons établir un réseau de 100 000 nœuds en rendant leur fonctionnement plus économique, 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 qu'un réseau de 10 000 nœuds, où chaque nœud stocke tout.

Aujourd'hui, Ethereum a commencé à se libérer du modèle où tous les nœuds stockent en permanence toute l'historique. Les blocs de consensus (c'est-à-dire la partie associée au consensus de preuve de participation) 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 et reçus historiques. L'objectif à long terme est d'établir une période unifiée (probablement d'environ 18 jours), pendant laquelle chaque nœud est responsable du stockage de tout, puis de créer un réseau peer-to-peer 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é soumis à 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 à placer également les données d'exécution et de consensus dans le blob.

Quel est le lien avec les recherches existantes ?

EIP-4444；

Torrents et EIP-4444；

réseau de portail;

Portail réseau et EIP-4444;

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

Comment augmenter la limite de gas (Paradigm).

Que faut-il encore faire, quels compromis doivent être pris ?

Le travail principal restant consiste à construire et à intégrer une solution décentralisé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 consiste à (i) introduire simplement une bibliothèque torrent existante, ainsi qu'à (ii) une solution native d'Ethereum appelée réseau Portal. Une fois que l'un d'eux est introduit, nous pouvons activer 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 en s'attendant à télécharger l'historique complet, mais en réalité ne l'obtenant pas.

Les principaux compromis concernent nos efforts pour fournir des données historiques "anciennes". La solution la plus simple est d'arrêter demain de stocker l'historique ancien 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écurisée consiste d'abord à construire et à intégrer un réseau torrent pour stocker l'historique de manière distribuée. Ici, "combien d'efforts mettons-nous" 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 extrême et paranoïaque pour (1) impliquerait la preuve de garde : exigeant en fait que chaque validateur de preuve de participation stocke un certain pourcentage d'historique et vérifie régulièrement de manière cryptographique s'il le fait. Une approche 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à effectué aujourd'hui : le Portail a déjà stocké les fichiers 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'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 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 non-état : parmi les 1,1 To requis par le nœud, environ 300 Go sont l'état, les 800 Go restants étant devenus historiques. Ce n'est qu'en réalisant la non-état et l'EIP-4444 que la vision de faire fonctionner un nœud Ethereum sur une montre intelligente et de l'installer en quelques minutes pourra être réalisée.

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 (DoS) de 2016 ont été supprimés. Puisque la transition vers la preuve d'enjeu est désormais de l'histoire, les clients peuvent supprimer en toute sécurité tout le code lié à la preuve de travail.

État d'expiration

Quel problème résout-il ?

Même si nous avons éliminé 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 d'augmenter : soldes de compte et nombres aléatoires, code de contrat et stockage de contrat. Les utilisateurs peuvent payer des frais uniques, ce qui alourdit à jamais les 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 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 des types de constructeurs de blocs spécialisés ont réellement besoin de 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 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 et comment ça fonctionne

Aujourd'hui, lorsque vous créez un nouvel objet d'état (cela 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 qui n'a pas é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 de manière à atteindre trois objectifs :

Efficacité : pas besoin d'un grand nombre de calculs supplémentaires pour exécuter le processus d'échéance.

Facilité d'utilisation : si quelqu'un entre dans la grotte pendant cinq ans et revient, il ne devrait pas perdre l'accès à ses positions en Éther, ERC20, NFT et CDP...

Amabilité pour les développeurs : Les développeurs n'ont pas besoin de passer à un modèle de pensée complètement inconnu. De plus, les applications qui sont actuellement rigides et non mises à jour devraient 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 (qui 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 avoir un processus pour parcourir les états afin de supprimer les objets d'état avec des dates d'expiration. Cependant, cela introduit un calcul supplémentaire (voire des besoins 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 où les valeurs stockées sont parfois réinitialisées à zéro. Si vous définissez un minuteur d'expiration dans le cadre 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 "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 "location 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 partiels expirés
• Suggestions de date 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 en permanence le "mapping de niveau supérieur", dans lequel