Auteur: Vitalik Buterin

Compilation: Daily Planet Daily, how about a husband

Depuis le 14 octobre, Vitalik Buterin, le fondateur d'Ethereum, a publié une série de discussions sur l'avenir possible d'Ethereum, allant de "The Merge", "The Surge", "The Scourge", "The Verge" à la dernière publication intitulée "The Purge". Cela illustre la vision de Vitalik pour le développement futur d'Ethereum Mainnet et les solutions proposées pour résoudre les problèmes actuels.

"The Merge": explore les améliorations de la finalité d'un seul slot et du seuil de participation à Gouttestake de l'ETH Bloc après la transition vers PoS, afin d'améliorer la participation et la vitesse de confirmation des transactions.

《The Surge》: Explore les différentes stratégies d'extension d'ETH, en particulier la feuille de route centrée sur Rollup, ainsi que les défis et solutions en termes de scalabilité, de décentralisation et de sécurité.

《The Scourge》: Explore les risques de centralisation et d'extraction de valeur auxquels fait face Ethereum lors de sa transition vers PoS, développe divers mécanismes pour renforcer la décentralisation et l'équité, et réforme l'économie de mise en jeu pour protéger les intérêts des utilisateurs.

《The Verge》 : Discuter des défis et des solutions de la vérification d'état sans ETH, en mettant l'accent sur la façon dont des technologies telles que l'arbre Verkle et STARK améliorent la décentralisation et l'efficacité de la chaîne de blocs.

Le 26 octobre, Vitalik Buterin a publié un article sur "The Purge", dans lequel il examine les défis auxquels fait face Ethereum et comment il parvient à maintenir la complexité et les exigences de stockage à long terme tout en préservant la persistance et la décentralisation de la chaîne. Les mesures clés comprennent la réduction du fardeau de stockage des clients en utilisant des "historiques expirés" et des "états expirés", ainsi que la simplification du protocole par le biais d'un "nettoyage des fonctionnalités" afin de garantir la durabilité et la scalabilité du réseau.

Voici le contenu original, traduit par Odaily Star Daily.

Un grand merci à Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden et Tomasz Stanczak pour leurs commentaires et leurs examens.

L'un des défis auxquels fait face Ethereum est que, par défaut, l'expansion et la complexité de tout protocole de chaîne de blocs augmentent avec le temps. Cela se produit à deux endroits:

Données historiques : Toutes les transactions effectuées à tout moment de l'histoire et tous les comptes créés doivent être stockés en permanence par tous les clients et téléchargés par tout nouveau client pour une synchronisation complète du réseau. Cela entraîne une augmentation constante de la charge et du temps de synchronisation des clients avec le 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, ce qui entraîne une complexité croissante du code avec le temps.

Pour que Ethereum puisse perdurer, nous devons exercer une forte pression à la baisse sur ces deux tendances, avec le temps, la complexité et l'expansion de Goutte. Cependant, en même temps, nous devons préserver l'une des propriétés clés qui rend la blockchain si formidable : la persistance. Vous pourriez mettre un Jeton non fongible, une lettre d'amour dans des données de transaction, ou un Smart Contract contenant 1 million de dollars, hors chaîne, les laisser dans une grotte pendant dix ans, et les retrouver toujours là, vous attendant pour les lire et interagir avec eux. Afin que les DApp puissent complètement Décentralisation en toute tranquillité et supprimer la Clé secrète de mise à niveau, ils doivent être sûrs que leurs dépendances ne seront pas mises à niveau de manière à les perturber - en particulier L1 lui-même.

S'il nous engageons à trouver un équilibre entre ces deux demandes et à réduire ou inverser au maximum l'obésité, la complexité et le déclin tout en maintenant la continuité, cela est absolument possible. Les organismes vivants peuvent le faire : bien que la plupart des organismes vivants vieillissent avec le temps, quelques chanceux ne le font pas. Même les systèmes sociaux peuvent avoir une durée de vie extrêmement longue. Dans certains cas, Ethereum a réussi : la preuve de travail a disparu, le code opération SELFDESTRUCT a en grande partie disparu, le nœud beacon chain a stocké des données obsolètes pendant jusqu'à six mois. Trouver un chemin plus général pour Ethereum et parvenir à un résultat final à long terme stable est le défi ultime pour la longue extensibilité, la durabilité technologique et même la sécurité d'Ethereum.

The Purge: objectif principal.

En réduisant ou en éliminant le besoin pour chaque Nœud de stocker en permanence tous les enregistrements historiques, voire même l'état final, les exigences de stockage du client Goutte.

Simplifiez la complexité en supprimant les fonctionnalités inutiles de Goutteprotocole.

Table des matières:

Expiration de l'historique

Expiration de l'état

Nettoyage des fonctionnalités

Expiration de l'historique

Quel problème résout-il?

