L'un des défis d'Ethereum est que par défaut, toute la boursouflure et la complexité du protocole de la blockchain augmentent avec le temps. Cela se produit à deux endroits :

• Données historiques: toute transaction effectuée et tout compte créé à un moment donné de l'histoire doit être stockée par tous les clients pour toujours, et téléchargée par tout nouveau client effectuant une synchronisation complète avec le réseau. Cela entraîne une charge et un temps de synchronisation croissants pour les clients au fil du temps, même si la capacité de la chaîne reste la même.
• Caractéristiques du protocole : il est beaucoup plus facile d'ajouter une nouvelle fonctionnalité que de supprimer une ancienne, ce qui entraîne une complexité croissante du code au fil du temps.

Pour qu'Ethereum puisse se maintenir à long terme, nous avons besoin d'une forte contre-pression contre ces deux tendances, réduisant la complexité et le gonflement au fil du temps. Mais en même temps, nous devons préserver l'une des principales propriétés qui rendent les blockchains formidables : leur permanence. Vous pouvez mettre un NFT, une note d'amour dans les données de transaction, ou un contrat intelligent contenant un million de dollars onchain, aller dans une grotte pendant dix ans, en ressortir et le trouver toujours là, en attente que vous le lisiez et interagissiez avec. Pour que les dapps se sentent à l'aise pour devenir entièrement décentralisées et supprimer leurs clés de mise à niveau, elles doivent être convaincues que leurs dépendances ne vont pas être mises à niveau de manière à les casser - en particulier la L1 elle-même.

La Purge, feuille de route 2023.

Il est tout à fait possible de concilier ces deux besoins, de réduire ou d'inverser l'enflure, la complexité et la dégradation tout en préservant la continuité, si nous nous y mettons vraiment. Les organismes vivants peuvent le faire : alors que la plupart vieillissent avec le temps,quelques chanceux ne le font pas. Même les systèmes sociaux peuvent avoir une longévité extrême. À plusieurs reprises, Ethereum a déjà montré des succès : la preuve de travail a disparu, l'opcode SELFDESTRUCT a en grande partie disparu, et les nœuds de la chaîne de balises stockent déjà d'anciennes données jusqu'à seulement six mois. Trouver cette voie pour Ethereum de manière plus généralisée, et avancer vers un résultat final stable à long terme, est le défi ultime de la scalabilité à long terme, de la durabilité technique et même de la sécurité d'Ethereum.

La Purge: objectifs clés

• Réduire les besoins de stockage du client en réduisant ou en supprimant le besoin pour chaque nœud de stocker en permanence tout l'historique, et peut-être même éventuellement l'état
• Réduire la complexité du protocole en éliminant les fonctionnalités inutiles

Dans ce chapitre

• Expiration de l'historique
• Expiration d'état
• Nettoyage des fonctionnalités

Expiration de l'historique

Quel problème cela résout-il ?

Au moment de la rédaction de cet article, un nœud Ethereum entièrement synchronisé nécessiteenviron 1,1 téraoctetsd'espace disque pour leclient d'exécution, plus quelques centaines de gigaoctets supplémentaires pour le client de consensus. La grande majorité de cela est de l'histoire : des données sur les blocs historiques, les transactions et les reçus, la majeure partie étant vieille de plusieurs années. Cela signifie que la taille d'un nœud ne cesse d'augmenter de plusieurs centaines de gigaoctets chaque année, même si la limite de gaz n'augmente pas du tout.

Qu'est-ce que c'est et comment ça marche?

Une caractéristique clé simplifiant le problème de stockage de l'historique est que chaque bloc pointe vers le bloc précédent via un lien de hachage (et autre structures)，avoir consensus sur le présent suffit à avoir consensus sur l'histoire. Tant que le réseau a consensus sur le dernier bloc, tout bloc, transaction ou état historique (solde du compte, nonce, code, stockage) peut être fourni par n'importe quel acteur unique avec une preuve de Merkle, et la preuve permet à quiconque d'en vérifier la justesse. Alors que le consensus est un modèle de confiance N/2-sur-N, l'histoire est un Modèle de confiance 1-sur-N.

Cela ouvre de nombreuses options pour la façon dont nous pouvons stocker l'historique. Une option naturelle est un réseau où chaque nœud ne stocke qu'un petit pourcentage des données. C'est ainsi que les réseaux de torrents ont fonctionné pendant des décennies : alors que le réseau stocke et distribue des millions de fichiers, chaque participant n'en stocke et n'en distribue que quelques-uns. Peut-être de manière contre-intuitive, cette approche ne diminue même pas nécessairement la robustesse des données. Si, en rendant le fonctionnement des nœuds plus abordable, nous pouvons arriver à un réseau de 100 000 nœuds, où chaque nœud stocke au hasard 10 % de l'historique, alors chaque pièce de données serait répliquée 10 000 fois - exactement le même facteur de réplication qu'un réseau de 10 000 nœuds où chaque nœud stocke tout.

