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

L’un des défis auxquels fait face Ethereum est que, par défaut, l’expansion et la complexité de n’importe quel protocole de la Blockchain augmentent avec le temps. Cela se produit à deux endroits :

· Données historiques : Toutes les transactions effectuées et tous les comptes créés à n’importe quel moment de l’histoire doivent être stockés en permanence par tous les clients et téléchargés par tout nouveau client pour une synchronisation complète avec le réseau. Cela entraîne une augmentation constante de la charge et du temps de synchronisation des clients au fil du temps, même si la capacité de la chaîne reste inchangée.

· Fonction protocole: Ajouter de nouvelles fonctionnalités est beaucoup plus facile que supprimer d’anciennes fonctionnalités, ce qui entraîne une complexité croissante du code avec le temps.

Pour assurer la durabilité à long terme d’Ethereum, nous devons exercer une forte pression contraire sur ces deux tendances, avec le temps, pour réduire la complexité et l’expansion. Mais en même temps, nous devons conserver l’une des caractéristiques clés qui rendent la blockchain géniale : la persistance. Vous pouvez mettre un jeton non fongible, une lettre d’amour dans les données d’une transaction, ou un contrat intelligent contenant 1 million de dollars hors chaîne, dans une grotte pendant dix ans et le retrouver intact pour le lire et y interagir. Pour permettre aux DApps de fonctionner en toute décentralisation complète et de supprimer les clés secrètes de mise à niveau, ils doivent être certains que leurs dépendances ne se mettront pas à jour de manière à les perturber, en particulier L1 lui-même.

Si nous sommes déterminés à trouver un équilibre entre ces deux demandes et à réduire ou inverser au maximum l’encombrement, 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, certains chanceux ne le font pas. Même les systèmes sociaux peuvent avoir une longue durée de vie. Dans certains cas, Ethereum a déjà réussi : la preuve de travail a disparu, la plupart des codes d’opération SELFDESTRUCT ont disparu, et le nœud beacon chain stocke les données anciennes depuis six mois maximum. Trouver le chemin le plus général pour Ethereum et atteindre un résultat final stable à long terme est le défi ultime de la longue durée de l’évolutivité, de la durabilité technique et même de la sécurité d’Ethereum.

The Purge: principaux objectifs.

· Réduisez les besoins de stockage des clients en réduisant ou en éliminant la nécessité pour chaque nœud de stocker de manière permanente tout l’historique et même l’état final.

· En réduisant la complexité en éliminant les fonctionnalités inutiles du protocole.

Table des matières de l’article :

· History expiry（历史记录到期）

· Expiration de l’état

Nettoyage des fonctionnalités

Expiration de l’historique

Quel problème résout-il ?

Au moment de la rédaction du présent document, un nœud complet d’Éther 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 ces données sont historiques : des données sur l’historique des blocs, des transactions et des reçus, dont la plupart remontent 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 simplification des problèmes de stockage historique est que, puisque chaque bloc est lié par hachage (et d’autres structures) au bloc précédent, 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 par une preuve de Merkle, et cette preuve permet à quiconque de vérifier sa validité. 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 est que chaque Nœud stocke uniquement une petite partie des données du réseau. C’est ainsi que le réseau de semences a fonctionné pendant des décennies : bien que le réseau stocke et distribue au total des millions de fichiers, chaque participant ne stocke et ne distribue que quelques-uns de ces fichiers. Contrairement à l’intuition, cette méthode ne garantit même pas la Goutte de la robustesse des données. En rendant l’exploitation des Nœuds plus économique, nous pourrions mettre en place un réseau de 100 000 Nœuds, chacun stockant aléatoirement 10 % de l’historique, de sorte que chaque donnée serait reproduite 10 000 fois - exactement le même facteur de reproduction que pour un réseau de 10 000 Nœuds, où chaque Nœud stocke l’intégralité du contenu.

