Vitalik: L’avenir possible du protocole Ethereum – la purge

Auteur: Vitalik, fondateur d’Ethereum;

Remarque: Cet article est la cinquième partie de la série d’articles récemment publiés par Vitalik, fondateur d’Ethereum,Futures possibles du protocole Ethereum, partie 5: La purge», Voir la quatrième partie»Vitalik: le verge d’Ethereum« . Voir « Vitalik: objectifs clés de l’ethereum la phase du fléau« , Voir la deuxième partie »Vitalik: Comment le protocole Ethereum devrait-il se développer au stade de surtension», Voir la première partie»Quoi d’autre peut être amélioré sur Ethereum pos».

---

L’un des défis auxquels Ethereum est confronté est que par défaut, le ballonnement et la complexité de tout protocole de blockchain augmenteront avec le temps.Cela se produit de deux manières:

• Données historiques:Toute transaction et tout compte créé à tout moment historique devront être stockés de façon permanente par tous les clients et téléchargés par tout nouveau client qui est entièrement synchronisé avec le réseau.Cela entraîne une augmentation de la charge du client et de la synchronisation au fil du temps, même si la capacité de la chaîne reste la même.

• Fonctions du protocole:L’ajout de nouvelles fonctionnalités est beaucoup plus facile que la suppression des anciennes fonctionnalités, ce qui entraîne une augmentation de la complexité du code au fil du temps.

Pour que Ethereum dure longtemps, nous devons mettre une contre-pression intensifiée sur les deux tendances, réduisant la complexité et le ballonnement au fil du temps.Mais en même temps, jeNous devons conserver l’un des attributs clés de la blockchain: la persistance.Vous pouvez mettre des NFT, aimer les lettres dans les données d’appel de transaction ou des contrats intelligents contenant un million de dollars sur la chaîne, entrez une grotte pendant dix ans et constatez qu’il est toujours là en attendant que vous lisez et interagissez.Pour que les DAPP soient entièrement décentralisés et suppriment les clés de mise à niveau en toute confiance, ils doivent être sûrs que leurs dépendances ne sont pas améliorées d’une manière qui les brise, en particulier L1 lui-même.

The Purge, 2023 Feuille de route.

Si nous nous concentrons et équilibrons ces deux besoins, minimisant ou inversant l’expansion, la complexité et la récession tout en maintenant la continuité, est absolument possible.Les organismes peuvent le faire: alors que la plupart des organismes vieillissent au fil du temps, heureusement, quelques organismes ne vieillissent 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, l’opcode d’autodestruction a essentiellement disparu et le nœud de la chaîne de balise a stocké de vieilles données pendant six mois.Trouver cette voie pour Ethereum d’une manière plus générale et évoluer vers un résultat final stable à long terme est le défi ultime pour l’évolutivité à long terme d’Ethereum, la durabilité technologique et même la sécurité.

La purge: objectifs principaux

• Réduire les exigences de stockage des clients en réduisant ou en éliminant le besoin pour chaque nœud de stocker en permanence tous les histoires, et peut même le finaliser

• Réduire la complexité du protocole en éliminant les caractéristiques indésirables

Les données historiques ont expiré

Quels problèmes résout-il?

À ce jour, un nœud Ethereum entièrement synchronisé nécessite environ 1,1 To d’espace disque pour exécuter le client, et quelques centaines de Go d’espace pour être utilisés pour le client consensuel.La plupart d’entre eux sont des données historiques: des données sur les blocs historiques, les transactions et les reçus, dont la plupart sont il y a des années.Cela signifie que même si la limite de gaz n’augmente pas du tout, la taille du nœud augmente de centaines de GB par an.

qu’est-ce que c’est?Comment ça marche?

Une caractéristique de clé simplifiée du problème de stockage historique est que, puisque chaque bloc pointe vers le bloc précédent à travers des liens de hachage (et d’autres structures), atteindre le consensus sur le courant est suffisant pour atteindre un consensus sur l’histoire.Tant que le réseau est d’accord sur le dernier bloc, tout bloc historique, transaction ou statut (solde du compte, numéro aléatoire, code, stockage) peut être fourni par un seul participant avec Merkle Proof, et la preuve permet à quiconque de vérifier qu’il est le sexe correct.Bien que le consensus soit le modèle de confiance N / 2-N-N, l’histoire est le modèle de fiducie 1-N-N.

Cela ouvre de nombreuses options sur la façon dont nous stockons l’histoire.Un choix naturel est un réseau où chaque nœud ne stocke qu’une petite partie des données.C’est ainsi que le réseau torrent a fonctionné pendant des décennies: alors que le réseau stocke et distribue des millions de fichiers au total, chaque participant stocke et en distribue seulement quelques-uns.Peut-être contre-intuitivement, cette approche peut même ne pas réduire la robustesse des données.Si nous pouvons implémenter un réseau de 100 000 nœuds en réduisant le coût du fonctionnement du nœud, où chaque nœud stocke au hasard 10% de l’histoire, alors chaque élément de données sera copié 10 000 fois – avec 10 000 du contenu stocké par nœud le facteur de réplication de chaque réseau de nœuds est exactement le même.