Aujourd'hui, Ethereum a déjà commencé à s'éloigner du modèle où tous les nœuds stockent toute l'histoire pour toujours. Les blocs de consensus (c'est-à-dire les parties liées au consensus de preuve d'enjeu) ne sont stockés que pendant environ 6 mois. Les blobs ne sont stockés que pendant environ 18 jours.EIP-4444vise à introduire une période de stockage d'un an pour les blocs et les reçus historiques. L'objectif à long terme est d'avoir une période harmonisée (qui pourrait être d'environ 18 jours) pendant laquelle chaque nœud est responsable de tout stocker, puis d'avoir un réseau pair à pair composé de nœuds Ethereum stockant les données plus anciennes de manière distribuée.

Les codes d'effacement peuvent être utilisés pour augmenter la robustesse tout en maintenant le même facteur de réplication. En fait, les blocs sont déjà codés en effacement afin de prendre en charge l'échantillonnage de disponibilité des données. La solution la plus simple pourrait bien être de réutiliser ce codage en effacement et de placer également les données de bloc d'exécution et de consensus dans des blocs.

Quels sont quelques liens vers des recherches existantes?

• EIP-4444: https://eips.ethereum.org/EIPS/eip-4444
• Torrents et EIP-4444: https://ethresear.ch/t/torrents-and-eip-4444/19788
• Réseau Portal: https://ethereum.org/fr/developers/docs/networking-layer/portal-network/
• Réseau de portail et EIP-4444: https://github.com/ethereum/portal-network-specs/issues/308
• Stockage et récupération distribués d'objets SSZ dans Portal: https://ethresear.ch/t/distributed-storage-and-cryptographically-secured-retrieval-of-ssz-objects-for-portal-network/19575
• Comment augmenter la limite de gaz (Paradigm) :https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

Qu'est-ce qui reste à faire, et quels sont les compromis ?

Le principal travail restant consiste à construire et à intégrer une solution distribuée concrète pour le stockage de l’historique - au moins l’historique d’exécution, mais finalement aussi le consensus et les blobs. Les solutions les plus simples pour cela sont (i) d’introduire simplement une bibliothèque torrent existante, et (ii) une solution native d’Ethereum appelée le réseau Portal. Une fois que l'un de ceux-ci est introduit, nous pouvons activer EIP-4444. EIP-4444 lui-même ne nécessite pas de hard fork, mais il nécessite une nouvelle version de protocole réseau. Pour cette raison, il est utile de l'activer pour tous les clients en même temps, sinon il y a des risques de dysfonctionnement des clients en se connectant à d'autres nœuds s'attendant à télécharger l'historique complet mais ne le recevant pas réellement.

Le principal compromis concerne la façon dont nous nous efforçons de rendre les données historiques "anciennes" disponibles. La solution la plus simple serait de cesser simplement de stocker l'histoire ancienne demain et de compter 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. Le chemin le plus difficile, mais plus sûr, consiste d'abord à développer et à intégrer le réseau torrent pour stocker l'histoire de manière distribuée. Ici, il y a deux dimensions de "la difficulté de notre effort":

1. À quel point nous efforçons-nous de nous assurer qu'un ensemble de nœuds maximalement large stocke réellement toutes les données?
2. Dans quelle mesure intégrons-nous profondément le stockage historique dans le protocole?

Une approche maximale paranoïaque pour (1) impliqueraitpreuve de gardeen fait, exigeant que chaque validateur de preuve d'enjeu stocke un certain pourcentage d'historique et vérifie régulièrement de manière cryptographique qu'ils le font. Une approche plus modérée consiste à établir une norme volontaire pour le pourcentage d'historique que chaque client stocke.

Pour (2), une implémentation de base consiste simplement à prendre le travail qui est déjà fait aujourd'hui: Portal stocke déjà des fichiers ERA contenant toute l'histoire d'Ethereum. Une implémentation plus approfondie consisterait à réellement connecter cela au processus de synchronisation, de sorte que si quelqu'un voulait synchroniser un nœud stockant l'historique complet ou un nœud d'archive, il pourrait le faire même s'il n'y avait pas d'autres nœuds d'archive en ligne, en se synchronisant directement depuis le réseau Portal.

Comment interagit-il avec les autres parties de la feuille de route?

Réduire les besoins de stockage de l'historique est sans doute encore plus important que l'absence d'état si nous voulons faciliter au maximum l'exécution ou la mise en service d'un nœud : sur les 1,1 To nécessaires à un nœud, environ 300 Go sont dédiés à l'état et les 800 Go restants à l'historique. La vision d'un nœud Ethereum fonctionnant sur une montre connectée et se configurant en quelques minutes seulement est réalisable uniquement si l'absence d'état et l'EIP-4444 sont mis en œuvre.

La limitation du stockage de l'historique le rend également plus viable pour les nouvelles implémentations de nœuds Ethereum qui ne prennent en charge que les versions récentes du protocole, ce qui les rend beaucoup plus simples. Par exemple, de nombreuses lignes de code peuvent être supprimées en toute sécurité maintenant que tous les emplacements de stockage vides créés lors des attaques DoS de 2016 ont été supprimés.supprimé. Maintenant que le passage à la preuve d'enjeu est de l'histoire ancienne, les clients peuvent en toute sécurité supprimer tout code lié à la preuve de travail.

Expiration de l'état

Quel problème résout-il?

Même si nous supprimons le besoin pour les clients de stocker l'historique, les besoins en stockage d'un client continueront de croître, d'environ 50 Go par an, en raison de la croissance continue de l'état : soldes des comptes et nonces, code de contrat et stockage de contrat. Les utilisateurs sont en mesure de payer un coût unique pour imposer une charge aux clients Ethereum présents et futurs pour toujours.

L'État est beaucoup plus difficile à « expirer » que l'histoire, car l'EVM est fondamentalement conçue autour de l'hypothèse qu'une fois qu'un objet d'état est créé, il sera toujours là et pourra être lu par n'importe quelle transaction à tout moment. Si nous introduisons la non-statalité, il y a un argument selon lequel peut-être ce problème n'est pas si grave : seule une classe spécialisée de constructeurs de blocs aurait besoin de stocker réellement l'état, et tous les autres nœuds (mêmeliste d'inclusion production!) peut fonctionner de manière étatique. Cependant, il y a un argument selon lequel nous ne voulons pas trop compter sur l'état de non-état, et éventuellement nous voudrons peut-être expirer l'état afin de maintenir Ethereum décentralisé.

Qu'est-ce que c'est, et comment cela fonctionne-t-il?

Aujourd'hui, lorsque vous créez un nouvel objet d'état (ce qui peut se produire de trois manières : (i) envoyer de l'ETH à un nouveau compte, (ii) créer un nouveau compte avec un code, (iii) définir un emplacement de stockage précédemment inutilisé), cet objet d'état reste en état pour toujours. Ce que nous voulons plutôt, c'est que les objets expirent automatiquement avec le temps. Le défi clé est de le faire d'une manière qui réalise trois objectifs :

1. Efficacité : ne nécessite pas de grandes quantités de calculs supplémentaires pour exécuter le processus d'expiration
2. Convivialité : si quelqu'un entre dans une grotte pendant cinq ans et revient, il ne devrait pas perdre l'accès à son ETH, ERC20, NFT, positions CDP...
3. Convivialité pour les développeurs : les développeurs ne devraient pas avoir à passer à un modèle mental complètement inconnu. De plus, les applications figées aujourd'hui qui ne sont pas mises à jour devraient continuer à fonctionner raisonnablement bien.

Il est facile de résoudre le problème sans atteindre ces objectifs. Par exemple, vous pouvez faire en sorte que chaque objet d’état stocke également un compteur pour sa date d’expiration (qui peut être prolongée en brûlant de l’ETH, ce qui peut se produire automatiquement chaque fois qu’il est lu ou écrit), et avoir un processus qui parcourt l’état pour supprimer les objets d’état expirés. Cependant, cela introduit des calculs supplémentaires (et même des exigences de stockage), et cela ne répond certainement pas à l’exigence de convivialité. Les développeurs auraient également du mal à raisonner sur les cas limites impliquant des valeurs de stockage parfois réinitialisées à zéro. Si vous fixez le délai d’expiration à l’ensemble du contrat, cela facilite techniquement la vie des développeurs, mais cela rend l’économie plus difficile : les développeurs devraient réfléchir à la manière de « répercuter » les coûts permanents du stockage sur leurs utilisateurs.

Ce sont des problèmes auxquels la communauté de développement de base d'Ethereum a lutté pendant de nombreuses années, y compris des propositions comme “location de la chaîne de blocsetregenesis« Finalement, nous avons combiné les meilleures parties des propositions et convergé vers deux catégories de « solutions connues les moins mauvaises » :

• Solutions partielles d'expiration d'état
• Propositions d’expiration d’état basées sur la période d’adresse.

Expiration partielle de l'état

Toutes les propositions d'expiration d'état partiel fonctionnent sur le même principe. Nous divisons l'état en morceaux. Tout le monde stocke de manière permanente la "carte de niveau supérieur" des morceaux vides ou non vides. Les données à l'intérieur de chaque morceau sont stockées uniquement si ces données ont été récemment consultées. Il existe un mécanisme de "résurrection" où si un morceau n'est plus stocké, n'importe qui peut ramener ces données en fournissant une preuve de ce que les données étaient.

Les principales distinctions entre ces propositions sont : (i) comment définissons-nous "récemment", et (ii) comment définissons-nous "chunk" ? Une proposition concrète est EIP-7736, qui s'appuie sur la conception « tige-et-feuille » introduit pour les arbres Verkle (bien qu'il soit compatible avec toutes les formes de non-état, par exemple les arbres binaires). Dans cette conception, les en-têtes, les codes et les emplacements de stockage qui se trouvent à côté les uns des autres sont stockés sous la même « branche ». Les données stockées sous une branche peuvent être au maximum de 256 * 31 = 7 936 octets. Dans de nombreux cas, l'intégralité de l'en-tête et du code, ainsi que de nombreux emplacements de stockage clés, d'un compte seront tous stockés sous la même branche. Si les données sous une branche donnée ne sont pas lues ou écrites pendant 6 mois, les données ne sont plus stockées et seule une attestation de 32 octets (« ébauche ») des données est stockée. Les transactions futures qui accèdent à ces données devraient « ressusciter » les données, avec une preuve qui serait vérifiée par rapport à l'ébauche.

Il existe d'autres moyens de mettre en œuvre une idée similaire. Par exemple, si la granularité au niveau du compte n'est pas suffisante, nous pourrions mettre en place un système où chaque fraction 1/232 de l'arbre est régi par un mécanisme similaire de tige et de feuille.

C'est plus délicat en raison des incitations : un attaquant pourrait forcer les clients à stocker en permanence une très grande quantité d'état en mettant une très grande quantité de données dans un seul sous-arbre et en envoyant une seule transaction chaque année pour 'renouveler l'arbre'. Si vous faites en sorte que le coût de renouvellement soit proportionnel (ou la durée de renouvellement inversement proportionnelle) à la taille de l'arbre, alors quelqu'un pourrait nuire à un autre utilisateur en mettant une très grande quantité de données dans le même sous-arbre qu'eux. On pourrait essayer de limiter ces deux problèmes en rendant la granularité dynamique en fonction de la taille du sous-arbre : par exemple, chaque groupe de 216 = 65536 objets d'état consécutifs pourrait être traité comme un 'groupe'. Cependant, ces idées sont plus complexes ; l'approche basée sur la tige est simple et elle aligne les incitations, car généralement toutes les données sous une tige sont liées à la même application ou au même utilisateur.

Propositions d'expiration de l'état basées sur l'adresse et la période

Et si nous voulions éviter toute croissance permanente de l'état, même les pointeurs de 32 octets ? C'est un problème difficile en raison de...@vbuterin/state_size_management#Resurrection-conflicts">conflits de résurrection : que se passe-t-il si un objet d’état est supprimé, l’exécution ultérieure d’EVM met un autre objet d’état exactement dans la même position, mais qu’après cela, quelqu’un qui se soucie de l’objet d’état d’origine revient et essaie de le récupérer ? En cas d’expiration partielle de l’état, le « stub » empêche la création de nouvelles données. Avec l’expiration complète de l’État, nous ne pouvons pas nous permettre de stocker même le talon.

La conception basée sur la période d’adresse est l’idée la plus connue pour résoudre ce problème. Au lieu d’avoir un arbre d’état stockant l’ensemble de l’état, nous avons une liste d’arbres d’état qui ne cesse de s’allonger, et tout état qui est lu ou écrit est enregistré dans l’arbre d’état le plus récent. Un nouvel arbre d’état vide est ajouté une fois par période (pensez : 1 an). Les arbres d’état plus anciens sont gelés. Les nœuds complets ne sont censés stocker que les deux arbres les plus récents. Si un objet d’état n’a pas été touché pendant deux périodes et tombe donc dans une arborescence expirée, il peut toujours être lu ou écrit, mais la transaction devra prouver une preuve de Merkle pour cela - et une fois qu’elle l’aura fait, une copie sera à nouveau enregistrée dans la dernière arborescence.

Une idée clé pour rendre tout cela convivial pour les utilisateurs et les développeurs est le concept de périodes d'adresse. Une période d'adresse est un nombre faisant partie d'une adresse. Une règle clé est qu'une adresse avec une période d'adresse N ne peut être lue ou écrite qu'au cours ou après la période N (c'est-à-dire lorsque la liste d'arbre d'état atteint la longueur N). Si vous enregistrez un nouvel objet d'état (par exemple, un nouveau contrat, ou un nouveau solde ERC20), si vous vous assurez de mettre l'objet d'état dans un contrat dont la période d'adresse est soit N soit N-1, alors vous pouvez l'enregistrer immédiatement, sans avoir besoin de fournir des preuves qu'il n'y avait rien avant. Toute addition ou modification de l'état dans des périodes d'adresse plus anciennes, en revanche, nécessite une preuve.

Ce design préserve la plupart des propriétés actuelles d'Ethereum, est très léger en calculs supplémentaires, permet aux applications d'être écrites presque comme elles le sont aujourd'hui (les ERC20 devront être réécrits, pour garantir que les soldes des adresses avec la période d'adresse N sont stockés dans un contrat enfant qui a lui-même la période d'adresse N), et résout le problème de la "cave pour cinq ans". Cependant, il a un gros problème : les adresses doivent être étendues au-delà de 20 octets pour s'adapter aux périodes d'adresse.

Extension de l'espace d'adressage

Une proposition consiste à introduire un nouveau format d'adresse de 32 octets, qui comprend un numéro de version, un numéro de période d'adresse et un hash étendu.

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

Le rouge est un numéro de version. Les quatre zéros colorés en orange ici sont destinés à représenter un espace vide, qui pourrait contenir un numéro de fragment à l'avenir. Le vert est un numéro de période d'adresse. Le bleu est un hachage de 26 octets.

Le défi clé ici est la compatibilité ascendante. Les contrats existants sont conçus autour d'adresses de 20 octets et utilisent souvent des techniques serrées d'empaquetage d'octets qui supposent explicitement que les adresses font exactement 20 octets de long.@ipsilon/address-space-extension-exploration">Une idée pour résoudre ce problème implique une carte de traduction, où les contrats de l’ancien style interagissant avec des adresses de nouveau style verraient un hachage de 20 octets de l’adresse du nouveau style. Cependant, il existe des complexités importantes pour rendre cela sûr.

Rétrécissement de l'espace d'adressage

Une autre approche va dans la direction opposée : nous interdisons immédiatement une sous-plage de taille 2128 (par exemple toutes les adresses commençant par 0xffffffff), puis utilisons cette plage pour introduire des adresses avec des périodes d'adresses et des hachages de 14 octets.

0xfffffff000169125d5dFcb7B8C2659029395bdF

Le principal sacrifice que fait cette approche, c’est qu’elle introduit des risques de sécurité pour les adresses contrefaites: les adresses qui détiennent des actifs ou des autorisations, mais dont le code n'a pas encore été publié sur la chaîne. Le risque consiste en ce que quelqu'un crée une adresse qui prétend avoir un morceau de code (pas encore publié), mais qui a également un autre morceau de code valide qui a la même empreinte que l'adresse. Calculer une telle collision nécessite 2⁸⁰hachages aujourd'hui; la contraction de l'espace d'adressage réduirait ce nombre à un 2 très accessible⁵⁶hachages.

La zone de risque clé, les adresses contrefactuelles qui ne sont pas des portefeuilles détenus par un seul propriétaire, est un cas relativement rare aujourd'hui, mais il est probable qu'il deviendra plus courant à mesure que nous entrerons dans un monde multi-L2. La seule solution est d'accepter simplement ce risque, mais d'identifier tous les cas d'utilisation courants où cela pourrait poser un problème et de trouver des solutions de contournement efficaces.

Quels sont quelques liens vers des recherches existantes?

• Premières propositions
  • Location de blockchain: https://github.com/ethereum/EIPs/issues/35
  • Regenesis: https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582
• Une théorie de la gestion de la taille de l'état Ethereum :@vbuterin/state_size_management"">https://hackmd.io/@vbuterin/state_size_management
• Quelques chemins possibles vers la non-appartenance à un État et l'expiration de l'État : @vbuterin/state_expiry_paths"">https://hackmd.io/@vbuterin/state_expiry_paths
• Propositions d'expiration partielle de l'état
  • EIP-7736: https://eips.ethereum.org/EIPS/eip-7736
• Documents d'extension d'espace d'adressage
  • Proposition originale :https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485
  • Revue Ipsilon: @ipsilon/address-space-extension-exploration"">https://notes.ethereum.org/@ipsilon/address-space-extension-exploration
  • Revue de l'article de blog: @chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6"">https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6
• Qu'est-ce qui se casserait si nous perdions la résistance aux collisions: https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

Que reste-t-il à faire et quels sont les compromis ?

Je vois quatre voies viables pour l'avenir :

• Nous pratiquons l'état sans état et n'introduisons jamais d'expiration d'état. L'état est en constante croissance (bien que lentement : nous pourrions ne pas le voir dépasser 8 To pendant des décennies), mais il n'a besoin d'être détenu que par une classe relativement spécialisée d'utilisateurs : même les validateurs de PoS n'auraient pas besoin de l'état.
  \
  La seule fonction qui a besoin d'accéder à certaines parties de l'état est la production de la liste d'inclusion, mais nous pouvons accomplir cela de manière décentralisée : chaque utilisateur est responsable de la maintenance de la partie de l'arbre d'état qui contient ses propres comptes. Lorsqu'ils diffusent une transaction, ils la diffusent avec une preuve des objets d'état auxquels ils ont accédé lors de l'étape de vérification (cela fonctionne à la fois pour les EOAs et les comptes ERC-4337). Les validateurs sans état peuvent ensuite combiner ces preuves en une preuve pour l'ensemble de la liste d'inclusion.
• Nous effectuons une expiration partielle de l'état et acceptons un taux de croissance de la taille de l'état permanent beaucoup plus faible mais toujours non nul. Ce résultat est sans doute similaire à la façon dont les propositions d'expiration de l'historique impliquant des réseaux pair à pair acceptent un taux de croissance de stockage de l'historique permanent beaucoup plus faible mais toujours non nul à partir de chaque client devant stocker un pourcentage faible mais fixe des données historiques.
• Nous faisons l’expiration de l’état, avec l’expansion de l’espace d’adressage. Cela impliquera un processus pluriannuel visant à s’assurer que l’approche de conversion du format d’adresse fonctionne et est sûre, y compris pour les applications existantes.
• Nous effectuons l'expiration de l'état, avec contraction de l'espace d'adressage. Il s'agira d'un processus pluriannuel visant à garantir que tous les risques de sécurité liés aux collisions d'adresses, y compris les situations inter-chaînes, sont gérés.

Un point important est que les problèmes difficiles liés à l'expansion et à la contraction de l'espace d'adressage devront finalement être abordés, que les schémas d'expiration de l'état qui dépendent des changements de format d'adresse soient ou non mis en œuvre. Aujourd'hui, cela prend environ 2⁸⁰hachages pour générer une collision d'adresse, une charge computationnelle déjà réalisable pour des acteurs extrêmement bien dotés : un GPU peut faire environ 2²⁷hachages, donc en le faisant fonctionner pendant un an, il peut calculer 2⁵², donc tout ~2^30 GPU dans le mondepourrait calculer une collision en ~1/4 d'année, et les FPGAs et les ASICs pourraient accélérer cela davantage. À l'avenir, de telles attaques seront accessibles à de plus en plus de personnes. Par conséquent, le coût réel de la mise en œuvre de l'expiration complète de l'état peut ne pas être aussi élevé qu'il semble, car nous devons résoudre ce problème d'adresse très difficile quoi qu'il en soit.

Comment interagit-il avec les autres parties de la feuille de route?

La réalisation de l'expiration de l'état rend potentiellement les transitions d'un format d'arbre d'état à un autre plus faciles, car il n'y aura pas besoin de procédure de transition : vous pourriez simplement commencer à créer de nouveaux arbres en utilisant un nouveau format, puis effectuer ultérieurement une bifurcation dure pour convertir les anciens arbres. Ainsi, bien que l'expiration de l'état soit complexe, elle présente des avantages en simplifiant d'autres aspects de la feuille de route.

Nettoyage des fonctionnalités

Quels problèmes cela résout-il?

L'une des conditions préalables clés de la sécurité, de l'accessibilité et neutralité crédibleC'est la simplicité. Si un protocole est beau et simple, cela réduit les chances qu'il y ait des bugs. Cela augmente la possibilité que de nouveaux développeurs puissent intervenir et travailler avec n'importe quelle partie. Il est plus probable d'être juste et plus facile à défendre contre les intérêts spéciaux. Malheureusement, les protocoles, comme tout système social, deviennent par défaut de plus en plus complexes avec le temps. Si nous ne voulons pas qu'Ethereum tombe dans un trou noir de complexité croissante, nous devons faire l'une des deux choses suivantes : (i) arrêter de faire des changements et ossifier le protocole, (ii) être capable de réellement supprimer des fonctionnalités et réduire la complexité. Une voie intermédiaire, consistant à apporter moins de modifications au protocole et à supprimer au moins un peu de complexité avec le temps, est également possible. Cette section expliquera comment nous pouvons réduire ou supprimer la complexité.

Qu'est-ce que c'est et comment ça marche?

Il n'y a pas de solution unique qui puisse réduire la complexité du protocole; la nature inhérente du problème est qu'il y a de nombreuses petites solutions.

Un exemple qui est déjà presque terminé et peut servir de modèle pour gérer les autres, est le @vbuterin/selfdestruct">suppression de l’opcode SELFDESTRUCT. L’opcode SELFDESTRUCT était le seul opcode capable de modifier un nombre illimité d’emplacements de stockage au sein d’un seul bloc, ce qui obligeait les clients à implémenter beaucoup plus de complexité pour éviter les attaques par déni de service. L’objectif initial de l’opcode était de permettre l’effacement volontaire de l’État, permettant à la taille de l’État de diminuer au fil du temps. Dans la pratique, très peu ont fini par l’utiliser. Le l'opcode a été affaiblipour permettre uniquement des comptes auto-destructeurs créés dans la même transaction dans le hardfork Dencun. Cela résout le problème de DoS et permet une simplification significative du code client. À l'avenir, il est probablement judicieux de supprimer complètement l'opcode.

Voici quelques exemples clés d'opportunités de simplification du protocole qui ont été identifiées jusqu'à présent. Tout d'abord, quelques exemples qui se trouvent en dehors de l'EVM; ceux-ci sont relativement non invasifs, et donc plus faciles à obtenir un consensus et à mettre en œuvre dans un délai plus court.

• transition de RLP → SSZ : initialement, les objets Ethereum étaient sérialisés en utilisant un encodage appelé RLP. RLP n'est pas typé et inutilement complexe. Aujourd'hui, la chaîne de balises utilise SSZ (en anglais seulement), qui est nettement meilleur à bien des égards, notamment en prenant en charge non seulement la sérialisation mais aussi le hachage. À terme, nous souhaitons nous débarrasser complètement du RLP et transférer tous les types de données en tant que structures SSZ, ce qui faciliterait également la mise à niveau. Les EIP actuels à cet effet comprennent,[1] [2][3].
• Suppression d'anciens types de transactions : il y a trop de types de transactions aujourd'hui, dont beaucoup pourraient potentiellement être supprimés. Une alternative plus modérée à la suppression totale est une fonction d'abstraction de compte grâce à laquelle les comptes intelligents pourraient inclure le code pour traiter et vérifier les transactions de style ancien s'ils le souhaitent.
• Réforme des journaux : les journaux créent des filtres de Bloom et d'autres logiques qui ajoutent de la complexité au protocole, mais qui ne sont pas réellement utilisés par les clients car c'est trop lent. Nous pourrions supprimer ces fonctionnalités, et plutôt mettre des efforts dans des alternatives, telles que des outils de lecture de journal décentralisés hors-protocole qui utilisent des technologies modernes comme SNARKs.
• Suppression éventuelle du mécanisme du comité de synchronisation de la chaîne de balises: le mécanisme de comité de synchronisationa été initialement introduit pour permettre la vérification légère du client Ethereum. Cependant, cela ajoute une complexité significative au protocole. Finalement, nous serons en mesure devérifier directement la couche de consensus Ethereum en utilisant SNARKs, ce qui supprimerait le besoin d'un protocole de vérification du client léger dédié. Potentiellement, des modifications apportées au consensus pourraient nous permettre de supprimer les comités de synchronisation même plus tôt, en créant un protocole de vérification du client léger plus « natif » impliquant la vérification des signatures d'un sous-ensemble aléatoire des validateurs du consensus Ethereum.
• Harmonisation du format de données : Aujourd'hui, l'état d'exécution est stocké dans un arbre de Merkle Patricia, l'état de consensus est stocké dans un protocole gate.arbre SSZ, et les blobs sont engagés avec@vbuterin/proto_danksharding_faq#Quel-format-les-données-blob-sont-elles-et-comment-sont-elles-engagées">Engagements KZG. À l'avenir, il serait logique d'avoir un format unifié unique pour les données de bloc et un format unifié unique pour l'état. Ces formats couvriraient tous les besoins importants: (i) des preuves faciles pour les clients sans état, (ii) la sérialisation et le codage par effacement pour les données, (iii) des structures de données standardisées.
• Suppression des comités de la chaîne de balises : ce mécanisme a été initialement introduit pour soutenir un version particulière de sharding d'exécution. Au lieu de cela, nous avons fini par faire du sharding à travers les L2 et les blobs. Par conséquent, les comités sont inutiles, et il en va de même pour en cours de progression vers leur suppression.
• Suppression du mélange de boutisme : l'EVM est big-endian et la couche de consensus est little-endian. Il peut être logique de réharmoniser et de rendre tout l'un ou l'autre (probablement big-endian, car l'EVM est plus difficile à changer)

Maintenant, quelques exemples qui sont à l'intérieur de l'EVM :

• Simplification des mécanismes de gaz : les règles actuelles sur le gaz ne sont pas très bien optimisées pour fixer des limites claires à la quantité de ressources nécessaires pour vérifier un bloc. Les principaux exemples incluent (i) les coûts de lecture/écriture de stockage, qui sont censés limiter le nombre de lectures/écritures dans un bloc mais qui sont actuellement assez chaotiques, et (ii) les règles de remplissage de la mémoire, où il est actuellement difficile d'estimer la consommation maximale de mémoire de l'EVM. Les solutions proposées incluent changement de coût du gaz de l'état de non-résidence, qui harmonisent tous les coûts liés au stockage dans une formule simple, et cette proposition de tarification de la mémoire.
• Suppression des précompilations : bon nombre des précompilations actuelles d'Ethereum sont à la fois inutilement complexes et relativement peu utilisées, et représentent une grande partie des échecs proches du consensus sans être réellement utilisées par des applications. Deux façons de gérer cela sont (i) simplement supprimer la précompilation et (ii) la remplacer par un morceau de code EVM (inévitablement plus cher) qui implémente la même logique.Ce projet d'EIP proposepour faire cela pour le précompilateur d'identité comme première étape; plus tard, RIPEMD160, MODEXP et BLAKE pourraient être des candidats à la suppression.
• Suppression de l'observabilité du gaz : rend l'exécution de l'EVM incapable de voir combien de gaz il lui reste. Cela pourrait perturber quelques applications (notamment les transactions sponsorisées), mais permettrait une mise à niveau beaucoup plus facile à l'avenir (par exemple, pour des versions plus avancées du protocole Ethereum).gaz multidimensionnel). Le spécification EOFdéjà rend le gaz inobservable, bien que pour être utile à la simplification du protocole, EOF devrait devenir obligatoire.
• Améliorations de l'analyse statique : aujourd'hui, le code EVM est difficile à analyser statiquement, notamment parce que les sauts peuvent être dynamiques. Cela rend également plus difficile la réalisation d'implémentations EVM optimisées qui pré-compilent le code EVM dans une autre langue. Nous pouvons potentiellement corriger cela ensuppression des sauts dynamiques(ou les rendant beaucoup plus chers, par exemple, le coût du gaz est linéaire dans le nombre total de JUMPDEST dans un contrat). EOF le fait, bien que tirer des avantages de simplification du protocole de cela nécessiterait de rendre EOF obligatoire.

Quels sont quelques liens vers des recherches existantes ?

• Prochaines étapes dans la Purge: https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA
• AUTO-DESTRUCTION: @vbuterin/selfdestruct"">https://hackmd.io/@vbuterin/selfdestruct
• SSZ-ification EIPS: [1] [2] [3]
• Changements des coûts en gaz de la non-étatisation: https://eips.ethereum.org/EIPS/eip-4762
• Tarification de la mémoire linéaire: https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
• Suppression de la précompilation: https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
• Suppression du filtre de Bloom: https://eips.ethereum.org/EIPS/eip-7668
• Un moyen de récupérer de manière sécurisée des journaux hors chaîne en utilisant un calcul vérifiable de manière incrémentielle (c'est-à-dire des STARKs récursifs) :https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

Que reste-t-il à faire, et quels sont les compromis ?

Le principal compromis dans la réalisation de ce type de simplification des fonctionnalités est (i) dans quelle mesure nous simplifions et à quelle vitesse par rapport à (ii) la compatibilité ascendante. La valeur d'Ethereum en tant que chaîne provient du fait qu'il s'agit d'une plateforme sur laquelle vous pouvez déployer une application en étant certain qu'elle fonctionnera encore de nombreuses années à partir de maintenant. En même temps, il est possible d'aller trop loin dans cet idéal et,pour paraphraser William Jennings Bryan, "crucifier Ethereum sur une croix de compatibilité arrière". S'il n'y a que deux applications dans tout Ethereum qui utilisent une fonctionnalité donnée, et que l'une n'a eu aucun utilisateur depuis des années et que l'autre est presque complètement inutilisée et sécurise un total de 57 $ de valeur, alors nous devrions simplement supprimer la fonctionnalité, et si nécessaire, dédommager les victimes de 57 $ de notre poche.

Le problème social plus large réside dans la création d'un pipeline standardisé pour apporter des modifications non urgentes qui rompent la compatibilité ascendante. Une façon d'aborder cela est d'examiner et d'étendre les précédents existants, tels que le processus SELFDESTRUCT. Le pipeline ressemble à ce qui suit :

• Étape 1: commencez à parler de supprimer la fonction X
• Étape 2 : effectuez une analyse pour identifier dans quelle mesure la suppression de X perturbe les applications. Selon les résultats, soit (i) abandonnez l'idée, (ii) procédez comme prévu, soit (iii) identifiez une manière modifiée et moins perturbatrice de supprimer X et procédez ainsi.
• Étape 3: faites un EIP formel pour déprécier X. Assurez-vous que l'infrastructure populaire de niveau supérieur (par exemple, les langages de programmation, les portefeuilles) respecte cela et cesse d'utiliser cette fonctionnalité.
• Étape 4 : enfin, enlever réellement X

Il devrait y avoir un pipeline de plusieurs années entre l'étape 1 et l'étape 4, avec des informations claires sur les articles qui se trouvent à quelle étape. À ce stade, il y a un compromis entre la vigueur et la rapidité du pipeline de suppression des fonctionnalités, d'une part, et la prudence et l'investissement de plus de ressources dans d'autres domaines du développement du protocole, d'autre part, mais nous sommes encore loin de la frontière de Pareto.

EOF

Un ensemble majeur de modifications proposées pour l'EVM est le Format d'objet EVM (EOF). EOF introduit un grand nombre de changements, tels que l'interdiction de l'observabilité du gaz, l'observabilité du code (c'est-à-dire pas de CODECOPY), permettant uniquement des sauts statiques. Le but est de permettre à l'EVM d'être améliorée davantage, d'une manière qui a des propriétés plus fortes, tout en préservant la compatibilité ascendante (car l'EVM pré-EOF existera toujours).