Maintenant, Ethereum commence à se débarrasser du modèle où chaque nœud stocke l’historique de manière permanente. La partie Consensus (c’est-à-dire celle liée à la Preuve d’enjeu) stocke seulement environ 6 mois de blocs. Le Blob stocke seulement environ 18 jours. L’EIP-4444 vise à introduire une période de stockage d’un an pour les blocs et les reçus historiques. L’objectif à long terme est de créer une période unifiée (probablement d’environ 18 jours), au cours de laquelle chaque nœud est responsable de stocker tous les contenus, puis de créer 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é codé en effacement pour prendre en charge l’échantillonnage de disponibilité des données. La solution la plus simple serait probablement de réutiliser ces codes d’effacement et d’inclure également les données de bloc d’exécution et de consensus dans le blob.

Quels sont les liens avec les recherches existantes?

· EIP-4444 ；

· Torrents et EIP-4444 ;

· Réseau de portail；

· 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 encore faire et quels sont les compromis à faire ?

Les principales tâches restantes incluent la construction et l’intégration d’une solution distribuée concrète pour stocker l’historique - au moins l’exécution de l’historique, mais finalement aussi le Consensus et le blob. La solution la plus simple consiste à (i) simplement introduire les bibliothèques torrent existantes et (ii) une solution native d’ETH appelée réseau Portal. Une fois qu’un des deux est introduit, nous pouvons ouvrir EIP-4444. EIP-4444 ne nécessite pas de hard fork en soi, mais nécessite une nouvelle version de protocole réseau. Par conséquent, il est précieux 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œud en espérant télécharger l’historique complet mais ne le récupèrent pas en réalité.

Les principaux compromis concernent la façon dont nous nous efforçons de fournir des données historiques “anciennes”. La solution la plus simple serait d’arrêter de stocker les anciennes données dès demain et de s’appuyer sur les nœuds d’archive existants et divers fournisseurs centralisés pour la duplication. Cela serait facile à faire, mais cela affaiblirait la position d’Ethereum en tant que lieu d’enregistrement permanent. La voie la plus difficile mais plus sécurisée consiste à construire et à intégrer d’abord un réseau torrent pour stocker les archives de manière décentralisée. Ici, “combien d’efforts nous déployons” a deux dimensions :

1. Comment nous assurons-nous que le plus grand ensemble de nœuds stocke réellement toutes les données ?

2. Jusqu’à quelle profondeur avons-nous intégré l’historique de stockage dans le protocole Depth ?

Pour une approche extrêmement paranoïaque de (1), cela impliquerait une attestation de dépôt : en fait, chaque validateur de Preuve d’enjeu serait requis de stocker un certain pourcentage d’historique et de le vérifier régulièrement de manière chiffrée. Une approche plus douce serait de définir une norme volontaire pour le pourcentage d’historique stocké par chaque client.

Pour (2), la mise en œuvre de base ne concerne que le travail déjà effectué aujourd’hui : le portail a déjà stocké le fichier ERA contenant toute l’histoire 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 d’historique complet ou un nœud d’archive, même en l’absence d’autres nœuds d’archive en ligne, ils peuvent le faire en synchronisant directement depuis le réseau du portail.

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

Si nous voulons rendre l’exécution ou le démarrage du nœud Nœud extrêmement facile, alors réduire les besoins de stockage historique est peut-être plus important que l’état sans état : sur les 1,1 To nécessaires au nœud Nœud, environ 300 Go sont l’état, et les 800 Go restants sont devenus historiques. Seule la réalisation de l’état sans état et de l’EIP-4444 permet de réaliser la vision d’exécuter un nœud ETH sur une montre intelligente et de le configurer en quelques minutes seulement.