Aujourd’hui, Ethereum a commencé à se débarrasser du modèle où tous les nœuds stockent en permanence toute l’histoire.Le bloc de consensus (c’est-à-dire la partie liée au consensus de preuve de pieu) n’est stocké que pendant environ 6 mois.Les blobs ne sont stockés que pendant environ 18 jours.EIP-4444 est conçu pour introduire une période de stockage d’un an pour les blocs et reçus historiques.L’objectif à long terme est d’avoir une période coordonnée (probablement environ 18 jours), au cours de laquelle chaque nœud est responsable de tout stocker, puis il existe un réseau de nœuds Ethereum de pair .

Le codage d’effacement peut être utilisé pour améliorer la robustesse tout en gardant le facteur de réplication inchangé.En fait, pour soutenir l’échantillonnage de la disponibilité des données, les blobs ont adopté des codes d’effacement.La solution la plus simple pourrait être de réutiliser ce code d’effacement et de mettre également les données d’exécution et de bloc de consensus dans le blob.

Quelles recherches sont-elles disponibles?

EIP-4444:https://eips.ethereum.org/eips/eip-4444

Torrents et EIP-4444:https://ethreear.ch/t/torrent-and-eip-4444/19788

Réseau de portail:https://ethereum.org/en/developers/docs/networking-ayer/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 des objets SSZ dans le portail:https://ethreear.ch/t/distributed-storage-and-cryptographically-secured-reval-of-ssz-objects-for-ports-network/19575

Comment augmenter la limite de gaz (paramètre):https://www.paradigm.xyz/2024/05/how-to-waise-the-gas-limit-2

Quels sont les autres et quels compromis y a-t-il?

Le travail principal restant consiste à construire et à intégrer une solution distribuée en béton à l’historique des magasins – au moins l’historique d’exécution, mais comprend également également des consensus et des blobs.La solution la plus simple est (i) l’introduction simplement de la bibliothèque Torrent existante, et (ii) une solution native Ethereum appelée Portal Network.Une fois que l’un d’eux est introduit, nous pouvons activer EIP-4444.EIP-4444 lui-même ne nécessite pas de fourche dure, 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, car sinon les clients peuvent échouer en raison de la connexion à d’autres nœuds qui s’attendent à télécharger l’historique complet mais qui ne sont pas réellement implémentés.

Le compromis principal consiste à savoir comment nous travaillons pour rendre les données historiques «précédentes» disponibles.La solution la plus simple consiste à arrêter de stocker les données précédentes demain et à s’appuyer sur les nœuds d’archives existants et divers fournisseurs centralisés pour la réplication.C’est facile, mais cela affaiblit la position d’Ethereum en tant qu’enregistrement des données permanentes.Une approche plus difficile mais plus sûre consiste à construire et à intégrer un réseau torrent d’abord pour stocker l’histoire de manière distribuée.Ici, il y a deux dimensions:

• De quels efforts avons-nous besoin pour garantir que le nombre maximum de nœuds stockent toutes les données?

• À quelle profondeur intégrons-nous le stockage historique avec les protocoles?

Car (1), l’approche la plus rigoureuse impliquerait une preuve de garde: en fait, chaque vérification de la preuve de pieu est tenu de stocker un certain pourcentage d’histoire et de vérifier régulièrement s’ils le font par le cryptage.Une approche plus modeste consiste à établir une norme volontaire pour le pourcentage d’historique stocké par client.

Pour (2), l’implémentation de base n’implique que ce qui a été fait aujourd’hui: Portal a stocké un fichier ERA contenant l’intégralité de l’historique Ethereum.Une implémentation plus approfondie impliquerait réellement la connecter au processus de synchronisation afin que si quelqu’un veut synchroniser le nœud de stockage complet ou le nœud d’archive, même si aucun autre nœud d’archive n’est en ligne, il peut le faire en se synchronisant directement à partir du réseau de portail.

Comment cela interagit-il avec le reste de la feuille de route?

Si nous voulons rendre le nœud en cours d’exécution ou démarrer extrêmement simple, la réduction des exigences de stockage historique peut être sans doute plus importante que les sans-états: du 1,1 To requis par le nœud, environ 300 Go est l’état, et le reste d’environ 800 Go est un historique.La vision du nœud Ethereum fonctionnant sur une smartwatch et le réglage en quelques minutes ne sont obtenues que si les apatrides et EIP-4444 sont obtenus simultanément.

Limiter le stockage historique rend également les nouveaux implémentations de nœuds Ethereum plus possibles pour prendre en charge uniquement les dernières versions du protocole, ce qui les rend beaucoup plus simples.Par exemple, comme tous les emplacements de stockage vides créés lors de l’attaque DOS 2016 ont été supprimés, de nombreuses lignes de code peuvent être supprimées en toute sécurité.Maintenant que le passage à la preuve de la participation est l’histoire, le client peut supprimer en toute sécurité tout le code lié à la preuve de travail.

