Un grand merci à Fede, Danno Ferrin, Justin Drake, Ladislaus et Tim Beiko pour leurs retours et leurs avis.

L'objectif d'Ethereum est de devenir un grand registre mondial - une plateforme qui transporte des actifs et des enregistrements humains, et qui est la couche sous-jacente pour des applications telles que la finance, la gouvernance et la vérification de données de grande valeur. Pour atteindre cet objectif, il doit à la fois avoir une scalabilité et une résilience. Le plan de hard fork Fusaka augmentera l'espace de disponibilité des données L2 de 10 fois, tandis queLa feuille de route proposée pour 2026Comprend également une échelle similaire d'expansion des données L1. Pendant ce temps, 'The Merge' a mis à niveau Ethereum vers un mécanisme de consensus de preuve d'enjeu (PoS)La diversité des clients augmente rapidement, La vérifiabilité des preuves de connaissance nulle (ZK) et la résistance aux attaques quantiques progressent également de manière constante, et l'écosystème d'application est de plus en plusMature et robuste.

L'objectif de cet article est de mettre en avant un aspect tout aussi critique mais souvent sous-estiméRésilience (et finalement évolutivité)Éléments :
Simplicité du protocole.

L'un des aspects les plus appréciés de Bitcoin est sa conception de protocole, qui est extrêmement élégante et simple :

Le système est une blockchain, composée d'une série de blocs. Chaque bloc est lié au précédent par le biais d'un hachage. La validité de chaque bloc est vérifiée grâce à la Preuve de Travail (PoW), ce qui signifie... il suffit de vérifier si les chiffres de tête de son hachage sont des zéros. Chaque bloc contient des transactions, qui dépensent soit les pièces obtenues par le minage, soit les pièces issues des transactions précédentes. C'est à peu près ça.
Même un lycéen intelligent a la capacité de comprendre pleinement les principes de fonctionnement du protocole Bitcoin. Et un programmeur peut même développer un client Bitcoin en tant que projet de loisir.

Le maintien du protocole simple apporte une série d'avantages clés, rendant potentiellement Bitcoin et EthereumNeutralité de confianceLa couche fondamentale de confiance mondiale:

• Rendre la logique du protocole plus facile à comprendre, élargir le groupe pouvant participer à la recherche, au développement et à la gouvernance du protocole, abaisser les barrières techniques, et éviter la domination d'une 'classe bureaucratique technologique' dans le protocole.
• Réduisez considérablement le coût de développement des nouvelles infrastructures intégrées aux protocoles (comme de nouveaux clients, de nouveaux vérificateurs, de nouveaux outils de journalisation, etc.).
• Réduisez le coût de maintenance à long terme du protocole.
• Réduire le risque de vulnérabilités catastrophiques, que ce soit dans les spécifications de protocole ou dans le code d'implémentation ; cela rend également plus facile de vérifier que le protocole ne contient pas de telles vulnérabilités.
• Réduisez la surface d'attaque sociale : moins il y a de composants, moins d'endroits peuvent être exploités et contrôlés par des parties prenantes spécifiques.

Dans le passé, Ethereum n'a pas bien performé à cet égard (parfois même à cause de mes décisions personnelles), ce qui a entraîné des dépenses de développement excessives, @vbuterin/selfdestruct”>Divers risques de sécurité et la nature fermée de la culture R&D, et ces efforts n'apportent souvent que des retours illusoires.
Cet article expliquera comment Ethereum pourrait atteindre un niveau de simplicité proche de celui de Bitcoin en cinq ans.

Couche de consensus simplifiée

Schéma de simulation de finalité à 3 fentes —3sf-mini