La limitation du stockage historique rend également plus réalisable la mise en place de nouveaux nœuds Ethereum, ne prenant en charge que les versions les plus récentes du protocole, ce qui les rend plus simples. Par exemple, il est maintenant possible de supprimer en toute sécurité de nombreuses lignes de code, car tous les emplacements de stockage vides créés pendant l’attaque DoS de 2016 ont été supprimés. Maintenant que le passage à la Preuve d’enjeu est devenu de l’histoire ancienne, les clients peuvent en toute sécurité supprimer tout le code lié à la Preuve de travail.

Expiration de l’état

Quel problème résout-il ?

Même si nous éliminons le besoin d’historique de stockage côté client, les besoins de stockage côté client continueront de augmenter, d’environ 50 Go par an, car l’état continue d’augmenter : solde du compte et nombres aléatoires, code de contrat et stockage de contrat. Les utilisateurs peuvent payer des frais ponctuels, ce qui représente un fardeau permanent pour les clients actuels et futurs d’Éther.

La mise à jour de l’état est plus difficile que l’historique, car l’EVM a été conçue sur l’hypothèse fondamentale qu’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-état, certains pensent que ce problème pourrait ne pas être si grave : seules les classes de constructeurs de bloc spécifiques ont besoin de stocker réellement l’état, tandis que tous les autres nœuds (même les générateurs de listes !) peuvent fonctionner sans état. Cependant, certains estiment que nous ne voulons pas trop dépendre de la non-état, et à terme, nous souhaitons peut-être 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 (qui 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 une fente de stockage précédemment inutilisée), cet objet d’état reste toujours dans cet état. Au lieu de cela, ce que nous voulons, c’est que l’objet expire automatiquement avec le temps. Le défi clé est de le faire de manière à atteindre les trois objectifs.

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

2. Convivialité pour les utilisateurs : si une personne entre dans une grotte pendant cinq ans et revient, elle ne devrait pas perdre l’accès à sa position ETH, ERC 20, NFT Jeton non fongible, CDP…

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

Il est facile de résoudre ces problèmes si ces objectifs ne sont pas satisfaits. Par exemple, vous pouvez faire en sorte que chaque objet d’état stocke également un compteur de dates d’expiration (qui peut être prolongé en brûlant de l’ETH, ce qui peut se produire automatiquement à tout moment de la lecture ou de l’écriture) et dispose d’une procédure d’itération de l’état pour supprimer les dates d’expiration. Cependant, cela introduit des calculs supplémentaires (ou même des exigences de stockage) et il ne peut certainement pas répondre aux exigences conviviales pour les utilisateurs. Les développeurs ont également du mal à raisonner sur les cas limites où les valeurs de stockage sont parfois réinitialisées à zéro. Si vous définissez un minuteur d’expiration dans le contrat, cela facilitera techniquement la vie des développeurs, mais cela rendra l’économie plus difficile : les développeurs doivent réfléchir à la façon de « transférer » les coûts de stockage continus aux utilisateurs.

Ce sont des problèmes que la communauté de développement principale d’Ethereum a travaillé dur pour résoudre au fil des ans, notamment les propositions telles que la “location de chaîne Bloc” et le “renouvellement”. Finalement, nous avons combiné les meilleurs éléments des propositions et nous sommes concentrés sur deux types de “solutions connues comme étant les moins mauvaises” :

Solution partielle d’expiration de l’état

· Recommandation d’expiration de l’état basée sur le cycle d’Adresse.

Expiration partielle de l’état

Certains projets de proposition d’expiration d’état suivent les mêmes principes. Nous divisons l’état en blocs. Chacun stocke en permanence une “carte de niveau supérieur”, où le bloc est vide ou non vide. Les données dans chaque bloc ne sont stockées que lorsqu’elles ont été récemment consultées. Il existe un mécanisme de “résurrection” pour les données qui ne sont plus stockées.