Cela a l'avantage de créer un chemin naturel pour l'ajout de nouvelles fonctionnalités EVM et d'encourager la migration vers un EVM plus restrictif avec des garanties plus solides. Cela a l'inconvénient d'augmenter significativement la complexité du protocole, à moins que nous ne trouvions un moyen de rendre obsolète et de supprimer l'ancien EVM. Une question majeure est : quel rôle joue l'EOF dans les propositions de simplification de l'EVM, surtout si l'objectif est de réduire la complexité de l'EVM dans son ensemble ?

Comment interagit-il avec les autres parties de la feuille de route?

De nombreuses propositions d'"amélioration" dans le reste de la feuille de route sont également des occasions de simplifier d'anciennes fonctionnalités. Pour reprendre quelques exemples ci-dessus :

• Passer à une finalité à emplacement unique nous donne l'opportunité de supprimer les comités, de retravailler l'économie et de simplifier d'autres aspects liés à la preuve d'enjeu.
• La mise en œuvre complète de l'abstraction de compte nous permet de supprimer une grande partie de la logique de traitement des transactions existantes, en la déplaçant dans un morceau de "code EVM de compte par défaut" que tous les EOAs pourraient être remplacés par.
• Si nous déplaçons l'état d'Ethereum vers des arbres de hachage binaires, cela pourrait être harmonisé avec une nouvelle version de SSZ, de sorte que toutes les structures de données d'Ethereum pourraient être hachées de la même manière.

