Vitalik : 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 à deux endroits :

Données historiques : Toutes les transactions effectuées à tout moment dans le passé et tous les comptes créés 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 charge pour les clients et un temps de synchronisation qui augmentent avec le temps, même si la capacité de la chaîne reste constante.

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é croissante du code au fil du temps.

Pour que l'Ethereum puisse survivre à 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 caractéristiques clés qui rendent la blockchain formidable : la pérennité. Vous pouvez mettre 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 constater 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 à niveau, ils doivent être sûrs que leurs dépendances ne seront pas mises à niveau de manière destructrice - en particulier L1 lui-même.

S'il nous plaît de prendre la décision de trouver un équilibre entre ces deux besoins et de minimiser ou d'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 durée de vie très longue. Dans certains cas, Ethereum a déjà réussi : la preuve de travail a disparu, l'opcode SELFDESTRUCT a disparu pour la plupart, et les nœuds de la chaîne de balises ont stocké jusqu'à six mois de données anciennes. 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 la nécessité pour chaque nœud de conserver de manière permanente tous les historiques ou même l'état final.

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

Table des matières :

Expiration de l'historique（历史记录到期）

État d'expiration（状态到期）

Nettoyage des caractéristiques

Expiration de l'historique

résout quel problème ?

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 en plus plusieurs centaines de Go d'espace disque 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 et comment ça fonctionne ?

Une caractéristique clé de la simplification du problème de stockage historique est que, puisque chaque bloc pointe vers le bloc précédent par des liens 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 individuel ainsi que par 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 stocke et distribue des millions de fichiers au total, chaque participant ne stocke et ne distribue que quelques-uns de ces fichiers. Peut-être à la surprise de certains, cette méthode 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 où chaque nœud stocke 10 % de l'historique de manière aléatoire en rendant l'exécution des nœuds plus économique, alors chaque donnée sera copiée 10 000 fois - ce qui est exactement le même facteur de réplication 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 en permanence tout l'historique. Les blocs de consensus (c'est-à-dire la partie liée à la preuve de participation) ne conservent que pendant environ 6 mois. Les Blobs ne sont conservé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 ê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, où les anciennes données seraient stocké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à utilisé des codes d'effacement pour soutenir l'échantillonnage de disponibilité des données. La solution la plus simple sera probablement de réutiliser ces codes d'effacement et d'inclure également les données 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 Portal;

Comment augmenter la limite de gas (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 les historiques ------ 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) appelée solution native d'Ethereum connue sous le nom de réseau Portal. Une fois que l'une d'entre elles est 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 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 ne l'obtenant en réalité pas.

Les principaux compromis concernent la manière dont nous nous efforçons de fournir des données historiques "anciennes". La solution la plus simple est d'arrêter demain de stocker les anciennes données historiques 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 consiste d'abord à construire et à intégrer un réseau torrent pour stocker l'historique de manière distribuée. Ici, "combien nous nous efforçons" a deux dimensions :

Comment travaillons-nous pour nous assurer que le plus grand ensemble de nœuds stocke effectivement toutes les données ?

Quelle est la profondeur d'intégration de l'historique des stockages dans le protocole ?

Une méthode d'extrême paranoïa pour (1) impliquerait une preuve de garde : en réalité, exigeant que chaque validateur de preuve de participation stocke une certaine proportion d'historique et vérifie régulièrement de manière cryptographique s'il le fait. Une approche 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 portail a déjà stocké un fichier ERA contenant l'historique complet 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 sans d'autres nœuds d'archives en ligne, il puisse le faire par synchronisation directe 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 facile, il est dit que réduire les exigences de stockage historique est plus important que la sans-état : parmi les 1,1 To nécessaires au nœud, environ 300 Go sont l'état, le reste, soit environ 800 Go, est devenu historique. Ce n'est qu'en réalisant la sans-é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 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 pendant l'attaque DoS de 2016 ont été supprimés. Maintenant que la transition vers le Proof of Stake est devenue historique, les clients peuvent supprimer en toute sécurité tout le code lié au Proof of Work.

Expiration de l'état

résout quel problème ?

Même si nous avons éliminé 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 de comptes et nombres aléatoires, code de contrat et stockage de contrat. Les utilisateurs peuvent payer des frais uniques, ce qui impose un fardeau permanent aux clients Ethereum présents 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 existera toujours et pourra être lu à tout moment par n'importe quelle transaction. Si nous introduisons la non-é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 besoin de stocker réellement l'état, tandis que tous les autres nœuds (y compris ceux générant des listes !) peuvent fonctionner sans état. Cependant, il y a un point de vue selon lequel nous ne voulons pas trop dépendre de la non-é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 (ce qui peut se produire de l'une des trois manières suivantes : (i) en envoyant de l'ETH à un nouveau compte, (ii) en créant un nouveau compte avec du code, (iii) en configurant un emplacement de stockage qui n'a pas été touché auparavant), cet objet d'état reste dans cet état indéfiniment. En revanche, ce que nous voulons, c'est que l'objet expire automatiquement au fil du temps. Le principal défi est de le faire de manière à atteindre trois objectifs :

Efficacité : il n'est pas nécessaire d'effectuer 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 ETH, 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 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 pourriez 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 qui parcourt l'état pour supprimer les objets d'état dont la date d'expiration est dépassée. Cependant, cela introduit des calculs supplémentaires (voire des besoins de stockage), et cela ne peut certainement pas satisfaire les exigences de convivialité. Les développeurs ont également du mal à raisonner sur les cas limites où les valeurs de stockage 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 compliquera l'économie : 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 que la communauté de développement central d'Ethereum s'efforce de résoudre depuis de nombreuses années, y compris des propositions telles que "loyer blockchain" et "régénération". Finalement, nous avons combiné les meilleures parties des propositions et nous nous sommes concentrés sur deux types de "solutions connues comme étant les moins mauvaises" :

• Solutions pour certains états expirés
• 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 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, si elles ne sont plus stockées.

La principale différence entre ces propositions est : (i) comment nous définissons "