Les principales différences entre ces propositions sont les suivantes : (i) Comment définissons-nous la notion de « récemment » et (ii) Comment définissons-nous le concept de « bloc » ? Une proposition concrète est l’EIP-7736, qui repose sur la conception des « branches » introduite pour les arbres Verkle (bien qu’elle soit compatible avec tout état sans état, comme les arbres binaires). Dans cette conception, les en-têtes, le code et les emplacements de stockage adjacents sont stockés sous une même « branche ». Les données stockées sous une branche peuvent contenir jusqu’à 256 * 31 = 7 936 octets. Dans de nombreux cas, l’intégralité de l’en-tête et du code du compte, ainsi que de nombreux emplacements de stockage de clés, seront stockés sous une même branche. Si les données sous une branche donnée ne sont ni lues ni écrites pendant 6 mois, elles ne seront plus stockées et seulement un engagement de 32 octets de ces données (« ébauche ») sera conservé. Les transactions futures qui accèdent à ces données devront « ressusciter » les données et fournir une preuve basée sur l’ébauche pour vérification.

Il existe d’autres moyens de réaliser des idées similaires. Par exemple, si le niveau de granularité du compte n’est pas suffisant, nous pouvons élaborer un plan où chaque moitié de 32 parties de l’arbre est contrôlée par un mécanisme similaire de branches et de feuilles.