Au moment de la rédaction de cet article, un nœud Ethereum entièrement synchronisé nécessite environ 1,1 To d'espace disque pour exécuter le client, ainsi que plusieurs centaines de Go d'espace disque pour le client Consensus. La plupart de cet espace est consacré à l'historique des données sur les blocs, les transactions et les reçus, dont la majeure partie remonte de nombreuses années. Cela signifie que même si la limite de gas n'augmente pas du tout, la taille du nœud continuera d'augmenter de plusieurs centaines de Go chaque année.

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

Une caractéristique clé de la résolution des problèmes de stockage historique est que, puisque chaque bloc pointe vers le bloc précédent via des liens de hachage (et d'autres structures), parvenir à un consensus actuel suffit pour parvenir à un consensus historique. Tant que le réseau parvient à un consensus sur le dernier bloc, n'importe quel bloc, transaction ou état historique (solde du compte, nombre aléatoire, code, stockage) peut être fourni par n'importe quel participant individuel ainsi que la preuve de Merkle, et cette preuve permet à quiconque de vérifier sa véracité. Le consensus est un modèle de confiance N/2-sur-N, tandis que l'historique est un modèle de confiance N-sur-N.

Cela nous offre de nombreuses options pour stocker l'historique. Un choix naturel serait 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 graine depuis des décennies : bien que le réseau stocke et distribue des millions de fichiers au total, chaque participant ne stocke et distribue que quelques-uns de ces fichiers. Contrairement à l'intuition, cette approche ne garantit pas nécessairement la résilience des données. Si nous pouvons rendre l'exécution des nœuds plus économique, nous pouvons mettre en place un réseau de 100 000 nœuds, où chaque nœud stocke 10 % aléatoire de l'historique. Ainsi, chaque donnée serait répliquée 10 000 fois - soit exactement le même facteur de réplication qu'un réseau de 10 000 nœuds où chaque nœud stocke l'ensemble du contenu.

À présent, Ethereum a commencé à se libérer du modèle où tous les nœuds stockent en permanence tout l'historique. Une partie du Consensus (liée à la Preuve d'enjeu) ne stocke que les 6 derniers mois. Le Blob ne stocke que les 18 derniers jours. L'EIP-4444 vise à introduire une période de stockage d'un an pour l'historique des blocs et des reçus. L'objectif à long terme est de mettre en place une période uniforme (probablement autour de 18 jours), pendant laquelle chaque nœud est chargé de stocker l'intégralité du contenu, puis de mettre en place un réseau peer-to-peer 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, Blob a déjà été corrigé pour prendre en charge 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 de blocs d'exécution et de consensus dans le blob.

Quels sont les liens avec les recherches existantes ?

EIP-4444;

Torrents et EIP-4444；

Portail Web;

Réseau de portail 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 faire encore, quels sont les facteurs à prendre en compte ?

Les principales tâches restantes consistent à construire et intégrer une solution distribuée concrète pour stocker l'historique - au moins l'exécution de l'historique, mais aussi le consensus et le blob. La solution la plus simple consiste à (i) introduire simplement une bibliothèque torrent existante, et (ii) utiliser une solution native d'ETH appelée Portal Network. Une fois l'une de ces solutions introduite, nous pouvons activer EIP-4444. EIP-4444 lui-même ne nécessite pas de fork, mais il nécessite une nouvelle version du protocole réseau. Il est donc utile de l'activer pour tous les clients en même temps, sinon il y a un risque de défaillance des clients qui se connectent à d'autres nœuds en s'attendant à télécharger l'historique complet mais ne le reçoivent pas réellement.

Le compromis principal concerne la façon dont nous nous efforçons de fournir des données historiques «anciennes». La solution la plus simple consiste à arrêter de stocker l'historique ancien à partir de demain et à compter sur les archives existantes Nœud et divers fournisseurs centralisés pour la reproduction. C'est facile, mais cela affaiblit la position d'Ethereum en tant que lieu d'enregistrement permanent. Le moyen le plus difficile mais plus sûr est de construire et d'intégrer d'abord le réseau torrent pour stocker l'historique de manière distribuée. Ici, «combien nous nous efforçons» a deux dimensions :

Comment nous assurons-nous que le plus grand ensemble de Nœud stocke effectivement toutes les données ?

À quelle profondeur avons-nous intégré l'historique de stockage dans le protocole Depth ?

Pour une approche extrêmement paranoïaque de (1), il sera question d'une attestation de dépôt : en fait, chaque validateur de Preuve d'enjeu devra stocker un certain pourcentage d'historique et le vérifier régulièrement de manière chiffrée pour s'assurer qu'il le fait. Une approche plus douce consiste à définir une norme volontaire de pourcentage d'historique stocké pour chaque client.