Le nouveau design de la couche de consensus (anciennement connu sous le nom de 'chaîne de faisceau') vise à intégrer l'expérience que nous avons accumulée en théorie du consensus, développement de ZK-SNARK, économie de l'enjeu et d'autres domaines au cours de la dernière décennie, pour créer une couche de consensus Ethereum optimale à long terme. Il est prévu que cette nouvelle couche de consensus, par rapport à l'actuelle Beacon Chain, parvienne à une plus grande simplicité. Cela est particulièrement évident dans :

• restructuration de finalité à 3 emplacements
  Ce design élimine la distinction entre ‘slot’ et ‘epoch’, le brassage des comités, et d'autres détails de spécification de protocole liés à ces mécanismes (comme les comités synchrones). Une version de base de la finalité en 3 slots,Seulement environ 200 lignes de code sont nécessairesCela peut être réalisé. Comparé au protocole Gasper actuel, la finalité en 3 slots offre également une sécurité proche de l'optimal.
• Le nombre de validateurs actifs a diminué
  Rend plus sûr et plus réalisable d'adopter une règle de choix de fork plus simple.
• Protocole d'agrégation basé sur STARK
  Signifie que n'importe qui peut devenir un agrégateur sans se soucier de faire confiance à l'agrégateur, de frais excessifs pour des champs de bits répétés, etc. Bien que le chiffrement de l'agrégation soit en soi assez complexe, celaComplexité hautement encapsuléeLe risque systématique global du protocole est beaucoup plus faible.
• Les deux points ci-dessus sont également susceptibles de soutenir une architecture pair à pair (p2p) plus simple et robuste.
• Nous avons l'opportunité de repenser les mécanismes d'entrée des validateurs, de sortie, de retrait, de changement de clé, de pénalité d'inertie, etc., et de les simplifier - non seulement en réduisant le nombre de lignes de code (LoC), mais aussi en fournissant des garanties mécaniques plus claires, telles qu'une date limite de 'subjectivité faible' plus explicite.

L'avantage de la couche de consensus est qu'elle est relativement découplée de l'exécution de l'EVM, nous avons donc beaucoup de marge pour continuer à pousser ces améliorations vers l'avant.
Plus difficile est : comment parvenir à la même simplification au niveau de l'exécution.

Simplifier la couche d'exécution

La complexité de l'Ethereum Virtual Machine (EVM) ne cesse d'augmenter, et une grande partie de cette complexité s'est avérée inutile (souvent liée à mes propres décisions) : nous disposons d'une machine virtuelle de 256 bits qui est trop optimisée pour des formes cryptographiques très spécifiques, qui sont maintenant progressivement marginalisées ; et certains contrats précompilés se concentrent trop sur très peu de cas d'utilisation.

Tenter de résoudre progressivement ces problèmes pratiques n'est pas réalisable.Supprimer @vbuterinL'instruction SELFDESTRUCT consomme une énorme quantité d'énergie, mais les résultats sont limités. Le récent débat sur EOF (EVM Object Format) démontre encore davantage la difficulté de faire des changements similaires à la machine virtuelle.

Par conséquent, en guise d'alternative, j'ai récemment proposé une idée plus radicale : au lieu de faire des changements incrémentiels (mais toujours destructeurs) pour une amélioration de 1,5x, il est préférable de migrer directement vers une toute nouvelle machine virtuelle, bien supérieure et plus simple, visant un retour de 100x. Tout comme 'The Merge', nous réduisons le nombre de transformations, mais chacune est significative. Plus précisément, je suggère de remplacer l'EVM existant par RISC-V (ou une autre machine virtuelle qui sera utilisée par le prouveur ZK d'Ethereum). De cette manière, nous atteindrons :