Les données d’état ont expiré

Quels problèmes résout-il?

Même si nous éliminons le besoin de l’historique du stockage des clients, la demande de stockage des clients continuera de croître, environ 50 Go par an, alors que l’État continue de croître: les soldes du compte et les nombres aléatoires, les codes de contrat et le stockage des contrats.Les utilisateurs peuvent payer des frais uniques, ce qui exercera toujours un fardeau sur les clients Ethereum actuels et futurs.

L’état est plus difficile à «expiration» que l’historique, car l’hypothèse de conception de base de l’EVM est qu’une fois qu’un objet d’état sera créé, il existera éternellement et peut être lu par n’importe quelle transaction à tout moment.Si nous introduisons les apatrides, certaines personnes pensent que ce problème n’est peut-être pas si mauvais: une seule classe de constructeurs de blocs spécialisés nécessite un stockage réel de l’état, et tous les autres nœuds (même en y compris la génération de liste!) Peut s’exécuter sans état.Cependant, certaines personnes pensent que nous ne voulons pas trop compter sur l’apatritude, et finalement nous voulons que l’État expire reste Ethereum décentralisé.

qu’est-ce que c’est?Comment ça marche?

Aujourd’hui, lorsque vous créez un nouvel objet d’état (peut être fait de l’une des trois manières: (i) Envoyez ETH à un nouveau compte, (ii) créer un nouveau compte avec le code, et (iii) configurer le stockage précédemment intouflé) L’objet d’état sera toujours dans cet état.Au lieu de cela, ce que nous voulons, c’est que l’objet expire automatiquement avec le temps.Le principal défi est de le faire d’une manière qui atteint trois buts:

• efficacité:Aucune grande quantité de calcul supplémentaire n’est nécessaire pour exécuter le processus d’expiration.

• Convivialité par l’utilisateur:Si quelqu’un revient à cinq ans dans la grotte, il ne devrait pas perdre accès à ses positions ETH, ERC20, NFT, CDP…

• Convivialité du développeur:Les développeurs n’ont pas à passer à des modèles de réflexion complètement inconnus.En outre, les applications qui sont maintenant rigides et inutiles devraient continuer à s’exécuter raisonnablement.

Sans atteindre ces objectifs, le problème est facile à résoudre.Par exemple, vous pouvez faire en sorte que chaque objet d’état stockait également un compteur pour enregistrer sa date d’expiration (qui peut être étendu en détruisant ETH, qui peut se produire automatiquement lors de la lecture ou de l’écriture), et avoir une boucle à travers l’État pour supprimer l’état d’expiration l’état de processus de l’objet.Cependant, cela introduit des calculs supplémentaires (même les exigences de stockage) et ne répond certainement pas aux exigences de convivialité.Il est également difficile pour les développeurs de raisonner sur les cas extrêmes impliquant des valeurs stockées parfois réinitialisées à zéro.Si vous définissez le temporisateur d’expiration dans la portée du contrat, cela facilite techniquement le travail du développeur, mais rend l’économie plus difficile: les développeurs doivent réfléchir à la façon de « transmettre » les coûts de stockage en cours à leurs utilisateurs.

Ce sont des problèmes que la communauté du développement de Core Ethereum travaille dur pour résoudre depuis des années, y compris des propositions telles que la « location de blockchain » et la « régénération ».En fin de compte, nous combinons les meilleures parties de la proposition et nous nous concentrons sur deux catégories de «les moins mauvaises solutions connues»:

• Certaines solutions d’expiration des États.

• Proposition d’expiration de l’État en fonction du cycle d’adresse.

Un certain statut a expiré

Certaines propositions d’expiration de l’État suivent les mêmes principes.Nous divisons l’état en morceaux.Tout le monde stocke en permanence la « carte de niveau supérieur » et quels blocs sont vides ou non vides.Les données de chaque bloc sont stockées uniquement si elles ont été récemment visitées.Il existe un mécanisme de « résurrection » où si un bloc n’est plus stocké, n’importe qui peut récupérer ces données en fournissant une preuve de ce qu’elle est.

Les principales différences entre ces propositions sont les suivantes: (i) Comment définissons-nous « récemment », et (ii) comment définissons-nous les « blocs »?Une proposition spécifique est l’EIP-7736, qui s’appuie sur la conception de la «tige et des feuilles» introduite pour les arbres Verkle (bien que compatible avec toute forme d’arbres apatrides, tels que les arbres binaires).Dans cette conception, les en-têtes, les codes et les créneaux de stockage adjacents sont stockés sous la même « tige ».Les données stockées sous la tige peuvent atteindre 256 * 31 = 7 936 octets.Dans de nombreux cas, l’intégralité du titre et du code du compte, ainsi que de nombreuses emplacements de stockage clés, seront stockés sous la même colonne vertébrale.Si les données sous une épine dorsale donnée ne sont pas lues ou écrites dans les 6 mois, les données ne sont plus stockées, mais seulement l’engagement de 32 octets envers les données (« Stub »).Les transactions futures accédant à ces données nécessiteront de « ressusciter » les données et de fournir une preuve de vérification avec le talon.