Pour (2), la mise en œuvre de base ne concerne que le travail déjà effectué aujourd'hui : le portail a stocké le fichier ERA contenant l'historique complet d'Ethereum. Une mise en œuvre plus approfondie impliquerait de le connecter réellement au processus de synchronisation, de sorte que si quelqu'un souhaite synchroniser un nœud de stockage ou un nœud d'archive contenant l'historique complet, même s'il n'y a pas d'autres nœuds d'archive en ligne, ils peuvent le faire en synchronisant directement à 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 de Nœud extrêmement facile, réduire les besoins de stockage historique est dit être plus important que l'état sans : sur les 1,1 To nécessaires pour Nœud, environ 300 Go sont l'état, le reste environ 800 Go GB est devenu historique. Seule la réalisation de l'état sans et de l'EIP-4444 peut permettre de réaliser la vision de l'exécution d'un nœud ETH sur une montre intelligente et de le configurer en quelques minutes seulement.

La limitation du stockage d'historique rend également plus viable l'implémentation des nœuds Ethereum plus récents, en ne prenant en charge que les dernières versions du protocole, ce qui les rend plus simples. Par exemple, de nombreuses lignes de code peuvent maintenant être en toute sécurité supprimées car tous les emplacements de stockage vides créés lors de l'attaque DoS de 2016 ont été supprimés. Maintenant que le passage à la preuve d'enjeu est devenu 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 éliminons le besoin de stockage de l'historique sur le client, les besoins de stockage du client continueront de hausse, d'environ 50 Go par an, car l'état continue d'hausse : solde du compte et nombres aléatoires, code de contrat et stockage de contrat. Les utilisateurs peuvent payer des frais ponctuels, offrant ainsi un fardeau permanent aux clients actuels et futurs de la plateforme Ethereum.

L'état est plus difficile à "expirer" que l'histoire, car l'EVM est fondamentalement conçu autour de cette hypothèse : une fois qu'un objet d'état est créé, il existe en permanence et peut être lu à tout moment par n'importe quelle transaction. Si nous introduisons la non-permanence, certains pensent que ce problème n'est peut-être pas si grave : seuls les constructeurs de blocs spécialisés ont besoin de stocker réellement l'état, tandis que tous les autres nœuds (y compris les générateurs de listes !) peuvent fonctionner sans état. Cependant, certains soutiennent que nous ne voulons pas trop dépendre de la non-permanence, et à terme, nous pourrions souhaiter que l'état expire pour maintenir la décentralisation d'Ethereum.

Qu'est-ce que c'est, comment ça marche

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 avec du code, (iii) définir des emplacements de stockage précédemment non sollicités), cet objet d'état reste en place pour toujours. Au contraire, ce que nous voulons, c'est que l'objet expire automatiquement avec le temps. Le défi clé est de réaliser cela de manière à atteindre ces trois objectifs :

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

Convivialité : Si quelqu'un est entré dans une grotte pendant cinq ans et est revenu, il ne devrait pas perdre l'accès à ETH, ERC20, NFT, CDP...

Convivialité des développeurs : les développeurs n'ont pas besoin de passer à un modèle mental complètement inconnu. De plus, les applications actuellement figées et non mises à jour devraient pouvoir continuer à fonctionner normalement.

