Ethereum vise à devenir le grand livre du monde : une plateforme pour stocker les actifs de la civilisation et enregistrer les informations, constituant la couche de base pour la finance, la gouvernance, la certification de données de grande valeur, etc. Cela nécessite deux conditions : évolutivité et résilience. Le hard fork Fusaka vise à multiplier par dix l'espace disponible pour les données de la couche 2 (L2), et la feuille de route proposée pour 2026 prévoit également une expansion similaire pour la couche 1 (L1). Dans le même temps, Ethereum a terminé sa mise à niveau vers le mécanisme de preuve d'enjeu (Proof of Stake), la diversité de ses clients a rapidement augmenté, les travaux sur la vérifiabilité par preuves nulles (ZK Verifiability) et la résistance à la computation quantique avancent également, et les différentes applications deviennent de plus en plus robustes.
Cet article vise à se concentrer sur un aspect de la résilience (qui affectera finalement l'évolutivité), un aspect tout aussi important mais souvent sous-estimé, à savoir la simplicité du protocole.
Un des grands avantages du Bitcoin est la simplicité et l'élégance de son protocole.
La blockchain est constituée d'une série de blocs, chaque bloc étant relié au bloc précédent par une valeur de hachage. La validité d'un bloc est vérifiée par un mécanisme de preuve de travail, qui valide si les premiers chiffres de sa valeur de hachage sont nuls. Chaque bloc contient plusieurs transactions, et les devises utilisées dans ces transactions proviennent soit du minage, soit des sorties de transactions antérieures. Le mécanisme central du protocole Bitcoin repose sur cela. Même un élève de lycée intelligent peut comprendre ce protocole, et un programmeur peut même le coder comme projet amateur.
La simplicité des protocoles offre un avantage clé pour que Bitcoin ou Ethereum deviennent des couches de base neutres reconnues mondialement :
Des protocoles simples sont plus faciles à analyser, ce qui peut attirer davantage de participants à s'engager dans la recherche, le développement et la gouvernance des protocoles, tout en réduisant les risques de monopole technologique.
La simplification de la structure des protocoles réduit considérablement les efforts de développement nécessaires pour l'intégration avec les nouvelles infrastructures (telles que les clients, les prouveurs, les outils de journalisation et autres outils de développement).
La conception concise du protocole réduit efficacement les coûts de maintenance à long terme.
Les risques de vulnérabilités graves dans la spécification des protocoles et leur mise en œuvre sont considérablement réduits, ce qui facilite la vérification de la sécurité du système.
Réduire la surface d'attaque sociale : la réduction des composants rend le système plus facile à protéger contre l'infiltration d'intérêts particuliers, améliorant ainsi la sécurité globale.
Historiquement, Ethereum a souvent échoué à appliquer le principe de simplicité dans la conception de son protocole (en partie à cause de mes décisions), ce qui a directement entraîné des coûts de développement élevés, des risques de sécurité fréquents et une culture de développement fermée. La racine de ces problèmes réside souvent dans la quête de bénéfices à court terme qui se sont révélés inefficaces en pratique. Cet article expliquera comment Ethereum pourra atteindre une simplicité de protocole proche de celle de Bitcoin au cours des cinq prochaines années.
Couche de consensus simplifiée
Simuler la finalité des trois créneaux dans 3sf - mini (nom de code du réseau de test Ethereum)
Le nouveau plan de couche de consensus (anciennement nommé « chaîne de faisceau ») vise à intégrer les résultats de recherche des dix dernières années dans des domaines tels que la théorie du consensus, les preuves à divulgation nulle de connaissance (ZK-SNARK) et l'économie de la mise, afin de construire un mécanisme de consensus optimal pour Ethereum axé sur le développement à long terme. Par rapport à la chaîne de balises existante, ce plan présente des caractéristiques nettement simplifiées, comme illustré dans les aspects suivants :
Innovation de l'architecture de finalité à trois intervalles (3-slot finality) : élimination de la séparation conceptuelle entre les intervalles (slot) et les époques (epoch), suppression du mécanisme de rotation du comité et des composants complexes tels que le comité de synchronisation, simplifiant considérablement les spécifications du protocole. L'implémentation centrale nécessite seulement environ 200 lignes de code, atteignant un niveau de sécurité presque optimal par rapport au protocole Gasper.
Optimisation de la gestion des nœuds de validation : en limitant le nombre de nœuds de validation actifs, les règles de sélection de fork peuvent être mises en œuvre de manière plus simplifiée, tout en garantissant la sécurité du système.
Mise à niveau du protocole d'agrégation : le mécanisme d'agrégation basé sur STARK permet à n'importe quel nœud d'assumer le rôle d'agrégateur, évitant ainsi la dépendance à la confiance envers l'agrégateur et le problème du gaspillage de ressources lié aux champs de bits (bitfield) répétitifs. Bien que la cryptographie d'agrégation elle-même soit relativement complexe, ses caractéristiques de haute encapsulation réduisent considérablement le risque systémique.
Amélioration de l'architecture réseau P2P : Les deux optimisations mentionnées ci-dessus offrent la possibilité de construire une architecture réseau P2P plus simple et plus efficace.
Refonte du processus de validation : redéfinir les mécanismes d'admission, de sortie, de retrait, de migration de clés et de pénalités pour inactivité des nœuds de validation, tout en réduisant la quantité de code, et en clarifiant les mécanismes de garantie des paramètres clés (comme le cycle subjectif faible).
Avantages technologiques : la caractéristique de découplage relatif entre la couche de consensus et la couche d'exécution EVM offre un plus grand espace technique pour une optimisation continue. En revanche, les améliorations similaires de la couche d'exécution font face à des défis plus importants.
Niveau d'exécution simplifié
La complexité de la machine virtuelle Ethereum (EVM) continue de croître, avec de nombreux designs complexes qui se sont révélés inutiles (dans de nombreux cas, en raison de mes erreurs de jugement) : une machine virtuelle de 256 bits sur-optimisée pour des algorithmes cryptographiques spécifiques, alors que ces algorithmes ont progressivement perdu de leur importance ; ainsi que des contrats précompilés sur-conçus pour un seul cas d'utilisation, dont le taux d'utilisation réel est très faible.
Essayer de résoudre les problèmes existants par des réparations ponctuelles n'est plus faisable. Supprimer l'opcode SELFDESTRUCT nécessite un effort énorme mais ne rapporte que des bénéfices limités, et les récentes discussions sur l'EOF mettent encore plus en évidence les difficultés de modifications progressives de la machine virtuelle.
En tant qu'alternative, j'ai récemment proposé une voie de transformation plus radicale : plutôt que d'apporter des modifications de taille moyenne (mais toujours destructrices) à l'EVM en échange d'une amélioration de performance de 1,5 fois, il serait préférable de passer directement à une toute nouvelle architecture de machine virtuelle qui soit nettement meilleure, afin d'atteindre une augmentation de performance par un facteur de cent. Tout comme la fusion (The Merge), nous réduisons le nombre de changements destructeurs, tout en augmentant la valeur stratégique de chaque changement. Plus précisément, il est proposé d'adopter l'architecture RISC-V ou la machine virtuelle utilisée par les programmes de preuve ZK d'Ethereum en remplacement de l'EVM actuel. Cette transformation apportera :
Amélioration révolutionnaire de l'efficacité : dans un environnement de preuve ZK, les contrats intelligents peuvent s'exécuter directement sur l'architecture cible, sans les frais d'un interpréteur. Les données succinctes montrent qu'une amélioration des performances de plus de cent fois est possible dans la plupart des scénarios.
Architecture simplifiée à l'extrême : la spécification RISC-V est beaucoup plus concise par rapport à l'EVM, d'autres solutions candidates (comme Cairo) possèdent également des caractéristiques de simplicité.
Les principaux avantages d'Eof : gestion par segments de code, support d'analyse statique plus convivial et limites de capacité de code plus importantes.
Extension de la chaîne d'outils pour les développeurs : Solidity et Vyper peuvent prendre en charge de nouvelles architectures grâce à un support de compilation backend ajouté ; si RISC-V est choisi, les développeurs de langages mainstream peuvent directement porter le code existant.
Optimisation des contrats précompilés : la plupart des fonctions précompilées ne seront plus nécessaires, seules les calculs de courbes elliptiques hautement optimisées seront conservés (elles pourraient être éliminées avec le développement de l'informatique quantique).
Les principaux défis sont les suivants : contrairement aux solutions EOF pouvant être mises en œuvre immédiatement, la nouvelle machine virtuelle prendra plus de temps pour bénéficier aux développeurs. Il est possible de synchroniser la mise en œuvre de certaines améliorations EVM de grande valeur (comme l'augmentation des limites de taille de code des contrats, l'optimisation de l'ensemble d'instructions DUP/SWAP) comme solution de transition à court terme.
Cette transformation simplifiera considérablement l'architecture de la machine virtuelle. La question principale est : comment gérer correctement l'écosystème EVM existant ?
Stratégie de rétrocompatibilité pour la migration de machines virtuelles
Le plus grand défi pour simplifier (ou optimiser sans augmenter la complexité) n'importe quelle partie de l'EVM est de trouver un équilibre entre la réalisation des objectifs attendus et le maintien de la compatibilité descendante des applications existantes.
Il est d'abord nécessaire de clarifier que, même pour un seul client, il n'existe pas de norme unique pour définir ce qu'est le « code source Ethereum ».
L'objectif est de minimiser la zone verte : c'est-à-dire que les nœuds doivent exécuter la logique nécessaire à la participation au consensus Ethereum, y compris le calcul de l'état actuel, la génération et la vérification des preuves, FOCIL (Note : confirmer s'il s'agit d'un acronyme technique) ainsi que le processus de construction de blocs "de base".
La zone orange ne peut pas être réduite : si les fonctionnalités de la couche d'exécution (qu'il s'agisse d'une machine virtuelle, de contrats précompilés ou d'autres mécanismes) sont supprimées des spécifications du protocole ou si leurs fonctionnalités changent, le client devant traiter les blocs historiques doit conserver cette fonctionnalité ; mais le nouveau client (y compris ZK-EVM ou les outils de vérification formelle) peut totalement ignorer cette partie.
Nouvelle zone jaune : fait référence à des codes qui ont une grande valeur pour l'analyse des données actuelles sur la chaîne ou la construction de blocs optimaux, mais qui ne font pas partie du mécanisme de consensus. Des exemples typiques incluent le soutien d'Etherscan et de certains constructeurs de blocs pour les opérations des utilisateurs ERC-4337. Si les fonctionnalités de base d'Ethereum (comme les comptes externes EOA et les divers types de transactions anciennes qu'ils supportent) sont remplacées par une implémentation RISC-V sur la chaîne, le code de consensus sera considérablement simplifié, mais les nœuds spécialisés peuvent encore avoir besoin d'utiliser le code d'origine pour le traitement des analyses.
La complexité des zones orange et jaune appartient à la complexité d'encapsulation, et toute personne souhaitant comprendre le protocole peut sauter ces sections. De plus, les implémentations Ethereum peuvent librement choisir d'ignorer ces parties. En outre, les défauts de code dans ces zones ne déclencheront pas de risque de consensus. Cela signifie qu'en comparaison avec la complexité du code de la zone verte, la complexité des zones orange et jaune a un impact négatif significativement moindre sur l'ensemble du système.
L'idée de migrer le code de la zone verte vers la zone jaune est similaire à la solution technique à long terme de compatibilité arrière qu'Apple a réalisée grâce à la couche de traduction Rosetta.
Il est exigé que tous les nouveaux contrats précompilés développés comprennent une mise en œuvre RISC-V conforme sur la chaîne. Cette étape vise à inciter l'écosystème à s'adapter progressivement à l'environnement de machine virtuelle RISC-V (à titre d'exemple de la migration de l'EVM vers RISC-V, cette solution s'applique également à la migration de l'EVM vers Cairo ou d'autres machines virtuelles plus performantes) :
Support parallèle de deux machines virtuelles : au niveau du protocole, prise en charge native simultanée des deux machines virtuelles RISC-V et EVM. Les développeurs peuvent choisir librement leur langage de développement, et les contrats écrits sur différentes machines virtuelles peuvent interagir sans couture.
Remplacement par phases des contrats précompilés : à l'exception des calculs de courbes elliptiques et de l'algorithme de hachage KECCAK (en raison de leurs exigences de performance extrêmement optimisées), tous les contrats précompilés sont remplacés par une implémentation RISC-V par hard fork.
L'opération spécifique consiste à supprimer le contrat précompilé d'origine tout en modifiant le code à cette adresse (en utilisant le mode de fork DAO) de l'état vide à la mise en œuvre correspondante de RISC-V. En raison de la grande simplicité de l'architecture RISC-V, même si cette étape est seulement complétée, la complexité globale du système sera toujours réduite.
Déploiement de l'interpréteur EVM sur la chaîne : mise en œuvre de l'interpréteur EVM basé sur RISC-V (la chaîne d'outils de preuve ZK a favorisé ce type de développement) et déploiement de celui-ci en tant que contrat intelligent sur la chaîne. Des années après la publication de la version initiale, les contrats EVM existants seront exécutés via cet interpréteur, permettant ainsi une transition en douceur vers la nouvelle machine virtuelle.
Simplification via le composant de protocole de partage
Une fois l'étape quatre terminée, de nombreuses « solutions d'implémentation EVM » resteront disponibles et seront utilisées pour optimiser la construction de blocs, les outils pour développeurs et l'analyse de données on-chain, mais ces implémentations ne feront plus partie des composants du protocole de consensus central. À ce moment-là, le mécanisme de consensus Ethereum supportera « nativement » uniquement l'architecture RISC-V.
Simplification par le biais de composants de protocole de partage
La troisième méthode pour réduire la complexité globale des protocoles (et la plus souvent sous-estimée) consiste à partager des normes unifiées autant que possible entre les différents niveaux de la pile de protocoles. En général, il est à la fois inutile et non rentable d'utiliser des protocoles différents dans différents modules pour réaliser la même fonctionnalité, mais ce type de modèle de conception existe néanmoins de manière répandue, principalement en raison d'un manque de synergie efficace entre les différentes parties de la feuille de route des protocoles. Voici des exemples de scénarios dans lesquels le renforcement de la réutilisation des composants à travers les couches peut simplifier Ethereum.
Solution de code de suppression et de partage unifié
Trois types de scénarios d'application des codes de correction d'effacement :
Échantillonnage de la disponibilité des données : le client doit utiliser le code de correction d'erreur lors de la vérification si le bloc a été publié, afin d'assurer l'intégrité des données.
Diffusion P2P efficace : les nœuds peuvent confirmer le bloc dès qu'ils reçoivent n/2 des n fragments, réalisant ainsi un équilibre optimal entre la réduction des délais et le degré de redondance.
Stockage historique distribué : les données historiques d'Ethereum sont divisées en plusieurs blocs de données, répondant à :
Chaque bloc de données peut être vérifié indépendamment.
Il suffit de n/2 blocs de données dans n'importe quel groupe pour récupérer les n/2 blocs de données restants.
Ce design réduit considérablement le risque de perte de données en un seul point.
L'utilisation du même code de correction d'erreurs (comme le code de Reed-Solomon, le code linéaire aléatoire, etc.) dans les trois scénarios suivants présentera des avantages significatifs :
Code simplifié;
Amélioration de l'efficacité : lorsque les nœuds doivent télécharger des données de fragment en raison d'un scénario (plutôt que d'un bloc complet), ces données peuvent être directement utilisées pour d'autres scénarios, évitant ainsi les transmissions redondantes ;
Tous les blocs de données de tous les scénarios peuvent être vérifiés de manière uniforme via le hash racine.
Si des codes de correction différents sont utilisés, il est nécessaire de satisfaire aux exigences de compatibilité : par exemple, dans l'échantillonnage de disponibilité des données (DAS) en morceaux, il est possible d'utiliser simultanément des codes de Reed-Solomon horizontaux et des codes linéaires aléatoires verticaux, mais les deux types de codage doivent être calculés sur le même corps fini.
Format de sérialisation unifié
Le format de sérialisation actuel d'Ethereum est encore à moitié normalisé - les données peuvent être re-sérialisées dans n'importe quel format et propagées, la seule exception étant le hachage de la signature de la transaction, qui doit adopter un format normalisé pour garantir la cohérence du hachage. Cependant, à l'avenir, le degré de normalisation du format de sérialisation sera renforcé, principalement pour les raisons suivantes :
Abstraction de compte (EIP-7701) : le contenu complet de la transaction sera entièrement visible pour la machine virtuelle (VM)
Scénario de limite de Gas élevé : Avec l'augmentation de la limite de Gas du bloc, les données de la couche d'exécution doivent être stockées dans une structure blob.
Lorsque cette transformation se produit, nous pouvons saisir cette occasion pour unifier les normes de sérialisation des trois niveaux clés d'Ethereum : (i) couche d'exécution (ii) couche de consensus (iii) appel d'ABI de contrat intelligent.
Il est recommandé d'adopter le format de sérialisation SSZ, qui présente les avantages suivants :
Le décodage est efficace et les scénarios, y compris les contrats intelligents, peuvent être décodés rapidement grâce à sa conception basée sur 4 octets et à un traitement limité des conditions aux limites.
La couche de consensus est largement appliquée et a été profondément intégrée au niveau de la couche de consensus.
Très similaire à l'ABI existant, facilitant la mise à niveau et l'adaptation de la chaîne d'outils.
Des équipes techniques pertinentes travaillent déjà à la migration complète de SSZ. Il est conseillé de poursuivre cette voie technique dans les futures planifications de mise à niveau et d'étendre les résultats existants.
Arbre de structure partagé unifié
Lorsque l'on passe de l'EVM à RISC-V (ou à d'autres architectures de machines virtuelles simplifiées), l'arbre Merkle Patricia à six branches deviendra le principal goulet d'étranglement des preuves d'exécution des blocs (même dans des scénarios normaux). Passer à une structure d'arbre binaire basée sur une fonction de hachage plus optimale améliorera considérablement l'efficacité des preuves et réduira les coûts de stockage des données pour les nœuds légers et d'autres scénarios d'application.
Lors de la mise en œuvre de cette migration, il convient d'adopter simultanément la même structure arborescente pour réaliser l'unification de la couche de consensus et de la couche d'exécution. Cette démarche garantit que l'ensemble de la pile Ethereum (y compris la couche de consensus et la couche d'exécution) utilise la même logique de code pour l'accès et l'analyse des données.
Le chemin d'évolution de l'état actuel à l'objectif
La simplicité présente des similitudes avec la décentralisation à plusieurs égards, les deux étant des prérequis fondamentaux pour réaliser la résilience des systèmes. Il est nécessaire d'opérer un changement culturel pour faire de la simplicité une valeur centrale : ses bénéfices sont souvent difficiles à percevoir immédiatement, tandis que les gains à court terme liés à la recherche de fonctionnalités complexes sont évidents. Cependant, avec le temps, les avantages de la simplicité deviendront de plus en plus significatifs - le parcours de développement de Bitcoin en est une puissante illustration.
Je propose de concevoir le protocole Ethereum en s'appuyant sur l'expérience pratique du projet TinyGrad, afin de définir un objectif clair de limite du nombre de lignes de code pour les normes Ethereum à long terme, cherchant à rendre la simplicité du code critique du consensus Ethereum proche du niveau de Bitcoin. Plus précisément, le code relatif aux règles historiques d'Ethereum peut continuer à être conservé, mais doit être strictement isolé en dehors du chemin critique du consensus, garantissant qu'il n'affecte pas la logique de consensus centrale ; en même temps, le choix des solutions techniques doit appliquer le principe de "préférer des solutions plus simples", en encapsulant la complexité plutôt qu'en diffusant une complexité systémique, et en s'assurant que toutes les décisions de conception offrent des caractéristiques et des garanties claires et vérifiables, formant ainsi globalement une culture technique orientée vers la simplicité.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Nouvel article de Vitalik : comment Ethereum met en œuvre une architecture simplifiée pour rivaliser avec Bitcoin ?
Titre original : Simplifier le L1
Rédigé par : Vitalik
Compilation : lenaxin, ChainCatcher
Ethereum vise à devenir le grand livre du monde : une plateforme pour stocker les actifs de la civilisation et enregistrer les informations, constituant la couche de base pour la finance, la gouvernance, la certification de données de grande valeur, etc. Cela nécessite deux conditions : évolutivité et résilience. Le hard fork Fusaka vise à multiplier par dix l'espace disponible pour les données de la couche 2 (L2), et la feuille de route proposée pour 2026 prévoit également une expansion similaire pour la couche 1 (L1). Dans le même temps, Ethereum a terminé sa mise à niveau vers le mécanisme de preuve d'enjeu (Proof of Stake), la diversité de ses clients a rapidement augmenté, les travaux sur la vérifiabilité par preuves nulles (ZK Verifiability) et la résistance à la computation quantique avancent également, et les différentes applications deviennent de plus en plus robustes.
Cet article vise à se concentrer sur un aspect de la résilience (qui affectera finalement l'évolutivité), un aspect tout aussi important mais souvent sous-estimé, à savoir la simplicité du protocole.
Un des grands avantages du Bitcoin est la simplicité et l'élégance de son protocole.
La blockchain est constituée d'une série de blocs, chaque bloc étant relié au bloc précédent par une valeur de hachage. La validité d'un bloc est vérifiée par un mécanisme de preuve de travail, qui valide si les premiers chiffres de sa valeur de hachage sont nuls. Chaque bloc contient plusieurs transactions, et les devises utilisées dans ces transactions proviennent soit du minage, soit des sorties de transactions antérieures. Le mécanisme central du protocole Bitcoin repose sur cela. Même un élève de lycée intelligent peut comprendre ce protocole, et un programmeur peut même le coder comme projet amateur.
La simplicité des protocoles offre un avantage clé pour que Bitcoin ou Ethereum deviennent des couches de base neutres reconnues mondialement :
Des protocoles simples sont plus faciles à analyser, ce qui peut attirer davantage de participants à s'engager dans la recherche, le développement et la gouvernance des protocoles, tout en réduisant les risques de monopole technologique.
La simplification de la structure des protocoles réduit considérablement les efforts de développement nécessaires pour l'intégration avec les nouvelles infrastructures (telles que les clients, les prouveurs, les outils de journalisation et autres outils de développement).
La conception concise du protocole réduit efficacement les coûts de maintenance à long terme.
Les risques de vulnérabilités graves dans la spécification des protocoles et leur mise en œuvre sont considérablement réduits, ce qui facilite la vérification de la sécurité du système.
Réduire la surface d'attaque sociale : la réduction des composants rend le système plus facile à protéger contre l'infiltration d'intérêts particuliers, améliorant ainsi la sécurité globale.
Historiquement, Ethereum a souvent échoué à appliquer le principe de simplicité dans la conception de son protocole (en partie à cause de mes décisions), ce qui a directement entraîné des coûts de développement élevés, des risques de sécurité fréquents et une culture de développement fermée. La racine de ces problèmes réside souvent dans la quête de bénéfices à court terme qui se sont révélés inefficaces en pratique. Cet article expliquera comment Ethereum pourra atteindre une simplicité de protocole proche de celle de Bitcoin au cours des cinq prochaines années.
Couche de consensus simplifiée
Simuler la finalité des trois créneaux dans 3sf - mini (nom de code du réseau de test Ethereum)
Le nouveau plan de couche de consensus (anciennement nommé « chaîne de faisceau ») vise à intégrer les résultats de recherche des dix dernières années dans des domaines tels que la théorie du consensus, les preuves à divulgation nulle de connaissance (ZK-SNARK) et l'économie de la mise, afin de construire un mécanisme de consensus optimal pour Ethereum axé sur le développement à long terme. Par rapport à la chaîne de balises existante, ce plan présente des caractéristiques nettement simplifiées, comme illustré dans les aspects suivants :
Innovation de l'architecture de finalité à trois intervalles (3-slot finality) : élimination de la séparation conceptuelle entre les intervalles (slot) et les époques (epoch), suppression du mécanisme de rotation du comité et des composants complexes tels que le comité de synchronisation, simplifiant considérablement les spécifications du protocole. L'implémentation centrale nécessite seulement environ 200 lignes de code, atteignant un niveau de sécurité presque optimal par rapport au protocole Gasper.
Optimisation de la gestion des nœuds de validation : en limitant le nombre de nœuds de validation actifs, les règles de sélection de fork peuvent être mises en œuvre de manière plus simplifiée, tout en garantissant la sécurité du système.
Mise à niveau du protocole d'agrégation : le mécanisme d'agrégation basé sur STARK permet à n'importe quel nœud d'assumer le rôle d'agrégateur, évitant ainsi la dépendance à la confiance envers l'agrégateur et le problème du gaspillage de ressources lié aux champs de bits (bitfield) répétitifs. Bien que la cryptographie d'agrégation elle-même soit relativement complexe, ses caractéristiques de haute encapsulation réduisent considérablement le risque systémique.
Amélioration de l'architecture réseau P2P : Les deux optimisations mentionnées ci-dessus offrent la possibilité de construire une architecture réseau P2P plus simple et plus efficace.
Refonte du processus de validation : redéfinir les mécanismes d'admission, de sortie, de retrait, de migration de clés et de pénalités pour inactivité des nœuds de validation, tout en réduisant la quantité de code, et en clarifiant les mécanismes de garantie des paramètres clés (comme le cycle subjectif faible).
Avantages technologiques : la caractéristique de découplage relatif entre la couche de consensus et la couche d'exécution EVM offre un plus grand espace technique pour une optimisation continue. En revanche, les améliorations similaires de la couche d'exécution font face à des défis plus importants.
Niveau d'exécution simplifié
La complexité de la machine virtuelle Ethereum (EVM) continue de croître, avec de nombreux designs complexes qui se sont révélés inutiles (dans de nombreux cas, en raison de mes erreurs de jugement) : une machine virtuelle de 256 bits sur-optimisée pour des algorithmes cryptographiques spécifiques, alors que ces algorithmes ont progressivement perdu de leur importance ; ainsi que des contrats précompilés sur-conçus pour un seul cas d'utilisation, dont le taux d'utilisation réel est très faible.
Essayer de résoudre les problèmes existants par des réparations ponctuelles n'est plus faisable. Supprimer l'opcode SELFDESTRUCT nécessite un effort énorme mais ne rapporte que des bénéfices limités, et les récentes discussions sur l'EOF mettent encore plus en évidence les difficultés de modifications progressives de la machine virtuelle.
En tant qu'alternative, j'ai récemment proposé une voie de transformation plus radicale : plutôt que d'apporter des modifications de taille moyenne (mais toujours destructrices) à l'EVM en échange d'une amélioration de performance de 1,5 fois, il serait préférable de passer directement à une toute nouvelle architecture de machine virtuelle qui soit nettement meilleure, afin d'atteindre une augmentation de performance par un facteur de cent. Tout comme la fusion (The Merge), nous réduisons le nombre de changements destructeurs, tout en augmentant la valeur stratégique de chaque changement. Plus précisément, il est proposé d'adopter l'architecture RISC-V ou la machine virtuelle utilisée par les programmes de preuve ZK d'Ethereum en remplacement de l'EVM actuel. Cette transformation apportera :
Amélioration révolutionnaire de l'efficacité : dans un environnement de preuve ZK, les contrats intelligents peuvent s'exécuter directement sur l'architecture cible, sans les frais d'un interpréteur. Les données succinctes montrent qu'une amélioration des performances de plus de cent fois est possible dans la plupart des scénarios.
Architecture simplifiée à l'extrême : la spécification RISC-V est beaucoup plus concise par rapport à l'EVM, d'autres solutions candidates (comme Cairo) possèdent également des caractéristiques de simplicité.
Les principaux avantages d'Eof : gestion par segments de code, support d'analyse statique plus convivial et limites de capacité de code plus importantes.
Extension de la chaîne d'outils pour les développeurs : Solidity et Vyper peuvent prendre en charge de nouvelles architectures grâce à un support de compilation backend ajouté ; si RISC-V est choisi, les développeurs de langages mainstream peuvent directement porter le code existant.
Optimisation des contrats précompilés : la plupart des fonctions précompilées ne seront plus nécessaires, seules les calculs de courbes elliptiques hautement optimisées seront conservés (elles pourraient être éliminées avec le développement de l'informatique quantique).
Les principaux défis sont les suivants : contrairement aux solutions EOF pouvant être mises en œuvre immédiatement, la nouvelle machine virtuelle prendra plus de temps pour bénéficier aux développeurs. Il est possible de synchroniser la mise en œuvre de certaines améliorations EVM de grande valeur (comme l'augmentation des limites de taille de code des contrats, l'optimisation de l'ensemble d'instructions DUP/SWAP) comme solution de transition à court terme.
Cette transformation simplifiera considérablement l'architecture de la machine virtuelle. La question principale est : comment gérer correctement l'écosystème EVM existant ?
Stratégie de rétrocompatibilité pour la migration de machines virtuelles
Le plus grand défi pour simplifier (ou optimiser sans augmenter la complexité) n'importe quelle partie de l'EVM est de trouver un équilibre entre la réalisation des objectifs attendus et le maintien de la compatibilité descendante des applications existantes.
Il est d'abord nécessaire de clarifier que, même pour un seul client, il n'existe pas de norme unique pour définir ce qu'est le « code source Ethereum ».
L'objectif est de minimiser la zone verte : c'est-à-dire que les nœuds doivent exécuter la logique nécessaire à la participation au consensus Ethereum, y compris le calcul de l'état actuel, la génération et la vérification des preuves, FOCIL (Note : confirmer s'il s'agit d'un acronyme technique) ainsi que le processus de construction de blocs "de base".
La zone orange ne peut pas être réduite : si les fonctionnalités de la couche d'exécution (qu'il s'agisse d'une machine virtuelle, de contrats précompilés ou d'autres mécanismes) sont supprimées des spécifications du protocole ou si leurs fonctionnalités changent, le client devant traiter les blocs historiques doit conserver cette fonctionnalité ; mais le nouveau client (y compris ZK-EVM ou les outils de vérification formelle) peut totalement ignorer cette partie.
Nouvelle zone jaune : fait référence à des codes qui ont une grande valeur pour l'analyse des données actuelles sur la chaîne ou la construction de blocs optimaux, mais qui ne font pas partie du mécanisme de consensus. Des exemples typiques incluent le soutien d'Etherscan et de certains constructeurs de blocs pour les opérations des utilisateurs ERC-4337. Si les fonctionnalités de base d'Ethereum (comme les comptes externes EOA et les divers types de transactions anciennes qu'ils supportent) sont remplacées par une implémentation RISC-V sur la chaîne, le code de consensus sera considérablement simplifié, mais les nœuds spécialisés peuvent encore avoir besoin d'utiliser le code d'origine pour le traitement des analyses.
La complexité des zones orange et jaune appartient à la complexité d'encapsulation, et toute personne souhaitant comprendre le protocole peut sauter ces sections. De plus, les implémentations Ethereum peuvent librement choisir d'ignorer ces parties. En outre, les défauts de code dans ces zones ne déclencheront pas de risque de consensus. Cela signifie qu'en comparaison avec la complexité du code de la zone verte, la complexité des zones orange et jaune a un impact négatif significativement moindre sur l'ensemble du système.
L'idée de migrer le code de la zone verte vers la zone jaune est similaire à la solution technique à long terme de compatibilité arrière qu'Apple a réalisée grâce à la couche de traduction Rosetta.
Il est exigé que tous les nouveaux contrats précompilés développés comprennent une mise en œuvre RISC-V conforme sur la chaîne. Cette étape vise à inciter l'écosystème à s'adapter progressivement à l'environnement de machine virtuelle RISC-V (à titre d'exemple de la migration de l'EVM vers RISC-V, cette solution s'applique également à la migration de l'EVM vers Cairo ou d'autres machines virtuelles plus performantes) :
Support parallèle de deux machines virtuelles : au niveau du protocole, prise en charge native simultanée des deux machines virtuelles RISC-V et EVM. Les développeurs peuvent choisir librement leur langage de développement, et les contrats écrits sur différentes machines virtuelles peuvent interagir sans couture.
Remplacement par phases des contrats précompilés : à l'exception des calculs de courbes elliptiques et de l'algorithme de hachage KECCAK (en raison de leurs exigences de performance extrêmement optimisées), tous les contrats précompilés sont remplacés par une implémentation RISC-V par hard fork.
L'opération spécifique consiste à supprimer le contrat précompilé d'origine tout en modifiant le code à cette adresse (en utilisant le mode de fork DAO) de l'état vide à la mise en œuvre correspondante de RISC-V. En raison de la grande simplicité de l'architecture RISC-V, même si cette étape est seulement complétée, la complexité globale du système sera toujours réduite.
Déploiement de l'interpréteur EVM sur la chaîne : mise en œuvre de l'interpréteur EVM basé sur RISC-V (la chaîne d'outils de preuve ZK a favorisé ce type de développement) et déploiement de celui-ci en tant que contrat intelligent sur la chaîne. Des années après la publication de la version initiale, les contrats EVM existants seront exécutés via cet interpréteur, permettant ainsi une transition en douceur vers la nouvelle machine virtuelle.
Simplification via le composant de protocole de partage
Une fois l'étape quatre terminée, de nombreuses « solutions d'implémentation EVM » resteront disponibles et seront utilisées pour optimiser la construction de blocs, les outils pour développeurs et l'analyse de données on-chain, mais ces implémentations ne feront plus partie des composants du protocole de consensus central. À ce moment-là, le mécanisme de consensus Ethereum supportera « nativement » uniquement l'architecture RISC-V.
Simplification par le biais de composants de protocole de partage
La troisième méthode pour réduire la complexité globale des protocoles (et la plus souvent sous-estimée) consiste à partager des normes unifiées autant que possible entre les différents niveaux de la pile de protocoles. En général, il est à la fois inutile et non rentable d'utiliser des protocoles différents dans différents modules pour réaliser la même fonctionnalité, mais ce type de modèle de conception existe néanmoins de manière répandue, principalement en raison d'un manque de synergie efficace entre les différentes parties de la feuille de route des protocoles. Voici des exemples de scénarios dans lesquels le renforcement de la réutilisation des composants à travers les couches peut simplifier Ethereum.
Solution de code de suppression et de partage unifié
Trois types de scénarios d'application des codes de correction d'effacement :
Échantillonnage de la disponibilité des données : le client doit utiliser le code de correction d'erreur lors de la vérification si le bloc a été publié, afin d'assurer l'intégrité des données.
Diffusion P2P efficace : les nœuds peuvent confirmer le bloc dès qu'ils reçoivent n/2 des n fragments, réalisant ainsi un équilibre optimal entre la réduction des délais et le degré de redondance.
Stockage historique distribué : les données historiques d'Ethereum sont divisées en plusieurs blocs de données, répondant à :
Chaque bloc de données peut être vérifié indépendamment.
Il suffit de n/2 blocs de données dans n'importe quel groupe pour récupérer les n/2 blocs de données restants.
Ce design réduit considérablement le risque de perte de données en un seul point.
L'utilisation du même code de correction d'erreurs (comme le code de Reed-Solomon, le code linéaire aléatoire, etc.) dans les trois scénarios suivants présentera des avantages significatifs :
Code simplifié;
Amélioration de l'efficacité : lorsque les nœuds doivent télécharger des données de fragment en raison d'un scénario (plutôt que d'un bloc complet), ces données peuvent être directement utilisées pour d'autres scénarios, évitant ainsi les transmissions redondantes ;
Tous les blocs de données de tous les scénarios peuvent être vérifiés de manière uniforme via le hash racine.
Si des codes de correction différents sont utilisés, il est nécessaire de satisfaire aux exigences de compatibilité : par exemple, dans l'échantillonnage de disponibilité des données (DAS) en morceaux, il est possible d'utiliser simultanément des codes de Reed-Solomon horizontaux et des codes linéaires aléatoires verticaux, mais les deux types de codage doivent être calculés sur le même corps fini.
Format de sérialisation unifié
Le format de sérialisation actuel d'Ethereum est encore à moitié normalisé - les données peuvent être re-sérialisées dans n'importe quel format et propagées, la seule exception étant le hachage de la signature de la transaction, qui doit adopter un format normalisé pour garantir la cohérence du hachage. Cependant, à l'avenir, le degré de normalisation du format de sérialisation sera renforcé, principalement pour les raisons suivantes :
Abstraction de compte (EIP-7701) : le contenu complet de la transaction sera entièrement visible pour la machine virtuelle (VM)
Scénario de limite de Gas élevé : Avec l'augmentation de la limite de Gas du bloc, les données de la couche d'exécution doivent être stockées dans une structure blob.
Lorsque cette transformation se produit, nous pouvons saisir cette occasion pour unifier les normes de sérialisation des trois niveaux clés d'Ethereum : (i) couche d'exécution (ii) couche de consensus (iii) appel d'ABI de contrat intelligent.
Il est recommandé d'adopter le format de sérialisation SSZ, qui présente les avantages suivants :
Le décodage est efficace et les scénarios, y compris les contrats intelligents, peuvent être décodés rapidement grâce à sa conception basée sur 4 octets et à un traitement limité des conditions aux limites.
La couche de consensus est largement appliquée et a été profondément intégrée au niveau de la couche de consensus.
Très similaire à l'ABI existant, facilitant la mise à niveau et l'adaptation de la chaîne d'outils.
Des équipes techniques pertinentes travaillent déjà à la migration complète de SSZ. Il est conseillé de poursuivre cette voie technique dans les futures planifications de mise à niveau et d'étendre les résultats existants.
Arbre de structure partagé unifié
Lorsque l'on passe de l'EVM à RISC-V (ou à d'autres architectures de machines virtuelles simplifiées), l'arbre Merkle Patricia à six branches deviendra le principal goulet d'étranglement des preuves d'exécution des blocs (même dans des scénarios normaux). Passer à une structure d'arbre binaire basée sur une fonction de hachage plus optimale améliorera considérablement l'efficacité des preuves et réduira les coûts de stockage des données pour les nœuds légers et d'autres scénarios d'application.
Lors de la mise en œuvre de cette migration, il convient d'adopter simultanément la même structure arborescente pour réaliser l'unification de la couche de consensus et de la couche d'exécution. Cette démarche garantit que l'ensemble de la pile Ethereum (y compris la couche de consensus et la couche d'exécution) utilise la même logique de code pour l'accès et l'analyse des données.
Le chemin d'évolution de l'état actuel à l'objectif
La simplicité présente des similitudes avec la décentralisation à plusieurs égards, les deux étant des prérequis fondamentaux pour réaliser la résilience des systèmes. Il est nécessaire d'opérer un changement culturel pour faire de la simplicité une valeur centrale : ses bénéfices sont souvent difficiles à percevoir immédiatement, tandis que les gains à court terme liés à la recherche de fonctionnalités complexes sont évidents. Cependant, avec le temps, les avantages de la simplicité deviendront de plus en plus significatifs - le parcours de développement de Bitcoin en est une puissante illustration.
Je propose de concevoir le protocole Ethereum en s'appuyant sur l'expérience pratique du projet TinyGrad, afin de définir un objectif clair de limite du nombre de lignes de code pour les normes Ethereum à long terme, cherchant à rendre la simplicité du code critique du consensus Ethereum proche du niveau de Bitcoin. Plus précisément, le code relatif aux règles historiques d'Ethereum peut continuer à être conservé, mais doit être strictement isolé en dehors du chemin critique du consensus, garantissant qu'il n'affecte pas la logique de consensus centrale ; en même temps, le choix des solutions techniques doit appliquer le principe de "préférer des solutions plus simples", en encapsulant la complexité plutôt qu'en diffusant une complexité systémique, et en s'assurant que toutes les décisions de conception offrent des caractéristiques et des garanties claires et vérifiables, formant ainsi globalement une culture technique orientée vers la simplicité.