Il existe d’autres moyens de mettre en œuvre des idées similaires.Par exemple, si l’intervalle de compte n’est pas suffisant, nous pouvons développer un plan où chaque 1/232 partie de l’arbre est contrôlée par un mécanisme de tige et de feuille similaire.

Ceci est encore plus délicat en raison de facteurs de motivation: un attaquant peut « mettre à jour l’arborescence » en mettant une grande quantité de données dans un seul sous-arbre et en envoyant une seule transaction chaque année, forçant le client à stocker en permanence une grande quantité d’État.Si vous effectuez le coût de mise à jour proportionnel à la taille de l’arborescence (ou à la durée de mise à jour inversement proportionnelle à la taille de l’arborescence), quelqu’un pourrait blesser un autre utilisateur en mettant beaucoup de données dans le même sous-arbre qu’eux.Vous pouvez essayer de limiter ces deux problèmes en régulant dynamiquement les intervalles de compte en fonction de la taille du sous-arbre: par exemple, chaque consécutif 2 ^ 16 = 65536 Les objets d’état peuvent être traités comme un « groupe ».Cependant, ces idées sont plus complexes;

Proposition d’expiration de l’État en fonction du cycle d’adresse

Et si nous voulons éviter toute croissance permanente de l’État, même un talon de 32 octets?Voici un puzzle: que se passe-t-il si l’objet d’état est supprimé, et plus tard l’exécution EVM met un autre objet d’état dans la même position exactement, mais la personne qui se soucie de l’objet d’état d’origine revient et essaie de le restaurer?Pour une expiration d’État, le talon empêche la création de nouvelles données.Pour l’expiration complète du statut, nous ne pouvons même pas stocker des talons.

La conception basée sur le cycle est le meilleur moyen de résoudre ce problème.Au lieu de stocker l’ensemble de l’État avec un arbre d’État, nous avons une liste croissante d’arbres d’État, et tous les états de lecture ou écrits sont sauvés dans le dernier arbre d’État.Ajoutez un nouvel arbre d’État vide à chaque cycle (pensez: 1 an).Les arbres d’État plus âgés sont fixes.Le nœud complet n’a besoin que de stocker les deux arbres les plus proches.Si l’objet d’état n’est pas touché dans les deux cycles et tombe donc dans l’arbre expiré, il peut toujours être lu ou écrit, mais la transaction doit le prouver – une fois terminé, la copie sera à nouveau enregistrée dans le dernier arbre Middle .

Une idée clé pour rendre tout cela convivial aux utilisateurs et aux développeurs est le concept de cycles d’adresse.Le cycle d’adresse est un nombre qui fait partie de l’adresse.Une règle clé est que les adresses avec une période d’adresse n ne peuvent être lues ou écrites que pendant ou après la période N (c’est-à-dire lorsque la liste des arborescences d’état atteint la longueur n).Si vous souhaitez enregistrer 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 avec une période d’adresse de N ou N-1, vous pouvez l’enregistrer Immédiatement sans ne lui donner aucune preuve de quoi que ce soit auparavant.D’un autre côté, tout ajout ou édition d’État dans l’ancien cycle d’adresse nécessite une preuve.

Cette conception conserve la plupart des propriétés actuelles d’Ethereum, avec un très petit calcul supplémentaire, permettant d’écrire presque comme ils le sont maintenant (ERC20 doit être réécrit pour s’assurer que l’équilibre des adresses avec la période d’adresse n est stocké en soi avec l’adresse Période n) et résolu le problème de « l’utilisateur entrant dans la grotte pendant cinq ans ».Cependant, il a un gros problème:L’adresse doit être étendue à plus de 20 octets pour s’adapter au cycle d’adresse.

Extension d’espace d’adressage

Une proposition consiste à introduire un nouveau format d’adresse de 32 octets qui inclut le numéro de version, le numéro de période d’adresse et la valeur de hachage étendue.

0x01000000000157AE408398DF7E5F4552091A69125D5DFCB7B8C2659029395BDF

Le rouge est le numéro de version.Ici, les quatre zéros orange représentent des espaces vides et peuvent accueillir les numéros de fragment à l’avenir.Le vert est le numéro de période d’adresse.Le bleu est un hachage de 26 octets.

Le principal défi ici est la compatibilité en arrière.Les contrats existants sont conçus autour des adresses de 20 octets et sont souvent utilisés avec des techniques d’emballage d’octets serrées, ce qui montre clairement que l’adresse est exactement de 20 octets.Une idée pour résoudre ce problème est d’utiliser un graphique de transformation où un contrat à l’ancienne qui interagit avec une adresse de style nouvelle verre verra un hachage de 20 octets de l’adresse de style nouveau.Cependant, il faut des efforts considérables pour assurer sa sécurité.