En raison des incitations, cela devient encore plus difficile : un attaquant peut forcer un 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 faites en sorte que le coût de renouvellement soit proportionnel à la taille de l’arbre (ou inversement proportionnel à 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 2^16 = 65536 objets d’état consécutifs peuvent être considérés comme un “groupe”. Cependant, ces idées sont plus complexes ; les approches basées sur le tronc sont plus simples et peuvent ajuster les incitations, car toutes les données sous le tronc sont généralement liées à la même application ou au même utilisateur.

Proposition de fin de cycle basée sur 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 ? Lorsque certains états expirent, 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.

Le concept le plus célèbre pour résoudre ce problème est basé sur la conception d’une hausse périodique de l’Adresse. Plutôt que de stocker l’intégralité de l’état dans un arbre d’états, nous disposons d’une liste d’arbres d’états en hausse continue, et tout état lu ou écrit est conservé dans le dernier arbre d’états. Un nouvel arbre d’états vide est ajouté à chaque période (par exemple : 1 an). Les anciens arbres sont gelés solidement. Le Nœud complet ne stocke que les deux derniers arbres. Si un objet d’état n’est pas touché pendant deux périodes, et donc tombe dans l’arbre expiré, il peut toujours être lu ou écrit, mais la transaction doit prouver son arbre de Merkle - une fois prouvé, une copie est à nouveau conservée dans le dernier arbre.

Une idée clé qui est conviviale à la fois pour les utilisateurs et les développeurs est le concept de cycle d’Adresse. Le cycle d’Adresse est un nombre qui fait partie de l’Adresse. La règle clé est que seule une Adresse avec un cycle N peut être lue ou écrite pendant ou après le cycle N (c’est-à-dire lorsque la liste de l’arbre d’état atteint une longueur N). Si vous souhaitez enregistrer un nouvel objet d’état (par exemple, un nouveau contrat ou un solde ERC 20), vous pouvez le faire immédiatement sans avoir à fournir de preuve si vous vous assurez de placer l’objet d’état dans un contrat avec un cycle d’Adresse de N ou N-1. En revanche, toute addition ou modification effectuée pendant une ancienne Adresse nécessite une preuve.

Cette conception conserve la plupart des propriétés actuelles d’Ethereum sans avoir besoin de calculs supplémentaires, ce qui permet aux applications d’être écrites presque telles qu’elles sont aujourd’hui (ERC 20 doit être réécrit pour s’assurer que le solde de l’adresse avec une période d’adresse N est stocké dans un contrat de sous-traitance, lui-même avec une période d’adresse N), et résout le problème des « utilisateurs vont dans une grotte pendant cinq ans ». Cependant, il a un gros problème : Adresse doit évoluer au-delà de 20 octets pour s’adapter au cycle Adresse.

Extension de l’espace d’adressage Adresse空间扩展

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

0x01 (rouge) 0000 (orange) 000001 (vert) 57 aE408398 dF7 E5 f4552091 A69125 d5dFcb7B8C2659029395bdF (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 de l’Adresse. Le bleu est la valeur de hachage de 26 octets.

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

L’espace d’Adresse se réduit

另一种方法采取相反的方向：我们立即禁止一些 2 128 大小的Adresse子范围（例如，所有以 0x ffffffff 开头的Adresse），然后使用该范围引入具有Adresse周期和 14 字节哈希值的Adresse。

0xffffffff000169125 d5dFcb7B8C2659029395bdF

Le principal sacrifice de cette méthode est l’introduction d’un risque de sécurité Adresse contrefactuelle : une Adresse qui prétend détenir des actifs ou des autorisations, mais dont le code n’a pas encore été publié sur la chaîne. Le risque est qu’une personne crée une Adresse prétendant détenir un morceau de code (non encore publié), mais qu’il existe également un autre morceau de code valide qui a le même hash que cette Adresse. Aujourd’hui, il faut calculer une telle collision avec 2^80 hash ; la réduction de l’espace des Adresses réduirait ce nombre à 2^56 hash, ce qui est beaucoup plus accessible.

Dans les domaines à risque clés, les adresses anti-factuelles de Portefeuille détenues par des propriétaires non uniques sont relativement rares aujourd’hui, mais pourraient devenir plus courantes à mesure que nous entrons dans un monde L2 plus complexe. La seule solution est d’accepter simplement ce risque, mais il est essentiel 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 précoce

Bloc链清洁；

Régénération;

Théorie de gestion de la taille de l’état d’Ethereum;

Quelques chemins possibles pour les états non authentifiés et les états expirés;

Certaines propositions d’expiration de l’état

EIP-7736 ；

Document d’extension d’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 encore faire et quels sont les compromis à faire ?

Je pense qu’il y a quatre voies viables pour l’avenir:

· Nous restons sans état et n’introduisons jamais d’expiration d’état. L’état augmente constamment (bien que lentement : nous ne pouvons peut-être pas le voir dépasser 8 TB pendant des décennies), mais il n’est nécessaire que pour des catégories d’utilisateurs relativement spéciales : même les validateurs PoS n’ont pas besoin d’état.

Une fonctionnalité qui nécessite l’accès à une partie de l’état est la génération de listes, mais nous pouvons accomplir cette opération de manière distribuée : chaque utilisateur est responsable de la maintenance d’une partie de l’arbre d’état contenant son propre compte. Lorsqu’ils diffusent une transaction, ils diffusent également une preuve de l’objet d’état auquel ils ont accédé pendant l’étape de vérification (cela s’applique aux comptes EOA et ERC-4337). Ensuite, un validateur sans état peut combiner ces preuves en une preuve complète contenant la liste.

· Nous arrivons à l’expiration de certaines parties de l’état 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 dit similaire à la façon dont les propositions expirées historiques impliquant des réseaux pair-à-pair acceptent que chaque client doit stocker un taux de croissance de l’historique permanent beaucoup plus bas mais toujours non nul des données historiques.

Nous utilisons une extension d’espace d’Adresse pour la gestion des états expirés. Il s’agira d’un processus de plusieurs années pour garantir l’efficacité et la sécurité de la méthode de conversion de format d’Adresse, y compris pour les applications existantes.

· Nous utilisons la réduction de l’espace Adresse pour expirer les états. 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) sont traités.

Une chose importante est que, qu’il s’agisse ou non de mettre en œuvre un plan d’expiration de l’état dépendant des modifications de format d’Adresse, il faudra finalement résoudre les problèmes d’expansion et de contraction de l’espace Adresse. Aujourd’hui, il faut environ 2^80 valeurs de hachage pour générer des conflits d’Adresse, ce qui est réalisable pour les acteurs très riches en ressources : les GPU peuvent exécuter environ 2^27 valeurs de hachage, de sorte qu’ils peuvent calculer une collision en environ un quart d’année, et les FPGA et ASIC peuvent accélérer ce processus encore plus. À l’avenir, de telles attaques seront de plus en plus accessibles à un plus grand nombre de personnes. Par conséquent, le coût réel de la mise en œuvre d’un plan d’expiration complet de l’état pourrait ne pas être aussi élevé qu’il n’y paraît, car nous devons de toute façon résoudre ce problème d’Adresse très difficile.

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

La possibilité d’expiration de l’état peut rendre la conversion d’un format d’arbre d’état à un autre plus facile, 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 présente des avantages pour simplifier d’autres aspects de la feuille de route.

Feature cleanup

Quel problème cela résout-il?

L’une des conditions préalables essentielles à la sécurité, à l’accessibilité et à la neutralité de confiance est la simplicité. Si le protocole est esthétique et simple, cela réduira la probabilité d’erreurs. Cela augmente les chances pour de nouveaux développeurs de participer à n’importe quelle partie. Il est plus susceptible d’être équitable et également plus résistant aux intérêts particuliers. Malheureusement, le protocole, comme tout système social, a tendance à devenir de plus en plus complexe avec le temps. Si nous ne voulons pas que Ethereum tombe dans le piège d’une complexité croissante, nous devons faire l’une des deux choses suivantes : (i) arrêter de faire des changements et rendre le protocole figé, (ii) être en mesure de réellement supprimer des fonctionnalités et réduire la complexité. Un compromis intermédiaire est également possible, c’est-à-dire apporter moins de modifications au protocole et éliminer au moins un peu de complexité avec le temps. Cette section discutera de la façon de réduire ou d’éliminer la complexité.

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

Il n’y a pas de correction unique majeure qui puisse réduire la complexité de Goutteprotocole; la nature de ce problème réside dans de nombreuses petites solutions.

Un exemple partiellement accompli est le retrait de l’opération SELFDESTRUCT et peut servir de modèle pour traiter d’autres exemples. L’opération SELFDESTRUCT est la seule opération qui permet de 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 cette 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é, peu de personnes l’ont finalement utilisée. L’opération a été affaiblie pour ne permettre que la création de compte autodétruit dans la même transaction que celle créée lors du hard fork de Dencun. Cela résout le problème DoS et peut grandement simplifier le code client. À l’avenir, il pourrait être judicieux de supprimer complètement cette opération.

Jusqu’à présent, quelques exemples clés de protocole simplifié ont été déterminés, notamment. Tout d’abord, quelques exemples en dehors de l’EVM ; ceux-ci sont relativement non invasifs, donc plus faciles à atteindre Consensus et à mettre en œuvre en moins de temps.

· Conversion RLP → SSZ : Initialement, les objets Ethereum étaient sérialisés en utilisant un encodage appelé RLP. RLP est non typé et inutilement complexe. Aujourd’hui, la beacon chain utilise SSZ, qui est nettement meilleur à bien des égards, notamment en prenant en charge non seulement la sérialisation mais aussi le hash. Finalement, nous espérons 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] [3].