Une approche plus radicale: transformer de grandes parties du protocole en code de contrat

Une stratégie de simplification plus radicale d'Ethereum consiste à conserver le protocole tel quel, mais à déplacer une grande partie de ses fonctionnalités de protocole vers du code de contrat.

La version la plus extrême de ceci serait de faire en sorte que la L1 Ethereum soit «techniquement» juste la chaîne de balises, et d'introduire une VM minimale (par exemple.RISC-V, Le Caire, ou quelque chose de encore plus minimal spécialisé pour les systèmes de preuve) qui permet à n'importe qui d'en créer son propre rollup. L'EVM se transformerait ensuite en le premier de ces rollups. C'est ironiquement exactement le même résultat que le propositions d'environnements d'exécution de 2019-20, bien que les SNARK rendent sa mise en œuvre beaucoup plus viable en réalité.

Une approche plus modérée consisterait à maintenir la relation entre la chaîne de balises et l'environnement d'exécution Ethereum actuel tel quel, mais à effectuer un remplacement sur place de l'EVM. Nous pourrions choisir RISC-V, Cairo ou une autre machine virtuelle pour être la nouvelle "machine virtuelle Ethereum officielle", puis convertir de force tous les contrats EVM en code de nouvelle machine virtuelle qui interprète la logique du code original (en le compilant ou en l'interprétant). Théoriquement, cela pourrait même être fait avec la "machine virtuelle cible" étant une version de EOF.

Avertissement：

1. Cet article est repris de [Vitalik Buterin], Tous les droits d'auteur appartiennent à l'auteur original [Vitalik Buterin]. If there are objections to this reprint, please contact the Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas des conseils en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe d'apprentissage de gate. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.