Traiter la contraction de l’espace

L’inverse: nous désactivons immédiatement certaines sous-greffes d’adresse de la taille 2128 (telles que toutes les adresses commençant par 0xffffffffff), puis utilisons cette plage pour introduire des adresses avec des périodes d’adresse et un hachage de 14 octets.

0xffffffff000169125d5dfcb7b8c2659029395bdf

Le sacrifice clé de cette approche est qu’il présente des risques de sécurité aux adresses contrefactuelles: adresses qui détiennent des actifs ou des autorisations mais dont le code n’a pas été publié dans la chaîne.Le risque implique que quelqu’un créant une adresse qui prétend avoir un code (non encore publié), mais il existe un autre code valide avec la valeur de hachage pointant vers la même adresse.Le calcul de ces collisions aujourd’hui nécessite 280 hachages;

La zone de risque critique, et non l’adresse contrefactuelle d’un portefeuille détenu par un seul propriétaire, est une situation relativement rare aujourd’hui, mais lorsque nous entrons dans le monde multi-L2, cette situation peut devenir plus courante.La seule solution consiste à accepter simplement ce risque, mais à identifier tous les cas d’utilisation courants où des problèmes peuvent survenir et à trouver des solutions efficaces.

Quelles recherches sont-elles disponibles?

Propositions précoces

Frais de location de blockchain:https://github.com/ethereum/eips/issues/35

Regenesis:https://ethreear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-log-blockchain-and-state/7582

Théorie de la gestion de la taille de l’État Ethereum:https://hackmd.io/@vbuterin/state_size_management

Plusieurs chemins possibles pour l’expiration apatride et étatique:https://hackmd.io/@vbuterin/state_expiry_paths

Certaines propositions d’expiration de statut

EIP-7736:https://eips.ethereum.org/eips/eip-7736

Document étendu de l’espace d’espace

Proposition originale:https://ethereum-magicicicic.org/t/inCreing-address-Size-from-20-to-32-bytes/5485

Commentaires Ipsilon:https://notes.ethereum.org/@ipsilon/address-space-extension-exploration

Article de blog Commentaires:https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address space-extension-60626544b8e6

Que se passe-t-il si nous perdons la résistance à la collision:https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-ressistant/11356

Que reste-t-il d’autre?Que peser?

Je pense qu’il y a quatre chemins viables à l’avenir:

• Nous pratiquons l’apatridité et n’introduisons jamais l’expiration de l’État.L’État augmente (bien que plus lent: nous ne le voyons peut-être pas plus de 8 To en décennies), mais il suffit d’être détenu par des catégories d’utilisateurs relativement professionnels: même les validateurs de POS n’ont pas besoin d’état.

  Une caractéristique qui nécessite l’accès à l’état partiel est d’inclure la génération de liste, mais nous pouvonsImplémentez cela de manière décentralisée:Chaque utilisateur est responsable du maintien de la partie d’arborescence d’état qui contient son propre compte.Lorsqu’ils diffusent les transactions, ils diffusent des preuves de l’objet de statut accessibles pendant l’étape de vérification (cela s’applique aux comptes EOA et ERC-4337).Le validateur apatride peut ensuite combiner ces preuves dans toute la preuve contenant la liste.

• Nous mettons en œuvre l’expiration partielle de l’État et acceptons un taux de croissance de la taille permanente permanente beaucoup plus bas mais non nul.Ce résultat peut être similaire à une proposition d’expiration historique impliquant des réseaux entre pairs, qui accepte un taux de croissance du stockage historique permanent que chaque client doit stocker un pourcentage inférieur mais fixe de données historiques, mais est beaucoup plus bas, mais toujours pas nulle.

• Nous déclarons la date d’expiration et étendons l’espace d’adresse.Cela impliquera un processus pluriannuel pour garantir que les méthodes de conversion de format d’adressage sont efficaces et sécurisées, y compris pour les applications existantes.

• Nous avons déclaré la date d’expiration et rétrécissé l’espace d’adresse.Cela impliquera un processus pluriannuel pour garantir que tous les risques de sécurité impliquant des conflits d’adresse, y compris les situations transversales, sont traités.

Un point important est que si un schéma d’expiration de l’État qui repose sur des modifications du format d’adresse est mis en œuvre, le problème de l’expansion et du rétrécissement de l’espace d’adressage doit finalement être résolu.Aujourd’hui, environ 2 ^ 80 hachages sont nécessaires pour générer des conflits d’adresse, et cette charge de calcul est déjà possible pour les participants extrêmement riches en ressources: le GPU peut faire environ 2 ^ 27 hachages, il peut donc être géré pendant un an. sont calculés, donc tout environ 2 ^ 30 GPU dans le monde peuvent calculer les conflits dans environ 1/4 de l’année, et les FPGA et les ASIC peuvent plus accélérer ce processus.À l’avenir, de telles attaques seront ouvertes à de plus en plus de personnes.Par conséquent, le coût réel de la mise en œuvre d’une expiration à l’état complet peut ne pas être aussi élevé qu’il y paraît, car nous devons résoudre ce problème d’adresse très difficile de toute façon.