· Supprimer les anciens types de transactions : Il existe actuellement trop de types de transactions, dont beaucoup pourraient être supprimés. Une alternative plus douce à la suppression complète est la fonction d’abstraction de compte, où les comptes intelligents peuvent inclure le code pour traiter et valider les anciens types de transactions (s’ils le souhaitent).

· Réforme des journaux : la création de filtres bloom et d’autres logiques de journal a augmenté la complexité du protocole, mais en réalité, ils ne sont pas utilisés par le client car ils sont trop lents. Nous pouvons supprimer ces fonctionnalités et nous concentrer sur des solutions alternatives, telles que l’utilisation de la technologie moderne SNARK pour les outils de lecture de journal décentralisés.

· Suppression finale du mécanisme de synchronisation du comité de la chaîne de balise : le mécanisme de synchronisation du comité a été initialement introduit pour permettre la vérification du client léger de l’ETH. Cependant, il augmente considérablement la complexité du protocole. Finalement, nous serons en mesure d’utiliser directement la vérification SNARK de la couche de consensus de l’ETH, ce qui éliminera le besoin d’un protocole de vérification de client léger dédié. Potentiellement, les modifications du consensus pourraient nous permettre de supprimer plus tôt le comité de synchronisation en créant un protocole de client léger plus ‘natif’ qui impliquerait la vérification des signatures d’un sous-ensemble aléatoire de validateurs de consensus de l’ETH.