Ne pas atteindre ces objectifs rendra la résolution du problème très facile. Par exemple, vous pouvez également stocker un compteur de date d'expiration pour chaque objet d'état (vous pouvez prolonger la date d'expiration en brûlant ETH, ce qui peut se produire automatiquement à tout moment en lecture ou en écriture), et avoir un processus d'état de boucle pour supprimer les dates d'expiration. Cependant, cela introduit un calcul supplémentaire (voire des besoins de stockage), et cela ne répond certainement pas aux exigences conviviales pour l'utilisateur. Il est également difficile pour les développeurs de 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 facilitera techniquement la vie des développeurs, mais cela rendra l'économie plus difficile : les développeurs doivent réfléchir à la manière de «transférer» les coûts de stockage continus aux utilisateurs.

Ce sont des problèmes que la communauté de développement central d'Ethereum a travaillé dur pour résoudre au fil des ans, notamment les propositions de "location de chaîne Bloc" et "régénération". À la fin, nous avons combiné les meilleures parties des propositions et nous sommes concentrés sur deux types de "solutions connues les moins mauvaises":.

• Solutions pour certaines statuts expirés
• Proposition d'expiration d'état basée sur le cycle de Adresse.

Expiration partielle de l'état

Certaines propositions d'expiration d'état suivent les mêmes principes. Nous divisons l'état en blocs. Chaque personne stocke en permanence une « carte de niveau supérieur » dans laquelle les blocs peuvent être vides ou non vides. Seules les données des blocs sont stockées lorsque les données ont été récemment consultées. Il existe un mécanisme de « résurrection » si les données ne sont plus stockées.

Les principales différences entre ces propositions sont les suivantes : (i) comment définissons-nous "récemment" et (ii) comment définissons-nous "bloc" ? Une proposition spécifique est l'EIP-7736, qui repose sur la conception de "brins" introduite pour l'arbre Verkle (bien qu'elle soit compatible avec tout état sans état, comme un arbre binaire). Dans cette conception, les en-têtes, le code et les emplacements de stockage adjacents sont stockés sous un même "tronc". Les données stockées sous un tronc peuvent atteindre au maximum 256 * 31 = 7 936 octets. Dans de nombreux cas, l'intégralité des en-têtes et du code de compte, ainsi que de nombreux emplacements de stockage de clés, seront stockés sous un même tronc. Si les données sous un tronc donné n'ont pas été lues ou écrites dans les 6 derniers mois, ces données ne seront plus stockées, mais seulement un engagement de 32 octets pour ces données ("racine"). Les transactions futures accédant à ces données devront "ressusciter" les données et fournir une preuve vérifiant ces données en fonction de la racine.

Il existe d'autres moyens de réaliser des idées similaires. Par exemple, si la granularité au niveau du compte n'est pas suffisante, nous pouvons élaborer un plan où chaque partie 1/232 de l'arbre est contrôlée par un mécanisme de branches et de feuilles similaire.

En raison des incitations, cela devient encore plus compliqué : un attaquant peut forcer le client à stocker en permanence une grande quantité d'états en plaçant une grande quantité de données dans un seul sous-arbre et en envoyant une seule transaction par an pour "mettre à jour l'arbre". Si vous liez le coût de renouvellement à la taille de l'arbre (ou inversement à la durée de renouvellement), quelqu'un pourrait nuire à d'autres utilisateurs en plaçant une grande quantité de données dans le même sous-arbre. Les gens peuvent essayer de limiter ces deux problèmes en rendant la granularité dynamique en fonction de la taille du sous-arbre : par exemple, chaque ensemble de 216 = 65536 objets d'état consécutifs peut être considéré comme un "groupe". Cependant, ces idées sont plus complexes ; l'approche basée sur la racine est simple et les incitations peuvent être ajustées car les données sous la racine sont généralement liées à la même application ou au même utilisateur.

Recommandation d'expiration d'état basée sur le cycle de l'Adresse

Que se passe-t-il si nous voulons éviter toute hausse d’état permanente, même un stub de 32 octets ? Il s’agit d’une énigme due au conflit de résurrection : que se passe-t-il si un objet d’état est supprimé et que plus tard l’exécution d’EVM met l’autre objet d’état exactement dans la même position, mais que la personne qui se souciait de l’objet d’état d’origine revient et essaie de le restaurer ? Lorsqu’un statut partiel expire, le « stub » empêche la création de nouvelles données. L’état expirant complètement, nous ne pouvons même pas stocker les talons.

L'idée la plus célèbre pour résoudre ce problème est basée sur le concept d'Adresse périodique. Au lieu de stocker l'intégralité de l'état dans un seul arbre d'état, nous avons une liste d'arbres d'état qui hausse continuellement, et tout état lu ou écrit est enregistré dans le dernier arbre d'état. Un nouvel arbre d'état vide est ajouté à chaque période (par exemple, 1 an). Les anciens arbres sont figés solidement. Seuls les deux derniers arbres sont conservés dans leur intégralité. Si un objet d'état n'est pas touché pendant deux périodes et tombe dans l'arbre expiré, il peut toujours être lu ou écrit, mais la transaction doit prouver sa preuve de Merkle - une fois prouvée, une copie est conservée à nouveau dans le dernier arbre.

Un concept clé convivial pour les utilisateurs et les développeurs est le concept de cycle d'Adresse. Le cycle d'Adresse est un nombre qui appartient à l'Adresse. La règle clé est qu'une Adresse ayant un cycle d'Adresse N ne peut être lue ou écrite qu'au cours ou après le cycle N (c'est-à-dire lorsque la liste de l'arbre d'état atteint une longueur de N). Si vous souhaitez enregistrer un nouvel objet d'état (par exemple, un nouveau contrat ou un nouveau solde ERC20), vous pouvez le faire immédiatement sans fournir de preuve si vous vous assurez de placer l'objet d'état dans un contrat ayant un cycle d'Adresse de N ou N-1. En revanche, tout ajout ou modification effectué pendant l'ancien cycle d'Adresse nécessite une preuve.

Ce design conserve la plupart des caractéristiques actuelles d'Ethereum sans nécessiter de calculs supplémentaires, permettant de développer des applications presque aussi facilement qu'actuellement (ERC20 nécessite une réécriture pour s'assurer que le solde des adresses avec un cycle N d'Adresse est stocké dans un sous-contrat, qui a lui-même un cycle N d'Adresse), résolvant ainsi le problème des "cinq années que les utilisateurs passent dans une grotte". Cependant, il y a un gros problème : l'Adresse doit être étendue à plus de 20 octets pour s'adapter au cycle d'Adresse.

Extension de l'espace d'adresseAdresse空间扩展

Une suggestion est d'introduire un nouveau format d'Adresse de 32 octets, comprenant un numéro de version, un numéro de cycle d'Adresse et un hachage étendu.

0x01 (rouge) 0000 (orange) 000001 (vert) 57aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF (bleu).

Le rouge est le numéro de version. Les quatre zéros orange ici sont destinés à servir d'espace vide pour accueillir le numéro de Sharding à l'avenir. Le vert est le numéro de cycle Adresse. Le bleu est la valeur de hachage de 26 octets.

Le défi clé ici est la compatibilité ascendante. Les contrats existants sont conçus autour de l'adresse de 20 octets et utilisent généralement une technique d'empaquetage stricte des octets, supposant explicitement que l'adresse est exactement de 20 octets. Une idée pour résoudre ce problème implique une conversion de mapping, où les anciens contrats interagissant avec l'adresse moderne verront la valeur de hachage de 20 octets de l'adresse moderne. Cependant, garantir sa sécurité présente une grande complexité.

Rétrécissement de l'espace Adresse

Une autre approche consiste à prendre la direction opposée : nous interdisons immédiatement certaines sous-plages d'adresses de taille 2128 (par exemple, toutes les adresses commençant par 0xffffffff), puis nous utilisons cette plage pour introduire des adresses avec une période d'adresse et une valeur de hachage de 14 octets.

0xffffffff000169125d5dFcb7B8C2659029395bdF

Le principal sacrifice de cette méthode est l'introduction du risque de sécurité hash contrefactuel : une Adresse détenant des actifs ou des autorisations, mais dont le code n'a pas encore été publié sur la chaîne. Le risque est que quelqu'un crée une Adresse prétendant posséder un code (non encore publié), mais qu'un autre code valide soit également haché vers la même Adresse. Aujourd'hui, calculer une telle collision nécessite 280 hash ; la réduction de l'espace des Adresses ramènera ce nombre à 256 hash facilement accessibles.

Dans les domaines à risques clés, les Adresses Portefeuille non factuelles détenues par des propriétaires non uniques sont relativement rares aujourd'hui, mais elles pourraient devenir plus courantes à mesure que nous entrons dans le monde du L2. La seule solution consiste à accepter simplement ce risque, mais il est important d'identifier tous les cas d'utilisation courants susceptibles de poser problème et de proposer des solutions efficaces.

Quels sont les liens avec les recherches existantes ?

Proposition initiale

• Bloc链清洁；
• Régénération;
• Théorie de gestion de la taille de l'état Ethereum ;
• Quelques chemins possibles sans état et avec expiration de l'état ;

Certaines propositions d'expiration d'état

• EIP-7736；

Document d'extension de l'Adresse

• Proposition initiale;
• Ipsilon Review;
• Commentaires sur les articles de blog ;
• Si nous perdons la résistance aux collisions, que détruirons-nous.

Que faut-il faire encore, quels sont les facteurs à prendre en compte ?

Je pense qu'il y a quatre voies réalisables pour l'avenir :

• Nous parvenons à être sans état et ne jamais introduire l'expiration de l'état. L'état est en hausse constante (bien que lentement : nous pourrions ne pas le voir dépasser 8 téraoctets pendant des décennies), mais il ne nécessite que par des utilisateurs de catégories relativement spéciales : même les validateurs PoS n'ont pas besoin de l'état. Une fonctionnalité nécessitant l'accès à une partie de l'état est la génération de listes, mais nous pouvons réaliser cette opération de manière distribuée : chaque utilisateur est responsable de maintenir la partie de l'arbre d'état contenant son propre compte. Lorsqu'ils diffusent des transactions, ils diffusent les transactions et accompagnent la preuve des objets d'état auxquels ils ont accédé pendant l'étape de validation (ceci s'applique aux comptes EOA et ERC-4337). Ensuite, les validateurs sans état peuvent combiner ces preuves pour former une preuve complète de la liste.
• Nous effectuons des états partiels à échéance, et acceptons un taux de croissance de la taille de l'état permanent beaucoup plus bas mais toujours non nul. Ce résultat peut être considéré comme similaire à la façon dont les propositions expirées de l'historique impliquant des réseaux pairs-à-pairs acceptent un taux de croissance de stockage permanent beaucoup plus bas mais toujours non nul pour chaque client devant stocker un pourcentage d'historique plus bas mais fixe de données historiques.
• Nous utilisons l'extension d'espace d'Adresse pour gérer l'expiration de l'état. Cela impliquera un processus de plusieurs années pour garantir que la méthode de conversion du format d'Adresse est efficace et sécurisée, y compris pour les applications existantes.
• Nous utilisons la réduction de l'espace Adresse pour gérer l'expiration de l'état. Il s'agit d'un processus pluriannuel visant à garantir que tous les risques de sécurité liés aux conflits d'Adresse (y compris les cas d'Interaction cross-chain) soient traités.

Un point important est que, que le schéma d'expiration de l'état dépende ou non des modifications du format Adresse, il faut finalement résoudre les problèmes d'extension et de contraction de l'espace Adresse. Aujourd'hui, la génération de conflits Adresse nécessite environ 280 valeurs de hachage, ce qui est réalisable pour les participants disposant de ressources extrêmement riches : les GPU peuvent effectuer environ 227 valeurs de hachage, ce qui signifie qu'ils peuvent effectuer un calcul de collision en un an, et les environ 230 GPU dans le monde entier peuvent effectuer un calcul de collision en environ 1/4 d'année, avec une accélération supplémentaire possible grâce aux FPGA et aux ASIC. À l'avenir, de telles attaques seront accessibles à un nombre croissant 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 n'y paraît, car nous devrons de toute façon résoudre ce problème Adresse très difficile.

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

L'expiration de l'état en cours peut faciliter la conversion d'un format d'arbre d'état à un autre format d'arbre d'état, car aucun processus de conversion n'est nécessaire : vous pouvez simplement commencer à utiliser le nouveau format pour créer un nouvel arbre, puis effectuer une bifurcation difficile pour convertir l'ancien arbre. Ainsi, bien que l'expiration de l'état soit complexe, elle simplifie d'autres aspects de la feuille de route.

Nettoyage des fonctionnalités

Quel problème cela résout-il?

L'une des conditions préalables clés de la sécurité, de l'accessibilité et de la neutralité de confiance est la simplicité du protocole. Si le protocole est esthétique et simple, cela réduira la possibilité d'erreurs. Cela augmente les chances pour que de nouveaux développeurs puissent participer à n'importe quelle partie. Il est plus susceptible d'être juste et plus facile à résister aux intérêts spéciaux. Malheureusement, le protocole, comme tout système social, devient plus complexe avec le temps par défaut. Si nous ne voulons pas qu'Ethereum tombe dans un trou noir d'augmentation constante de la complexité, nous devons faire l'une des deux choses suivantes: (i) arrêter les changements et rendre le protocole rigide, (ii) être capable de supprimer réellement les fonctionnalités et de réduire la complexité. Une voie intermédiaire est également possible, c'est-à-dire apporter des modifications mineures au protocole et éliminer au moins un peu de complexité au fil du temps. Cette section examine comment réduire ou éliminer la complexité.

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

Il n’y a pas de correction unique majeure qui peut réduire la complexité du protocole Goutte ; l’essence de ce problème réside dans de nombreuses petites solutions.

Un exemple partiellement terminé est la suppression du code d'opération SELFDESTRUCT, qui peut servir de modèle pour traiter d'autres exemples. Le code d'opération SELFDESTRUCT est le seul code d'opération pouvant modifier un nombre illimité de slots de stockage dans un seul bloc, ce qui nécessite une complexité significativement plus élevée de la part du client pour éviter les attaques DoS. L'objectif initial de ce code d'opération était de permettre une liquidation volontaire de l'état, permettant ainsi une réduction de la taille de l'état au fil du temps. En réalité, très peu de personnes l'utilisent. Le code d'opération a été affaibli pour ne permettre la création que de compte auto-détruits dans la même transaction que la création de compte Dencun. Cela résout le problème DoS et peut grandement simplifier le code client. À l'avenir, il pourrait être pertinent de supprimer complètement le code d'opération.

Jusqu'à présent, quelques exemples clés de protocole simplifié déterminés incluent ce qui suit. Tout d'abord, quelques exemples en dehors de l'EVM; ceux-ci sont relativement non intrusifs, donc plus faciles à atteindre Consensus et à mettre en œuvre en moins de temps.

Conversion RLP → SSZ : Au début, les objets Ethereum étaient sérialisés à l'aide d'un encodage appelé RLP. RLP est non typé et inutilement complexe. Aujourd'hui, la chaîne de balises utilise SSZ, qui est nettement supérieur à bien des égards, offrant non seulement la sérialisation, mais également le hachage. À terme, nous souhaitons nous débarrasser complètement de RLP et transférer tous les types de données vers la structure SSZ, ce qui facilitera les mises à niveau. Les EIP actuels incluent[1][2]。

Supprimer les anciens types de transactions : Il y a trop de types de transactions aujourd'hui, dont beaucoup pourraient être supprimés. Une alternative plus douce à la suppression complète est la fonction d'abstraction du compte, où les comptes intelligents peuvent inclure le code de traitement et de validation des anciennes transactions (s'ils le souhaitent).

Réforme LOG : création de filtre bloom et d'autres logiques dans les journaux, ce qui a augmenté la complexité du protocole, mais en réalité, ils ne sont pas utilisés par le client car c'est trop lent. Nous pouvons supprimer ces fonctionnalités et nous concentrer sur des solutions de remplacement, telles que l'utilisation de protocoles pour des outils de lecture de journaux décentralisés basés sur des technologies modernes telles que SNARK.

Finalement, le mécanisme de synchronisation du beacon chain a été supprimé : à l'origine, le mécanisme de synchronisation a été introduit pour permettre la validation du light client d'ETH, ce qui a considérablement complexifié le protocole. En fin de compte, nous serons en mesure de vérifier la couche de consensus d'ETH directement à l'aide de la vérification SNARK, ce qui éliminera le besoin d'un protocole de validation de light client dédié. Potentiellement, les changements de consensus pourraient nous permettre de supprimer plus tôt le comité de synchronisation en créant un protocole de light client plus "natif" qui implique la vérification des signatures d'un sous-ensemble aléatoire de validateurs de consensus d'ETH.

Formats de données unifiés: Aujourd'hui, l'état d'exécution est stocké dans l'arbre de Merkle Patricia, l'état de consensus est stocké dans l'arbre SSZ, et le blob est soumis via l'engagement KZG. Dans le futur, il serait judicieux d'avoir un format unique pour les données de bloc et un format unique pour l'état. Ces formats répondront à tous les besoins importants: (i) preuve simple pour le client non étatique, (ii) sérialisation et codage d'effacement des données, (iii) structure de données normalisée.

Supprimer le comité de la chaîne de balises : ce mécanisme a été initialement introduit pour prendre en charge l'exécution du Sharding dans une version spécifique. Au lieu de cela, nous utilisons finalement le L2 et le blob pour le Sharding. Par conséquent, le comité est superflu et des mesures sont prises pour le supprimer.

Supprimer le mélange d'octets : EVM est big-endian, la couche de consensus est little-endian. Réaligner et rendre tout cohérent pour être soit big-endian soit little-endian pourrait avoir du sens (peut-être big-endian car l'EVM est plus difficile à changer)

Maintenant, quelques exemples dans l'EVM:

Simplification du mécanisme de gas : Les règles actuelles de gas ne sont pas encore bien optimisées et ne peuvent pas imposer de limites claires sur les ressources nécessaires à la vérification du Bloc. Des exemples clés à cet égard incluent (i) le coût de lecture/écriture de stockage, qui vise à limiter le nombre de lectures/écritures par bloc, mais qui est actuellement assez arbitraire, et (ii) les règles de remplissage de la mémoire, qui rendent actuellement difficile l'estimation de la consommation maximale de mémoire de l'EVM. Les mesures correctives proposées comprennent des modifications des coûts de gas sans état (unification de tous les coûts liés au stockage dans une formule simple) et une proposition de tarification de la mémoire.

Suppression des précompilations : Ethereum possède actuellement de nombreuses précompilations qui sont à la fois inutilement complexes, relativement inutilisées et constituent une grande partie de l'échec du consensus, car elles sont presque inutilisées par des applications. Deux approches pour résoudre ce problème sont (i) la suppression pure et simple des précompilations, et (ii) les remplacer par une section de code EVM implémentant la même logique (certainement plus coûteuse). Ce projet d'EIP suggère de commencer par supprimer la précompilation d'identité, puis plus tard, RIPEMD160, MODEXP et BLAKE pourraient être des candidats à la suppression.

Suppression de la visibilité du gas : rend l'EVM incapable de voir combien de gas il reste à exécuter. Cela perturbera certaines applications (notamment les transactions sponsorisées), mais rendra les futures mises à niveau plus simples (par exemple, pour des versions plus avancées du gaz multidimensionnel). La norme EOF a rendu le gaz non observable, mais pour simplifier le protocole, l'EOF doit être rendu obligatoire.

Amélioration de l'analyse statique: aujourd'hui, il est difficile d'effectuer une analyse statique du code EVM, en particulier parce que les sauts peuvent être dynamiques. Cela rend également plus difficile l'optimisation de la mise en œuvre de l'EVM (pré-compilation du code EVM dans d'autres langues). Nous pouvons résoudre ce problème en supprimant les sauts dynamiques (ou en les rendant plus coûteux, par exemple, le coût en gaz du nombre total de JUMPDEST dans le contrat est linéaire). EOF fait cela, bien que la mise en œuvre forcée d'un protocole soit nécessaire pour en tirer les bénéfices de simplification.

Quels sont les liens avec les recherches existantes ?

• Étapes suivantes de la suppression ;
• Autodestruction
• SSZ transforme EIPS：[1][2]；
• Coût du gaz sans état changeant ;
• Tarification de la mémoire linéaire ;
• Précompilation supprimée;
• Supprimer le filtre bloom ;
• Une méthode utilisant le calcul incrémental vérifiable pour la récupération sécurisée des journaux hors chaîne (lire : récursivité STARK) ;

Que faut-il faire encore, quels sont les facteurs à prendre en compte ?

Le principal compromis de cette simplification fonctionnelle est (i) notre degré et notre vitesse de simplification et (ii) la rétrocompatibilité. La valeur d'Ether comme chaîne vient du fait qu'il s'agit d'une plateforme sur laquelle vous pouvez déployer des applications et être assuré qu'elles fonctionneront encore dans de nombreuses années. En même temps, cet idéal peut également aller trop loin, pour reprendre les mots de William Jennings Bryan, "clouer Ether à la croix de la rétrocompatibilité". Si seulement deux applications dans toute la chaîne Ether utilisent une fonctionnalité donnée, et qu'une application n'a jamais eu d'utilisateurs pendant des années, tandis qu'une autre application n'a presque pas été utilisée et a généré une valeur totale de 57 dollars, nous devrions supprimer cette fonctionnalité, et si nécessaire, payer 57 dollars aux victimes de notre poche.

Un problème plus large dans la société est de créer un canal normalisé pour les changements non urgents de rétrocompatibilité destructrice. Une façon de résoudre ce problème est d'examiner et d'étendre les précédents existants, comme le processus d'autodestruction. Le canal ressemble à ceci:

• Commencer à parler de la fonction de suppression X ;
• Analyser pour déterminer les impacts de la suppression de X sur l'application, en fonction des résultats : (i) abandonner l'idée, (ii) continuer selon le plan initial, ou (iii) déterminer une méthode modifiée avec un impact minimal pour supprimer X et continuer ;
• Élaborer un EIP officiel pour abandonner X. Assurez-vous que les infrastructures de niveau supérieur populaires (comme les langages de programmation, Portefeuille) respectent cela et cessent d'utiliser cette fonctionnalité.
• Enfin, supprimez réellement X；
• Il devrait y avoir un pipeline de plusieurs années entre les étapes 1 et 4, et il devrait être clairement indiqué quels projets se trouvent à quelle étape. À ce stade, il est nécessaire de trouver un équilibre entre la vigueur et la vitesse du processus de suppression des fonctionnalités et la prudence et les ressources supplémentaires consacrées au développement du protocole dans d'autres domaines, mais nous sommes encore loin de la frontière de Pareto.

EOF

Un ensemble de modifications importantes proposées pour EVM est le format d'objet EVM (EOF). EOF introduit de nombreux changements, tels que l'interdiction de l'observabilité du gaz, de l'observabilité du code (c'est-à-dire sans CODECOPY) et la suppression des sauts dynamiques. L'objectif est de permettre à EVM de se mettre à jour de manière plus robuste tout en maintenant la compatibilité ascendante (car EVM avant EOF existe encore).

Les avantages de cette approche sont qu'elle crée un chemin naturel pour ajouter de nouvelles fonctionnalités EVM et encourage la migration vers une EVM plus stricte avec des garanties plus solides. Son inconvénient est qu'elle augmente considérablement la complexité du protocole, à moins que nous puissions trouver un moyen de finalement abandonner et supprimer l'ancienne EVM. Une question majeure est : quel rôle joue la fin de fichier (EOF) dans la proposition de simplification de l'EVM, en particulier si l'objectif est de réduire la complexité de l'ensemble de l'EVM ?

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

De nombreuses suggestions "d'amélioration" dans le reste de la feuille de route sont également des opportunités pour simplifier les anciennes fonctionnalités. Répétons certains des exemples ci-dessus :

• Le passage à la finalité unique nous donne l'occasion d'annuler les comités, de repenser l'économie et de simplifier d'autres aspects liés à l'attestation de participation.
• La réalisation complète de l'abstraction de compte peut nous permettre de supprimer une grande partie de la logique de traitement des transactions existante et de la déplacer dans le "code EVM de compte par défaut" remplaçable par tous les EOA.
• Si nous transférons l'état d'Ethereum vers un arbre de hash binaire, cela peut être cohérent avec la nouvelle version de la SSZ, afin que toutes les structures de données d'Ethereum puissent être hashées de la même manière.

Méthode plus radicale: convertir la majeure partie du protocole en code de contrat

Une stratégie plus agressive de simplification d'ETH consiste à laisser le protocole inchangé, mais à déplacer la majeure partie de ses fonctionnalités du protocole vers le code du contrat.

La version la plus extrême serait de faire en sorte que L1 d'ETH soit simplement la beacon chain sur le plan technique et d'introduire une machine virtuelle minimale (comme RISC-V, Cairo ou même plus petite, spécifiquement conçue pour les systèmes de preuve), permettant à d'autres de créer leurs propres agrégats. Ensuite, l'EVM deviendrait le premier de ces agrégats. Ironiquement, cela correspond exactement aux résultats de la proposition d'exécution de l'environnement de 2019-20, bien que les SNARK rendent sa mise en œuvre réelle plus réalisable.

Une approche plus douce serait de maintenir la relation entre la beacon chain et l'environnement d'exécution actuel de l'ETH, mais de remplacer l'EVM sur place. Nous pouvons choisir RISC-V, Cairo ou un autre VM comme le nouveau "Machine virtuelle Ethereum" officiel, puis convertir de force tous les contrats EVM en code VM nouvellement interprété pour la logique du code source (par compilation ou interprétation). En théorie, cela pourrait même être réalisé en utilisant "Machine virtuelle cible" comme une version d'EOF.