Comment cela interagit-il avec le reste de la feuille de route?

L’exécution de l’expiration de l’État peut rendre la conversion d’un format d’arbre d’état à un autre car il n’y a pas besoin de processus de conversion: vous pouvez simplement commencer à faire un nouvel arbre avec un nouveau format, puis durcir plus tard Fork pour convertir l’ancien arbre.Ainsi, bien que l’expiration de l’État soit complexe, cela aide à simplifier d’autres aspects de la feuille de route.

Nettoyage fonctionnel

Quels problèmes résout-il?

L’une des principales conditions préalables à la sécurité, à l’accessibilité et à la fiabilité est la simplicité.Si le protocole est beau et simple, la possibilité d’erreurs est réduite.Il augmente les chances que les nouveaux développeurs puissent rejoindre et en utiliser n’importe quelle partie.Il est plus susceptible d’être juste et plus susceptible de résister aux intérêts particuliers.Malheureusement, les protocoles, comme tout système social, deviennent plus complexes par défaut au fil du temps.Si nous ne voulons pas faire entrer Ethereum dans un trou noir de plus en plus complexe, nous devons faire l’une des deux choses:(i) Arrêtez d’apporter des modifications et rigidez le protocole, (ii) être capable de supprimer réellement les fonctionnalités et de réduire la complexité.Les routes intermédiaires, c’est-à-dire apporter moins de modifications au protocole tout en éliminant au moins un peu de complexité au fil du temps, sont également possibles.Cette section explique comment réduire ou éliminer la complexité.

qu’est-ce que c’est?Comment ça marche?

Il n’y a pas de grande solution unique qui réduit la complexité du protocole;

Un exemple essentiellement fait qui peut être utilisé comme plan pour comment faire face à d’autres problèmes, à savoir la suppression de l’opcode d’autodestruction.L’opcode d’autodestruction est le seul opcode qui peut modifier un nombre illimité de créneaux de stockage dans un seul bloc, nécessitant une plus grande complexité des clients pour éviter les attaques DOS.Le but initial de cet opcode est d’atteindre la compensation volontaire de l’état, permettant à la taille de l’état de diminuer avec le temps.En fait, peu de gens finissent par l’utiliser.Cet opcode est affaibli, permettant uniquement les comptes d’autodestruction créés dans la même transaction dans la fourche dur Dencun.Cela résout les problèmes DOS et permet une simplification significative du code client.À l’avenir, il peut être logique de supprimer complètement l’opcode complètement.

Certains exemples clés des opportunités de simplification du protocole identifiés à ce jour comprennent les éléments suivants.Premièrement, quelques exemples en dehors de l’EVM;

• RLP → Conversion SSZ:Initialement, les objets Ethereum ont été sérialisés en utilisant un codage appelé RLP.Aujourd’hui, les chaînes de balises utilisent SSZ, ce qui est nettement mieux à bien des égards, notamment en soutenant non seulement la sérialisation mais aussi le hachage.En fin de compte, nous voulons nous débarrasser complètement du RLP et déplacer tous les types de données vers la structure SSZ, ce qui facilite la mise à niveau.Les EIP actuellement proposés pour cela incluent [1] [2] [3].

• Supprimer les anciens types de transactions:Il y a trop de types de transactions aujourd’hui, et beaucoup d’entre eux peuvent être supprimés.Une alternative plus modeste à la suppression complètement est la fonction d’abstraction du compte, à travers laquelle les comptes intelligents peuvent contenir des codes pour traiter et vérifier les transactions héritées (si elles le souhaitent).

• Réforme des journaux:Les journaux créent des filtres Bloom et d’autres logiques, ajoutant de la complexité au protocole, mais parce qu’il est trop lent, le client ne l’utilise pas réellement.Nous pouvons supprimer ces fonctionnalités et consacrer notre énergie à des alternatives, telles que des outils de lecture de journaux décentralisés hors protocole à l’aide de technologies modernes telles que Snark.

• Enfin, le mécanisme du comité de synchronisation de la chaîne de balises sera annulé:Le mécanisme du comité de synchronisation a été initialement introduit pour permettre l’authentification légère du client pour Ethereum.Cependant, cela ajoute la complexité du protocole.En fin de compte, nous pourrons utiliser Snark pour vérifier directement la couche consensus Ethereum, qui éliminera le besoin d’un protocole de vérification de client léger dédié.En créant un protocole client léger plus « natif » qui implique de valider les signatures à partir d’un sous-ensemble aléatoire du validateur de consensus Ethereum.