· Unification des formats de données : 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 à un engagement KZG. À l’avenir, il sera logique de définir un format unifié unique pour les données de bloc et un format unifié unique pour l’état. Ces formats répondront à tous les besoins importants : (i) preuves simples pour les clients sans état, (ii) sérialisation des données et codage d’effacement, (iii) structure de données normalisée.

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

· Supprimer l’ordre des octets mixtes : EVM est big-endian, la couche de consensus est little-endian. Il peut être significatif de réharmoniser et de rendre tout cohérent dans l’une ou l’autre forme (peut-être big-endian car EVM est plus difficile à changer)

Quelques exemples dans l’EVM maintenant :

· Simplification du mécanisme de gas : Les règles actuelles du gas n’ont pas encore été bien optimisées et ne peuvent pas fournir de limites claires pour les ressources nécessaires à la validation 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 dans un bloc, mais qui est actuellement assez arbitraire, et (ii) les règles de remplissage de la mémoire, qui rendent actuellement difficile d’estimer la consommation maximale de mémoire de l’EVM. Les mesures de correction 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 : De nombreux précompilations actuellement présentes dans Ethereum sont à la fois inutilement complexes, relativement inutilisées et constituent une grande partie de l’échec du consensus, étant donné qu’elles sont utilisées par presque aucune application. Deux approches pour résoudre ce problème sont (i) la simple suppression des précompilations, et (ii) leur remplacement par une section de code EVM mettant en œuvre la même logique (inévitablement plus coûteuse). Ce brouillon de l’EIP suggère de commencer par appliquer cette opération aux précompilations d’identité ; plus tard, RIPEMD 160, MODEXP et BLAKE pourraient être des candidats à la suppression.

· Suppression de la visibilité du gas : l’EVM ne pourra plus voir combien de gas il reste à exécuter. Cela affectera certaines applications (notamment les transactions de parrainage), mais facilitera les futures mises à niveau (par exemple, vers des versions plus avancées du gas multidimensionnel). La spécification EOF a déjà rendu le Gas non observable, mais elle doit devenir obligatoire pour simplifier le protocole.

· Amélioration de l’analyse statique : il est actuellement difficile de réaliser une analyse statique du code EVM, en particulier en raison de la possibilité de sauts dynamiques. Cela rend également plus difficile l’optimisation de la mise en œuvre de l’EVM (précompilation du code EVM dans d’autres langages). 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 gas est linéaire par rapport au nombre total de JUMPDEST dans le contrat). C’est ce que fait EOF, bien que l’application forcée de EOF soit nécessaire pour tirer des avantages de simplification du protocole.

Quels sont les liens avec les recherches existantes?

· Étapes suivantes pour effacer;

Auto-destruction

· SSZ transformation EIPS: [1] [2] [3];

· Coût du gaz sans état changeant ;

· Tarification linéaire de la mémoire ;

· Suppression de la compilation préalable ;

· Suppression du filtre bloom;

· Une méthode de recherche sécurisée de journaux utilisant le calcul vérifiable incrémentiel hors chaîne (lire : STARK récursif) ;

Que faut-il encore faire et quels sont les compromis à faire ?