• Amélioration significative de l'efficacité : parce que les contrats intelligents peuvent s'exécuter directement dans le prouveur sans les frais généraux d'un interprète. Des données succinctes indiquent que les performances peuvent être améliorées de plus de 100 fois dans de nombreux scénarios.
• Simplicité ultime : comparé à la spécification EVM, RISC-VExtrêmement simple. D'autres solutions alternatives (comme Le Caire) sont tout aussi concises.
• Héritant des avantages attendus d'EOF : tels que la segmentation du code, une analyse statique plus conviviale, une limite de capacité de code plus importante, etc.
• Les développeurs ont plus de choix : Solidity et Vyper peuvent être compilés vers le nouveau backend de la machine virtuelle. Si RISC-V est choisi, les développeurs de langages grand public peuvent également facilement porter leur code.
• Réduire considérablement le besoin de précompilation : en conservant éventuellement uniquement quelques opérations sur les courbes elliptiques hautement optimisées (bien qu'elles n'existeront plus une fois que l'informatique quantique sera populaire).

Le principal inconvénient de cette approche est que, contrairement à EOF (déployable immédiatement), la nouvelle machine virtuelle prend plus de temps à bénéficier aux développeurs. Pour atténuer cela, nous pouvons introduire quelques améliorations EVM petites mais de grande valeur à court terme.Augmenter la limite de taille du code du contrat、Augmenter les instructions DUP/SWAP17-32, etc.)

En fin de compte, cela nous donnera une machine virtuelle grandement simplifiée. Mais la plus grande question est : que faire de l'EVM existante ?

Stratégie de compatibilité ascendante transitoire de la VM

Lorsqu'il s'agit de simplifier de manière significative (ou même d'améliorer sans ajouter de complexité) une partie quelconque de la Machine Virtuelle Ethereum (EVM), le plus grand défi est de savoir comment maintenir la compatibilité ascendante avec les applications existantes tout en atteignant l'objectif.

Tout d'abord, il convient de préciser qu'il n'y a pas de manière unique de définir la portée de la base de code d'Ethereum (même au sein du même client).

L'objectif est de minimiser autant que possible le champ d'application de la zone verte : c'est-à-dire la logique que les nœuds doivent exécuter pour participer au consensus d'Ethereum, y compris le calcul de l'état actuel, la preuve, la validation, le FOCIL (couche d'intégrité du consensus de premier ordre), la construction de blocs de base, etc.

La zone orange ne peut pas être réduite : si une certaine fonctionnalité de la couche d'exécution (qu'il s'agisse d'une machine virtuelle, d'une précompilation ou d'un autre mécanisme) est supprimée de la spécification du protocole, ou si sa fonctionnalité est modifiée, le client concerné par le traitement des blocs historiques doit toujours la conserver - mais de manière importante, les nouveaux clients (comme les ZK-EVMs ou les vérificateurs formels) peuvent totalement ignorer la zone orange.

La nouvelle catégorie est la zone jaune : ce type de code est très important pour comprendre et analyser l'état actuel de la chaîne, et pour construire les meilleurs blocs, mais il ne fait pas partie du consensus. Un exemple est Etherscan(Et quelquesConstructeur de blocs) Prise en charge des opérations utilisateur ERC-4337. Si nous utilisons une implémentation RISC-V on-chain pour remplacer certaines fonctions importantes d'Ethereum (comme les comptes EOA et leur prise en charge de divers anciens types de transactions), alors malgré la simplification significative du code de consensus, certains nœuds professionnels peuvent encore continuer à utiliser le code original pour analyser ces fonctions.

Il est important que les zones orange et jaune appartiennent à “Gate”Complexité de l'encapsulationToute personne qui souhaite comprendre le protocole peut les ignorer, les clients Ethereum peuvent également choisir de ne pas les implémenter, et les bugs dans ces domaines ne présenteront pas de risque de consensus. Cela signifie que la complexité du code et l'impact négatif causés par les zones orange et jaune sont bien moindres que ceux de la zone verte.

Transférez le code de la zone verte à la zone jaune, cette approche est similaire à Apple Inc.Traduisez via la couche de traduction RosettaPour assurer une compatibilité à long terme.