• Coordination du format de données:Aujourd’hui, l’état d’exécution est stocké dans l’arbre Merkle Patricia, l’état de consensus est stocké dans l’arbre SSZ, et les blobs sont soumis comme KZG promises.À l’avenir, il est logique de créer un format unifié unique pour les données de bloc et l’état.Ces formats couvriront tous les besoins importants: (i) une preuve simple des clients sans état, (ii) la sérialisation et le codage d’effacement des données et (iii) des structures de données standardisées.

• Comité de la chaîne de balise de suppression:Ce mécanisme a été initialement introduit pour prendre en charge des versions spécifiques de la rupture d’exécution.Au lieu de cela, nous finissons par les clos de L2 et Blob.Par conséquent, le comité n’est pas nécessaire et travaille à le supprimer.

• Supprimer la commande d’octets mixtes:L’EVM est un ordre d’octet en grande est -didien, et la couche consensuelle est un ordre d’octet peu enlan.Cela pourrait être logique de se re-coordonner et de faire de tout Big-Endian Endian (probablement en Endien de Big-endian, car EVM est plus difficile à changer).

Maintenant, quelques exemples à l’intérieur de l’EVM:

• Simplifiez le mécanisme du gaz:Les règles de gaz actuelles n’ont pas encore été bien optimisées et il est impossible de limiter explicitement le nombre de ressources nécessaires pour vérifier le bloc.Des exemples clés de cela incluent (i) les coûts de lecture / écriture de stockage, conçus pour limiter les temps de lecture / d’écriture dans un bloc, mais sont actuellement très arbitraires, et (ii) des règles de remplissage de mémoire, qui sont actuellement difficiles à estimer la consommation maximale de mémoire de L’EVM.Les correctifs recommandés incluent les changements de coût du gaz sans état, la réconciliation de tous les coûts liés au stockage dans une formule simple et les recommandations de tarification de la mémoire.

• Supprimer la précompilation:De nombreuses précompilations dont Ethereum a aujourd’hui ne sont à la fois pas nécessaires et relativement inutilisées, et tiennent compte d’une grande proportion de risques d’insuffisance consensuelle, mais ne sont réellement utilisés par aucune application.Deux façons de résoudre ce problème sont (i) supprimant directement la précompilation, et (ii) le remplacer par du code EVM (et inévitablement plus cher) qui implémente la même logique.Ce projet EIP recommande de le faire d’abord pour la précompilation d’identité;

• Retirer l’observabilité du gaz:Fait que l’exécution EVM ne peut plus voir la quantité de gaz qu’il a laissé.Cela rompt certaines applications (les offres le plus visiblement parrainées), mais peut être améliorée plus facilement à l’avenir (par exemple, pour des versions de gaz multidimensionnelles plus avancées).La spécification EOF a rendu le gaz inobservable, mais pour faciliter la simplification du protocole, l’EOF doit être obligatoire.

• Améliorations à l’analyse statique:Le code EVM d’aujourd’hui est difficile à effectuer une analyse statique, d’autant plus que les sauts peuvent être dynamiques.Cela rend également plus difficile la réalisation d’une implémentation EVM optimisée (code EVM précompilé dans d’autres langues).Nous pouvons résoudre ce problème en supprimant les sauts dynamiques (ou en les rendant plus chers, par exemple, les coûts de gaz sont linéairement liés au nombre total de facteurs de saut dans le contrat).C’est ce que fait l’EOF, mais obtenir les avantages de la simplification du protocole nécessite de rendre l’EOF obligatoire.

Quelles recherches sont-elles disponibles?

Étapes suivantes pour Purge:https://notes.ethereum.org/i_aihysjttcyau_adoy2ta

Auto-destruction:https://hackmd.io/@vbuterin/selfdestruct

EIPS-SSZ-iification: [1] [2] [3]

Changements de coût du gaz sans état:https://eips.ethereum.org/eips/eip-4762

Prix ​​de mémoire linéaire:https://notes.ethereum.org/ljptsqbgr2knssu0yurwxw

Précompilé et supprimé:https://notes.ethereum.org/iwtx22ymqde1k_fz9psxig

Retrait du filtre de floraison:https://eips.ethereum.org/eips/eip-7668

Une méthode de récupération de journaux sécurisée hors chaîne à l’aide de calculs vérifiables incrémentiels (lire: Stark récursif):https://notes.ethereum.org/xzuqy8znt3keg1pkzpefxw

Que dois-je faire d’autre et quels compromis y a-t-il?