Le principal compromis de cette simplification fonctionnelle est (i) le degré et la rapidité de notre simplification et (ii) la compatibilité arrière. La valeur d’ETH réside dans le fait qu’il s’agit d’une plateforme sur laquelle vous pouvez déployer des applications et avoir la certitude qu’elles fonctionneront encore des années plus tard. En même temps, cet idéal pourrait aller trop loin, pour reprendre les mots de William Jennings Bryan, “clouer l’ETH à la croix de la compatibilité arrière”. Si seulement deux applications dans l’ensemble d’ETH utilisent une fonctionnalité donnée, et qu’une application n’a jamais eu d’utilisateur pendant des années, tandis que l’autre a à peine été utilisée et a une valeur totale de 57 dollars, nous devrions supprimer cette fonctionnalité et indemniser les victimes de 57 dollars si nécessaire.

Un problème plus large dans la société est de créer un canal standardisé pour effectuer des modifications de compatibilité arrière non urgentes. Une façon de résoudre ce problème est d’examiner et d’étendre les précédents existants, tels que le processus d’auto-destruction. Le pipeline ressemble à ceci :

1. Commencer à parler de la fonction de suppression X;

2. L’analyse pour déterminer les effets de la suppression de X sur l’application dépendra des résultats : (i) abandonner l’idée, (ii) continuer selon le plan, ou (iii) déterminer la méthode modifiée de suppression de X avec le moindre impact et continuer.

3. É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é.

4. 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 à quel stade. À ce stade, il est nécessaire de trouver un équilibre entre la vivacité et la rapidité du processus de suppression des fonctionnalités et la prudence ainsi que l’investissement de plus de ressources dans d’autres domaines du développement du protocole, mais nous sommes encore loin de la frontière de Pareto.

EOF

Un ensemble de principaux changements proposés pour l’EVM est le format d’objet EVM (EOF). EOF introduit de nombreux changements, tels que l’interdiction de l’observabilité des gas, l’observabilité du code (c’est-à-dire pas de CODECOPY), et autorise uniquement les sauts statiques. L’objectif est de permettre à l’EVM de faire plus de mises à niveau de manière plus robuste, tout en maintenant la compatibilité ascendante (car l’EVM avant EOF existe toujours).

L’avantage de cette approche est 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 ne trouvions un moyen de déprécier et de supprimer l’ancienne EVM. Un problème clé est: quel rôle joue 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 nombreux autres conseils d’« amélioration » dans le reste de la feuille de route sont également des occasions de simplifier les anciennes fonctionnalités. Reprenons quelques exemples ci-dessus :

· En passant à la finalité à un seul slot, nous avons la possibilité d’annuler les comités, de repenser l’économie et de simplifier d’autres aspects liés à la Preuve d’enjeu.

· 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 existantes et de la déplacer vers le « code EVM de compte par défaut » qui peut être remplacé par tous les EOA.

· Si nous transférons l’état d’Ethereum vers un arbre de hashage binaire, cela peut être cohérent avec la nouvelle version de SSZ, de telle sorte que toutes les structures de données d’Ethereum puissent être hashées de la même manière.

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

Une stratégie de simplification plus radicale pour Ethereum est de maintenir le protocole inchangé, mais de déplacer la majeure partie de ses fonctionnalités vers le code du contrat.

La version la plus extrême serait de faire en sorte que la L1 d’ETH ne soit “techniquement” que la beacon chain, et d’introduire une machine virtuelle minimale (comme RISC-V, Cairo ou une spécialement 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 au résultat de la proposition d’exécution de l’environnement de 2019-20, même si les SNARK le rendent en pratique 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 procéder à un échange en place de l’EVM. Nous pouvons choisir RISC-V, Cairo ou une autre VM comme nouvelle “VM officielle d’ETH”, puis convertir de force tous les contrats EVM en code de la nouvelle VM qui interprète la logique du code source (par compilation ou interprétation). En théorie, cela pourrait même être réalisé en utilisant une version de « Machine virtuelle cible » comme EOF.

lien vers l’article original