J'ai proposé (emprunté à@ipsilon/eof-ethereums-gateway-to-risc-v”> Les récents points de vue de l'équipe Ipsilon) Le processus de migration de machine virtuelle suivant (en utilisant la migration de l'EVM vers RISC-V comme exemple, mais également applicable à la migration de l'EVM vers Cairo, voire à une future migration vers une machine virtuelle plus optimale):

1. Tous les nouveaux précompilés doivent être écrits dans une implémentation RISC-V standard on-chain, afin que l'écosystème puisse commencer à se familiariser et à utiliser RISC-V en tant que machine virtuelle.
2. Présentation de RISC-V comme option pour le développement de contrats en parallèle d'EVM pour les développeurs. Le protocole prend en charge nativement à la fois RISC-V et EVM, permettant aux contrats écrits dans les deux langues d'interagir librement.
3. Remplacez tous les précompilations (sauf les opérations de courbe elliptique et KECCAK) par une implémentation RISC-V. Nous supprimons ces précompilations par le biais d'une fourchette dure et en même temps changeons le code à l'adresse correspondante (style fourche DAO) pour être une implémentation RISC-V. Comme la machine virtuelle RISC-V est extrêmement concise, même le simple fait de le faire simplifie la structure globale.
4. Implémenter un interpréteur EVM écrit en RISC-V et le déployer en tant que contrat intelligent sur la chaîne. Après plusieurs années de publication initiale, les contrats EVM existants seront traités par cet interpréteur.

Après avoir terminé l'étape 4, de nombreuses 'implémentations EVM' continueront à être utilisées pour optimiser la construction de blocs, les outils de développement et l'analyse on-chain, mais elles ne feront plus partie des spécifications clés du consensus. À ce moment-là, le consensus d'Ethereum ne comprendra 'nativement' que RISC-V.

Simplifiez en partageant les composants du protocole

La troisième méthode de simplification, peut-être la plus sous-estimée, consiste à partager autant que possible une norme unifiée à travers différentes parties de la pile de protocoles. En général, il n'y a aucune raison d'utiliser différents protocoles pour un même objectif dans différents scénarios, mais cette situation se produit fréquemment en réalité, principalement en raison d'un manque de communication entre différentes parties de la feuille de route du protocole. Voici quelques exemples spécifiques de simplification d'Ethereum grâce à la « maximisation du partage des composants » :

Un code d'effacement unifié

Nous devons corriger le code de suppression dans trois scénarios :

• Échantillonnage de disponibilité des données - Le client vérifie si le bloc a été publié
• Diffusion P2P plus rapide - Les nœuds peuvent accepter des blocs après avoir reçu n/2 sur n blocs, établissant ainsi un équilibre optimal entre la réduction de la latence et la redondance.
• Stockage d'historique distribué - Chaque morceau d'historique d'Ethereum est stocké dans de nombreux blocs, de sorte que (i) ces blocs peuvent être vérifiés de manière indépendante et (ii) la moitié des blocs de chaque groupe peut récupérer l'autre moitié, réduisant ainsi considérablement le risque de perte d'un seul bloc.

Si nous utilisons le même code d'effacement (qu'il s'agisse de Reed-Solomon, de code linéaire aléatoire ou autre) dans trois cas d'utilisation, nous obtiendrons certains avantages importants:

1. Minimiser le nombre total de lignes de code
2. Améliorer l'efficacité car si chaque nœud doit télécharger diverses parties d'un bloc pour un cas d'utilisation (au lieu de l'intégralité du bloc), les données peuvent être utilisées pour un autre cas d'utilisation
3. Assurer la vérifiabilité : Les trois blocs dans le contexte peuvent être vérifiés en fonction de la racine

Si différents codes de correction d'erreurs sont effectivement nécessaires, la 'compatibilité' devrait être assurée au moins : par exemple, dans le scénario DAS, Reed-Solomon est utilisé horizontalement et le code linéaire aléatoire est utilisé verticalement, mais tous deux sont basés sur le même champ mathématique.