Le compromis principal pour une telle simplification fonctionnelle est (i) le degré et la vitesse de notre simplification avec (ii) la compatibilité vers l’arrière.La valeur d’Ethereum en tant que chaîne est qu’il s’agit d’une plate-forme où vous pouvez déployer des applications et s’assurer qu’elle fonctionnera toujours correctement après de nombreuses années.Dans le même temps, il est également possible de mettre cet idéal trop loin, selon les mots de William Jennings Brian, « Nail Ethereum sur la croix de la compatibilité arrière ».Si seulement deux applications de l’ensemble de l’Ethereum utilisent une fonctionnalité, dont l’une ne comporte pas d’utilisateurs depuis des années et l’autre n’a presque aucune utilité et a reçu un total de 57 $, alors nous devrions supprimer la fonctionnalité, si nécessaire, peut payer 57 $ de votre propre poche à la victime.

Le problème social plus large consiste à créer un pipeline standardisé pour les changements perturbateurs de compatibilité arrière non urgents.Une façon de résoudre ce problème consiste à vérifier et à étendre les précédents existants, tels que le processus d’autodestruction.Le tuyau ressemble à ceci:

• Étape 1:Commencez à discuter de la fonction de suppression X.

• Étape 2:Effectuer une analyse pour déterminer la quantité destructrice de l’application à faire en supprimant X, choisissez (i) pour abandonner l’idée, (ii) pour procéder comme prévu, ou (iii) pour déterminer une méthode «minimale destructrice» modifiée et de supprimer x et continuer.

• Étape 3:Créez un EIP formel pour déprécier X.Assurez-vous que les infrastructures avancées populaires (telles que les langages de programmation, les portefeuilles) respectent cela et arrêtez d’utiliser la fonctionnalité.

• Étape 4:Enfin, supprimez en fait X.

Il devrait y avoir un processus de plusieurs années entre les étapes 1 et 4, et indiquer clairement quels projets sont dans quelle étape.À ce stade, il existe un compromis entre la force et la vitesse du processus d’élimination des fonctionnalités et les domaines les plus conservateurs et autres d’investir plus de ressources dans le développement du protocole, mais nous sommes encore loin de la pointe de Pareto.

Eof

L’un des principaux changements proposés pour EVM est le format d’objet EVM (EOF).L’EOF introduit de nombreux changements, tels que l’interdiction de l’observabilité du gaz, l’observabilité du code (c’est-à-dire pas de codécopie) et ne permettant que des sauts statiques.L’objectif est de permettre aux EVM d’effectuer plus de mises à niveau pour avoir des propriétés plus puissantes tout en maintenant une compatibilité en arrière (car les EVM avant EOF existent toujours).

L’avantage de cela est qu’il crée un chemin naturel pour ajouter de nouvelles capacités EVM et encourager la migration vers des EVM plus strictes avec des garanties plus fortes.Son inconvénient est qu’il augmente considérablement la complexité du protocole, sauf si nous pouvons trouver des moyens de déprécier et de supprimer les anciens EVM.Un problème majeur est:Quel rôle joue l’EOF dans les propositions de simplification EVM, surtout si l’objectif est de réduire la complexité de l’ensemble de l’EVM?

Comment cela interagit-il avec le reste de la feuille de route?

De nombreuses propositions «Améliorations» dans le reste de la feuille de route sont également des opportunités de simplifier les anciennes fonctionnalités.Répétez quelques exemples ci-dessus:

• Le passage à la finalité des créneaux uniques nous donne la possibilité d’annuler les comités, de réingermer l’économie et de faire d’autres simplifications liées à la preuve de la participation.

• La mise en œuvre complète de l’abstraction du compte nous permet de supprimer de nombreuses logiques de traitement des transactions existantes en le déplaçant dans un « code EVM de compte par défaut » dont tous les EOA peuvent être remplacés.

• Si nous déplaçons l’état Ethereum vers l’arbre de hachage binaire, cela peut être coordonné avec la nouvelle version de SSZ afin que toutes les structures de données Ethereum puissent être hachées de la même manière.

Une approche plus radicale: convertir la majeure partie du protocole en code contractuel

Une stratégie de simplification Ethereum plus radicale consiste à conserver le protocole tel quel, mais à transformer une grande partie du protocole de la fonctionnalité du protocole au code contractuel.

La version la plus extrême consiste à faire des chaînes de balises Ethereum L1 « techniquement » et à introduire une machine virtuelle minimale (telle que RISC-V, Cairo ou des machines virtuelles plus simples spécifiquement utilisées pour prouver le système) qui permettent à quiconque de se créer un résumé.Ensuite, l’EVM sera le premier de ces résumés.Ironiquement, c’est exactement le même résultat que la proposition d’environnement de mise en œuvre 2019-20, bien que Snark le rend plus possible de mettre en œuvre.

Une approche plus modeste consiste à maintenir la relation entre la chaîne de balises et l’environnement d’exécution d’Ethereum actuel inchangé, mais d’échanger des EVM en place.Nous pouvons choisir RISC-V, le Caire ou d’autres machines virtuelles comme la nouvelle « VM Ethereum officielle », puis lancer tous les contrats EVM dans un nouveau code VM qui interprète la logique du code d’origine (par compilation ou interprétation).En théorie, il est même possible de le faire avec la « VM cible » comme version EOF.

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