Un format de sérialisation unifié

Actuellement, le format de sérialisation d'Ethereum est stricto sensu seulement "semi-standardisé", car les données peuvent être resérialisées et diffusées dans n'importe quel format. La seule exception est le hachage de signature de transaction, où un format standardisé est requis pour le calcul du hachage.
Mais la normalisation des formats de sérialisation futurs sera encore améliorée, pour deux raisons :

• Abstraction de compte complète (EIP-7701) : La machine virtuelle pourra voir le contenu complet de la transaction
• Augmentation de la limite de gaz : Exécuter les données de bloc nécessite d'être empaquetées dans un blob

À ce moment-là, nous avons l'opportunité de unifier les solutions de sérialisation requises pour les trois aspects actuels : 1) couche d'exécution ; 2) couche de consensus ; 3) ABI d'invocation de contrat intelligent.

Je suggère d'adopter SSZ(Simple Serialize), car SSZ présente les avantages suivants :

• Facile à décoder : y compris à l'intérieur des contrats intelligents (basé sur une conception en 4 octets, quelques cas limites)
• Largement utilisé dans le consensus
• Très similaire à l'ABI existant : faible coût de migration de l'ensemble d'outils

Actuellement, plus de composants ont étéMigrationÀ SSZTravailLors de la planification des futures mises à niveau, nous devrions prendre en compte et utiliser pleinement ces développements.

Une structure arborescente unifiée

Une fois que nous passons de l'EVM à RISC-V (ou à un autre VM minimaliste), l'arbre de Merkle Patricia hexadécimal deviendra le plus grand goulot d'étranglement pour prouver l'exécution de bloc, même dans des scénarios moyens. Passer à une fonction de hachageArbre binaire, cela améliorera considérablement l'efficacité du vérificateur et réduira le coût des données des nœuds légers et d'autres scénarios.

Lors de la migration de la structure arborescente, nous devons également nous assurer que la couche de consensus utilise la même structure arborescente pour garantir que l'ensemble d'Ethereum - à la fois les couches de consensus et d'exécution - peut être accédé et analysé à l'aide du même ensemble de code.

De maintenant à l'avenir

La simplification et la décentralisation ont de nombreuses similitudes. Toutes deux sont des exigences en amont nécessaires pour atteindre l'objectif supérieur de la résilience du système. Mettre explicitement l'accent sur la simplification nécessite un changement culturel. Les avantages de la simplification sont souvent difficiles à percevoir aux premiers stades, mais les coûts d'opportunité et la charge de travail supplémentaire liés au rejet de ces "nouvelles fonctionnalités séduisantes" sont immédiatement évidents. Cependant, avec le temps, la valeur à long terme de la simplification devient de plus en plus évidente - le Bitcoin lui-même en est un excellent exemple.

Je suggère que nousApprenez de l'approche de tinygradPour fixer un objectif clair de limite de lignes de code pour la spécification à long terme d'Ethereum, l'objectif est de rendre le code critique du consensus d'Ethereum aussi proche que possible du style minimaliste de Bitcoin. Le code traitant des règles historiques d'Ethereum existera toujours mais devrait être isolé du chemin critique du consensus. En même temps, nous devrions former un principe de conception universel : choisir des solutions plus simples chaque fois que possible, privilégier la complexité encapsulée sur la complexité systémique, et pencher vers des décisions de conception qui offrent des propriétés et des garanties claires et vérifiables.

Avertissement :

1. Cet article est repris de [vitalik]. Tous les droits d'auteur appartiennent à l'auteur original [vitalikTout. Si vous avez des objections à cette réimpression, veuillez contacterGate LearnL'équipe s'en occupera en temps opportun.
2. Avertissement : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas des conseils en investissement.
3. L'équipe de Gate Learn traduit des articles dans d'autres langues. Copier, distribuer ou plagier des articles traduits est interdit sauf indication contraire.