Ethereum vise à devenir un grand livre mondial, nécessitant évolutivité et résilience. Cet article se concentre sur l'importance de la simplicité du protocole et propose de réduire considérablement la complexité en simplifiant la couche de consensus (finalité 3-slot, agrégation STARK) et la couche d'exécution (remplacer l'EVM par RISC-V ou une machine virtuelle similaire), réduisant ainsi les coûts de développement, les risques d'erreurs et la surface d'attaque. Il est suggéré d'effectuer une transition en douceur grâce à une stratégie de rétrocompatibilité (comme un interpréteur EVM en chaîne) et d'unifier les codes de correction d'erreurs, le format de sérialisation (SSZ) et la structure d'arbre pour simplifier davantage. L'objectif est d'amener le code clé de consensus d'Ethereum à une simplicité proche de celle de Bitcoin, améliorant ainsi la résilience et l'engagement, tout en mettant culturellement l'accent sur la simplicité et en établissant un objectif de nombre maximal de lignes de code.
L'objectif d'Ethereum est de devenir un registre mondial : une plateforme pour stocker les actifs et les enregistrements de la civilisation humaine, au service des domaines financier, de la gouvernance, de la certification de données de haute valeur, etc. Cela nécessite un soutien dans deux domaines : l'évolutivité et la résilience. Le plan de hard fork de Fusaka augmentera l'espace disponible pour les données L2 par 10 fois, tandis que la feuille de route proposée pour 2026 prévoit également d'apporter des améliorations similaires au niveau L1. Parallèlement, Ethereum a achevé sa transition vers la preuve d'enjeu (PoS), la diversité des clients a rapidement augmenté, la validation par zéro connaissance (ZK) et la recherche sur la résistance quantique avancent également de manière régulière, et l'écosystème d'applications devient de plus en plus robuste.
Cet article vise à se concentrer sur un élément de résilience (voire d'évolutivité) tout aussi important mais souvent sous-estimé : la simplicité du protocole.
Ce qui est le plus remarquable dans le protocole Bitcoin, c'est son élégante simplicité :
Il existe une chaîne composée de blocs, chaque bloc étant lié au bloc précédent par un hachage.
La validité du bloc est vérifiée par la preuve de travail (PoW), c'est-à-dire en vérifiant si les premiers chiffres du hachage sont nuls.
Chaque bloc contient des transactions, les pièces dépensées proviennent soit de récompenses de minage, soit de sorties de transactions précédentes.
C'est tout ! Même un lycéen intelligent peut comprendre parfaitement le fonctionnement du protocole Bitcoin, tandis qu'un programmeur peut même écrire un client en tant que projet amateur.
La simplicité du protocole a apporté de nombreux avantages clés à Bitcoin (et Ethereum) en tant que couche de base mondiale fiable et neutre :
Facile à comprendre : réduire la complexité du protocole pour permettre à un plus grand nombre de personnes de participer à la recherche, au développement et à la gouvernance du protocole, réduisant ainsi le risque de domination par une élite technique.
Réduire les coûts de développement : Simplifier le protocole réduit considérablement le coût de création de nouvelles infrastructures (telles que de nouveaux clients, des proveurs, des outils pour développeurs, etc.).
Réduire la charge de maintenance : diminuer le coût de la maintenance des accords à long terme.
Réduire le risque d'erreurs : diminuer la probabilité d'erreurs catastrophiques dans les spécifications et l'implémentation des protocoles, tout en facilitant la vérification de l'absence de telles erreurs.
Réduire la surface d'attaque : diminuer les composants complexes du protocole pour réduire le risque d'attaques par des groupes d'intérêts particuliers.
Dans l'histoire, Ethereum (parfois à cause de mes décisions personnelles) a souvent échoué à rester simple, entraînant des coûts de développement trop élevés, une augmentation des risques de sécurité et une culture de recherche et développement fermée, tandis que les bénéfices de cette quête de complexité se sont souvent révélés illusoires. Cet article explorera comment Ethereum, cinq ans plus tard, se rapproche de la simplicité de Bitcoin.
Couche de consensus simplifiée
La nouvelle conception de la couche de consensus (historique appelée "chaîne de balisage") vise à tirer parti de l'expérience des dix dernières années dans des domaines tels que la théorie du consensus, le développement de ZK-SNARK et l'économie de la mise, pour construire une couche de consensus optimale à long terme et plus simple. Par rapport à la chaîne de balisage existante, la nouvelle conception simplifie considérablement :
Conception finale à 3 emplacements : suppression des concepts de slot, d'époque, de réorganisation du comité, etc., ainsi que des mécanismes de traitement efficaces associés (comme le comité de synchronisation). La mise en œuvre de la finalité à 3 emplacements nécessite seulement environ 200 lignes de code, et par rapport à Gasper, la sécurité est presque optimale.
Réduire le nombre de validateurs actifs : permettre l'utilisation de règles de sélection de forks plus simples pour renforcer la sécurité.
Protocole d'agrégation basé sur STARK : tout le monde peut devenir agrégateur, sans avoir besoin de faire confiance à l'agrégateur ou de payer des frais élevés pour des domaines de bits répétés. La complexité de la cryptographie d'agrégation est élevée, mais cette complexité est fortement encapsulée, ce qui réduit les risques systémiques.
Simplification de l'architecture P2P : Les facteurs mentionnés ci-dessus pourraient soutenir une architecture de réseau pair à pair plus simple et plus robuste.
Reconcevoir le mécanisme des validateurs : y compris les mécanismes d'entrée, de sortie, de retrait, de conversion de clés, de fuite d'inactivité, etc., simplifier le nombre de lignes de code et fournir des garanties plus claires (comme les périodes de faible subjectivité).
L'avantage de la couche de consensus réside dans son indépendance relative par rapport à la couche d'exécution EVM, ce qui offre un espace considérable pour des améliorations continues. Le plus grand défi réside dans la manière de réaliser une simplification similaire au niveau de la couche d'exécution.
Niveau d'exécution simplifié
La complexité de l'EVM augmente de manière exponentielle, et de nombreuses complexités se sont révélées inutiles (en partie à cause de mes erreurs de jugement personnelles) : un système virtuel de 256 bits a trop optimisé des formes cryptographiques spécifiques qui sont désormais progressivement obsolètes, les précompilations ont été optimisées pour un usage unique mais sont rarement utilisées.
Résoudre ces problèmes un par un est peu efficace. Par exemple, supprimer l'opcode SELFDESTRUCT nécessite un effort considérable, mais ne rapporte que peu de bénéfices. Les récentes discussions sur l'EOF (EVM Object Format) montrent également des défis similaires.
J'ai récemment proposé un plan plus radical : plutôt que d'apporter des modifications de taille moyenne (mais toujours destructrices) à l'EVM pour un rendement de 1,5 fois, il vaudrait mieux passer à une machine virtuelle plus efficace et plus simple pour obtenir un rendement de 100 fois. Semblable à la "fusion" (The Merge), nous réduisons le nombre de modifications destructrices, mais rendons chaque changement plus significatif. Plus précisément, je propose de remplacer l'EVM par RISC-V, ou une autre machine virtuelle utilisée par le prouveur ZK d'Ethereum. Cela apporterait :
Amélioration significative de l'efficacité : l'exécution des contrats intelligents (dans le prouveur) se fait sans frais d'interpréteur, directement exécutée. Les données de Succinct montrent que dans de nombreux scénarios, les performances peuvent être améliorées de plus de 100 fois.
Amélioration significative de la simplicité : la spécification RISC-V est extrêmement simple par rapport à l'EVM, tout comme les alternatives (comme Cairo).
Motivations pour le support d'Eof : telles que la partition de code, une analyse statique plus conviviale, des limites de taille de code plus importantes, etc.
Plus de choix pour les développeurs : Solidity et Vyper peuvent ajouter un backend pour compiler vers une nouvelle machine virtuelle. Si RISC-V est choisi, les développeurs de langages mainstream peuvent également facilement porter leur code vers cette machine virtuelle.
Suppression de la plupart des précompilés : il se peut que seules les opérations de courbe elliptique hautement optimisées soient conservées (avec la généralisation des ordinateurs quantiques, même celles-ci disparaîtront).
L'inconvénient majeur est que, contrairement à l'EOF prêt à l'emploi, les bénéfices de la nouvelle machine virtuelle mettront plus de temps à profiter aux développeurs. Nous pouvons atténuer ce problème en mettant en œuvre à court terme des améliorations EVM de grande valeur (telles que l'augmentation de la limite de taille du code des contrats, le support de DUP/SWAP17–32).
Cela conduira à une machine virtuelle plus simple. Le principal défi est le suivant : comment gérer l'EVM existant ?
Stratégie de compatibilité descendante pour la transition de la machine virtuelle
Le plus grand défi pour simplifier (ou améliorer sans augmenter la complexité) l'EVM est de trouver un équilibre entre la réalisation des objectifs et la compatibilité descendante avec les applications existantes.
Il est d'abord nécessaire de préciser que la base de code d'Ethereum (même au sein d'un seul client) n'a pas qu'une seule définition.
L'objectif est de réduire autant que possible la zone verte : la logique requise pour que les nœuds participent au consensus Ethereum, y compris le calcul de l'état actuel, les preuves, la vérification, FOCIL (règle de sélection de fourche) et la construction de blocs "ordinaires".
La zone orange ne peut pas être réduite : si la spécification du protocole supprime ou modifie une fonction de couche d'exécution (comme la machine virtuelle, les précompilations, etc.), le client traitant les blocs historiques doit toujours conserver le code pertinent. Cependant, les nouveaux clients, ZK-EVM ou les vérificateurs formels peuvent complètement ignorer la zone orange.
Nouvelle zone jaune : très utile pour comprendre la chaîne actuelle ou optimiser la construction de blocs, mais ne fait pas partie de la logique de consensus. Par exemple, Etherscan et certains constructeurs de blocs prennent en charge les opérations des utilisateurs ERC-4337. Si nous remplaçons certaines fonctionnalités d'Ethereum (comme EOA et ses anciens types de transactions pris en charge) 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 continuer à utiliser le code d'origine pour l'analyse.
La complexité des zones orange et jaune est celle de l'encapsulation de la complexité, les personnes qui comprennent le protocole peuvent ignorer ces parties, Ethereum peut les ignorer, les erreurs dans ces zones ne déclencheront pas de risque de consensus. Par conséquent, la complexité du code dans les zones orange et jaune est beaucoup moins nuisible que celle de la zone verte.
L'idée de déplacer le code de la zone verte vers la zone jaune est similaire à la stratégie d'Apple qui utilise une couche de traduction Rosetta pour garantir une compatibilité à long terme.
Inspiré par l'article récent de l'équipe Ipsilon, je propose le processus suivant de changement de machine virtuelle (en prenant l'exemple de EVM à RISC-V, mais cela peut également être utilisé pour EVM à Cairo ou RISC-V à une machine virtuelle plus performante) :
Exiger que la nouvelle précompilation fournisse une implémentation RISC-V sur la chaîne : permettre à l'écosystème de s'adapter progressivement à la machine virtuelle RISC-V.
Introduction de RISC-V comme option de développeur : le protocole prend en charge à la fois RISC-V et EVM, les contrats des deux machines virtuelles peuvent interagir librement.
Remplacer la plupart des précompilés : à l'exception des opérations de courbe elliptique et de KECCAK (en raison de la nécessité d'une vitesse extrême), remplacer les autres précompilés par RISC-V. Supprimer les précompilés par un hard fork, tout en changeant le code à cette adresse (similaire au fork DAO) de vide à une implémentation RISC-V. La machine virtuelle RISC-V est extrêmement simple, même à ce stade, elle simplifie considérablement le protocole.
Implémenter un interpréteur EVM dans RISC-V : en tant que contrat intelligent sur la chaîne (puisque le prouveur ZK doit être effectué). Après plusieurs années de publication initiale, les contrats EVM existants fonctionnent via cet interpréteur.
Après avoir terminé l'étape 4, de nombreuses "implémentations EVM" continueront d'être utilisées pour optimiser la construction de blocs, les outils pour développeurs et l'analyse de chaînes, mais ne feront plus partie des spécifications de consensus clés. Le consensus Ethereum comprendra "nativement" uniquement RISC-V.
Simplifier par des composants de protocole de partage
La troisième façon de réduire la complexité totale du protocole (qui est aussi la plus susceptible d'être sous-estimée) consiste à partager des normes unifiées autant que possible entre les différentes parties de la pile de protocoles. Différents protocoles qui font la même chose dans des contextes différents sont souvent inutiles, mais ce modèle apparaît encore fréquemment, principalement en raison du manque de communication entre les différentes parties de la feuille de route du protocole. Voici quelques exemples concrets de simplification d'Ethereum grâce au partage de composants.
Code de correction d'effacement unifié
Nous avons besoin de codes de correction dans trois scénarios :
Échantillonnage de la disponibilité des données : le client vérifie que le bloc a été publié.
Diffusion P2P plus rapide : les nœuds peuvent accepter le bloc après avoir reçu n/2 segments, trouvant un équilibre entre latence et redondance.
Stockage historique distribué : les données historiques d'Ethereum sont stockées en morceaux, chaque groupe de n/2 segments peut récupérer les segments restants, réduisant ainsi le risque de perte d'un seul segment.
Si le même code de correction d'erreurs (qu'il s'agisse de Reed-Solomon, de codes linéaires aléatoires, etc.) est utilisé dans les trois scénarios, les avantages suivants seront obtenus :
Minimiser la quantité de code : réduire le nombre total de lignes de code.
Améliorer l'efficacité : Si un nœud télécharge des segments partiels pour un certain scénario, ces données peuvent être utilisées pour d'autres scénarios.
Assurer la vérifiabilité : tous les fragments de scène peuvent être vérifiés selon la racine.
Si vous utilisez des codes de correction d'erreurs différents, vous devez au moins garantir la compatibilité, par exemple, le code Reed-Solomon pour l'échantillonnage de la disponibilité des données et le code linéaire aléatoire vertical fonctionnent dans le même domaine.
Format de sérialisation unifié
Le format de sérialisation d'Ethereum est actuellement seulement partiellement figé, car les données peuvent être re-sérialisées et diffusées dans n'importe quel format. La seule exception est le hachage de la signature de transaction, qui doit être haché dans un format standard. À l'avenir, le degré de solidité du format de sérialisation sera encore renforcé pour les raisons suivantes :
Abstraction complète des comptes (EIP-7701) : le contenu complet des transactions est visible par la machine virtuelle.
Limite de Gas plus élevée : les données de la couche d'exécution doivent être placées dans des blocs de données (blobs).
À ce moment-là, nous aurons l'occasion d'unifier les formats de sérialisation des trois niveaux d'Ethereum : le niveau d'exécution, le niveau de consensus et l'appel ABI des contrats intelligents.
Je propose d'utiliser SSZ, car SSZ :
Facile à décoder : inclus dans le contrat intelligent (en raison de sa conception basée sur 4 octets et de moins de cas particuliers).
Déjà largement utilisé dans la couche de consensus.
Très similaire à l'ABI existant : l'adaptation de l'outil est relativement simple.
Des efforts ont déjà été déployés pour une migration complète vers SSZ, et nous devrions prendre en compte et poursuivre ces efforts lors de la planification des futures mises à niveau.
Structure d'arbre unifiée
Si l'on migre de l'EVM vers RISC-V (ou d'autres machines virtuelles minimales optionnelles), l'arbre Merkle Patricia hexadécimal deviendra le principal goulot d'étranglement pour prouver l'exécution des blocs, même dans des cas moyens. Migrer vers un arbre binaire basé sur une meilleure fonction de hachage améliorera considérablement l'efficacité du prouveur tout en réduisant le coût des données dans des scénarios comme celui des clients légers.
Lors de la migration, il est important de s'assurer que la couche de consensus utilise la même structure d'arbre. Cela permettra à la couche de consensus d'Ethereum d'accéder et d'analyser la couche d'exécution via le même code.
Du présent au futur
La simplicité est, à bien des égards, similaire à la décentralisation, les deux étant des objectifs de résilience en amont. Accorder une importance claire à la simplicité nécessite un certain changement culturel. Ses bénéfices sont souvent difficiles à quantifier, tandis que le coût des efforts supplémentaires et de l'abandon de certaines fonctionnalités brillantes est immédiat. Cependant, avec le temps, les bénéfices deviennent de plus en plus évidents — le Bitcoin lui-même en est un excellent exemple.
Je propose de s'inspirer de tinygrad pour établir un objectif clair de nombre maximal de lignes de code pour la norme à long terme d'Ethereum, afin que le code clé du consensus d'Ethereum se rapproche de la simplicité de Bitcoin. Le code traitant des règles historiques d'Ethereum continuera d'exister, mais devrait être placé en dehors du chemin clé du consensus. En même temps, nous devrions adhérer à l'idée de choisir des solutions plus simples, en privilégiant l'encapsulation de la complexité plutôt que la complexité systémique, et en faisant des choix de conception qui offrent des attributs et des garanties clairs.
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.
Blog de Vitalik : Comment rendre Ethereum dans 5 ans aussi simple que Bitcoin
Auteur | Vitalik Buterin
Compilation | GaryMa Wu parle de la blockchain
Lien original :
Résumé
Ethereum vise à devenir un grand livre mondial, nécessitant évolutivité et résilience. Cet article se concentre sur l'importance de la simplicité du protocole et propose de réduire considérablement la complexité en simplifiant la couche de consensus (finalité 3-slot, agrégation STARK) et la couche d'exécution (remplacer l'EVM par RISC-V ou une machine virtuelle similaire), réduisant ainsi les coûts de développement, les risques d'erreurs et la surface d'attaque. Il est suggéré d'effectuer une transition en douceur grâce à une stratégie de rétrocompatibilité (comme un interpréteur EVM en chaîne) et d'unifier les codes de correction d'erreurs, le format de sérialisation (SSZ) et la structure d'arbre pour simplifier davantage. L'objectif est d'amener le code clé de consensus d'Ethereum à une simplicité proche de celle de Bitcoin, améliorant ainsi la résilience et l'engagement, tout en mettant culturellement l'accent sur la simplicité et en établissant un objectif de nombre maximal de lignes de code.
L'objectif d'Ethereum est de devenir un registre mondial : une plateforme pour stocker les actifs et les enregistrements de la civilisation humaine, au service des domaines financier, de la gouvernance, de la certification de données de haute valeur, etc. Cela nécessite un soutien dans deux domaines : l'évolutivité et la résilience. Le plan de hard fork de Fusaka augmentera l'espace disponible pour les données L2 par 10 fois, tandis que la feuille de route proposée pour 2026 prévoit également d'apporter des améliorations similaires au niveau L1. Parallèlement, Ethereum a achevé sa transition vers la preuve d'enjeu (PoS), la diversité des clients a rapidement augmenté, la validation par zéro connaissance (ZK) et la recherche sur la résistance quantique avancent également de manière régulière, et l'écosystème d'applications devient de plus en plus robuste.
Cet article vise à se concentrer sur un élément de résilience (voire d'évolutivité) tout aussi important mais souvent sous-estimé : la simplicité du protocole.
Ce qui est le plus remarquable dans le protocole Bitcoin, c'est son élégante simplicité :
Il existe une chaîne composée de blocs, chaque bloc étant lié au bloc précédent par un hachage.
La validité du bloc est vérifiée par la preuve de travail (PoW), c'est-à-dire en vérifiant si les premiers chiffres du hachage sont nuls.
Chaque bloc contient des transactions, les pièces dépensées proviennent soit de récompenses de minage, soit de sorties de transactions précédentes.
C'est tout ! Même un lycéen intelligent peut comprendre parfaitement le fonctionnement du protocole Bitcoin, tandis qu'un programmeur peut même écrire un client en tant que projet amateur.
La simplicité du protocole a apporté de nombreux avantages clés à Bitcoin (et Ethereum) en tant que couche de base mondiale fiable et neutre :
Facile à comprendre : réduire la complexité du protocole pour permettre à un plus grand nombre de personnes de participer à la recherche, au développement et à la gouvernance du protocole, réduisant ainsi le risque de domination par une élite technique.
Réduire les coûts de développement : Simplifier le protocole réduit considérablement le coût de création de nouvelles infrastructures (telles que de nouveaux clients, des proveurs, des outils pour développeurs, etc.).
Réduire la charge de maintenance : diminuer le coût de la maintenance des accords à long terme.
Réduire le risque d'erreurs : diminuer la probabilité d'erreurs catastrophiques dans les spécifications et l'implémentation des protocoles, tout en facilitant la vérification de l'absence de telles erreurs.
Réduire la surface d'attaque : diminuer les composants complexes du protocole pour réduire le risque d'attaques par des groupes d'intérêts particuliers.
Dans l'histoire, Ethereum (parfois à cause de mes décisions personnelles) a souvent échoué à rester simple, entraînant des coûts de développement trop élevés, une augmentation des risques de sécurité et une culture de recherche et développement fermée, tandis que les bénéfices de cette quête de complexité se sont souvent révélés illusoires. Cet article explorera comment Ethereum, cinq ans plus tard, se rapproche de la simplicité de Bitcoin.
Couche de consensus simplifiée
La nouvelle conception de la couche de consensus (historique appelée "chaîne de balisage") vise à tirer parti de l'expérience des dix dernières années dans des domaines tels que la théorie du consensus, le développement de ZK-SNARK et l'économie de la mise, pour construire une couche de consensus optimale à long terme et plus simple. Par rapport à la chaîne de balisage existante, la nouvelle conception simplifie considérablement :
Conception finale à 3 emplacements : suppression des concepts de slot, d'époque, de réorganisation du comité, etc., ainsi que des mécanismes de traitement efficaces associés (comme le comité de synchronisation). La mise en œuvre de la finalité à 3 emplacements nécessite seulement environ 200 lignes de code, et par rapport à Gasper, la sécurité est presque optimale.
Réduire le nombre de validateurs actifs : permettre l'utilisation de règles de sélection de forks plus simples pour renforcer la sécurité.
Protocole d'agrégation basé sur STARK : tout le monde peut devenir agrégateur, sans avoir besoin de faire confiance à l'agrégateur ou de payer des frais élevés pour des domaines de bits répétés. La complexité de la cryptographie d'agrégation est élevée, mais cette complexité est fortement encapsulée, ce qui réduit les risques systémiques.
Simplification de l'architecture P2P : Les facteurs mentionnés ci-dessus pourraient soutenir une architecture de réseau pair à pair plus simple et plus robuste.
Reconcevoir le mécanisme des validateurs : y compris les mécanismes d'entrée, de sortie, de retrait, de conversion de clés, de fuite d'inactivité, etc., simplifier le nombre de lignes de code et fournir des garanties plus claires (comme les périodes de faible subjectivité).
L'avantage de la couche de consensus réside dans son indépendance relative par rapport à la couche d'exécution EVM, ce qui offre un espace considérable pour des améliorations continues. Le plus grand défi réside dans la manière de réaliser une simplification similaire au niveau de la couche d'exécution.
Niveau d'exécution simplifié
La complexité de l'EVM augmente de manière exponentielle, et de nombreuses complexités se sont révélées inutiles (en partie à cause de mes erreurs de jugement personnelles) : un système virtuel de 256 bits a trop optimisé des formes cryptographiques spécifiques qui sont désormais progressivement obsolètes, les précompilations ont été optimisées pour un usage unique mais sont rarement utilisées.
Résoudre ces problèmes un par un est peu efficace. Par exemple, supprimer l'opcode SELFDESTRUCT nécessite un effort considérable, mais ne rapporte que peu de bénéfices. Les récentes discussions sur l'EOF (EVM Object Format) montrent également des défis similaires.
J'ai récemment proposé un plan plus radical : plutôt que d'apporter des modifications de taille moyenne (mais toujours destructrices) à l'EVM pour un rendement de 1,5 fois, il vaudrait mieux passer à une machine virtuelle plus efficace et plus simple pour obtenir un rendement de 100 fois. Semblable à la "fusion" (The Merge), nous réduisons le nombre de modifications destructrices, mais rendons chaque changement plus significatif. Plus précisément, je propose de remplacer l'EVM par RISC-V, ou une autre machine virtuelle utilisée par le prouveur ZK d'Ethereum. Cela apporterait :
Amélioration significative de l'efficacité : l'exécution des contrats intelligents (dans le prouveur) se fait sans frais d'interpréteur, directement exécutée. Les données de Succinct montrent que dans de nombreux scénarios, les performances peuvent être améliorées de plus de 100 fois.
Amélioration significative de la simplicité : la spécification RISC-V est extrêmement simple par rapport à l'EVM, tout comme les alternatives (comme Cairo).
Motivations pour le support d'Eof : telles que la partition de code, une analyse statique plus conviviale, des limites de taille de code plus importantes, etc.
Plus de choix pour les développeurs : Solidity et Vyper peuvent ajouter un backend pour compiler vers une nouvelle machine virtuelle. Si RISC-V est choisi, les développeurs de langages mainstream peuvent également facilement porter leur code vers cette machine virtuelle.
Suppression de la plupart des précompilés : il se peut que seules les opérations de courbe elliptique hautement optimisées soient conservées (avec la généralisation des ordinateurs quantiques, même celles-ci disparaîtront).
L'inconvénient majeur est que, contrairement à l'EOF prêt à l'emploi, les bénéfices de la nouvelle machine virtuelle mettront plus de temps à profiter aux développeurs. Nous pouvons atténuer ce problème en mettant en œuvre à court terme des améliorations EVM de grande valeur (telles que l'augmentation de la limite de taille du code des contrats, le support de DUP/SWAP17–32).
Cela conduira à une machine virtuelle plus simple. Le principal défi est le suivant : comment gérer l'EVM existant ?
Stratégie de compatibilité descendante pour la transition de la machine virtuelle
Le plus grand défi pour simplifier (ou améliorer sans augmenter la complexité) l'EVM est de trouver un équilibre entre la réalisation des objectifs et la compatibilité descendante avec les applications existantes.
Il est d'abord nécessaire de préciser que la base de code d'Ethereum (même au sein d'un seul client) n'a pas qu'une seule définition.
L'objectif est de réduire autant que possible la zone verte : la logique requise pour que les nœuds participent au consensus Ethereum, y compris le calcul de l'état actuel, les preuves, la vérification, FOCIL (règle de sélection de fourche) et la construction de blocs "ordinaires".
La zone orange ne peut pas être réduite : si la spécification du protocole supprime ou modifie une fonction de couche d'exécution (comme la machine virtuelle, les précompilations, etc.), le client traitant les blocs historiques doit toujours conserver le code pertinent. Cependant, les nouveaux clients, ZK-EVM ou les vérificateurs formels peuvent complètement ignorer la zone orange.
Nouvelle zone jaune : très utile pour comprendre la chaîne actuelle ou optimiser la construction de blocs, mais ne fait pas partie de la logique de consensus. Par exemple, Etherscan et certains constructeurs de blocs prennent en charge les opérations des utilisateurs ERC-4337. Si nous remplaçons certaines fonctionnalités d'Ethereum (comme EOA et ses anciens types de transactions pris en charge) 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 continuer à utiliser le code d'origine pour l'analyse.
La complexité des zones orange et jaune est celle de l'encapsulation de la complexité, les personnes qui comprennent le protocole peuvent ignorer ces parties, Ethereum peut les ignorer, les erreurs dans ces zones ne déclencheront pas de risque de consensus. Par conséquent, la complexité du code dans les zones orange et jaune est beaucoup moins nuisible que celle de la zone verte.
L'idée de déplacer le code de la zone verte vers la zone jaune est similaire à la stratégie d'Apple qui utilise une couche de traduction Rosetta pour garantir une compatibilité à long terme.
Inspiré par l'article récent de l'équipe Ipsilon, je propose le processus suivant de changement de machine virtuelle (en prenant l'exemple de EVM à RISC-V, mais cela peut également être utilisé pour EVM à Cairo ou RISC-V à une machine virtuelle plus performante) :
Exiger que la nouvelle précompilation fournisse une implémentation RISC-V sur la chaîne : permettre à l'écosystème de s'adapter progressivement à la machine virtuelle RISC-V.
Introduction de RISC-V comme option de développeur : le protocole prend en charge à la fois RISC-V et EVM, les contrats des deux machines virtuelles peuvent interagir librement.
Remplacer la plupart des précompilés : à l'exception des opérations de courbe elliptique et de KECCAK (en raison de la nécessité d'une vitesse extrême), remplacer les autres précompilés par RISC-V. Supprimer les précompilés par un hard fork, tout en changeant le code à cette adresse (similaire au fork DAO) de vide à une implémentation RISC-V. La machine virtuelle RISC-V est extrêmement simple, même à ce stade, elle simplifie considérablement le protocole.
Implémenter un interpréteur EVM dans RISC-V : en tant que contrat intelligent sur la chaîne (puisque le prouveur ZK doit être effectué). Après plusieurs années de publication initiale, les contrats EVM existants fonctionnent via cet interpréteur.
Après avoir terminé l'étape 4, de nombreuses "implémentations EVM" continueront d'être utilisées pour optimiser la construction de blocs, les outils pour développeurs et l'analyse de chaînes, mais ne feront plus partie des spécifications de consensus clés. Le consensus Ethereum comprendra "nativement" uniquement RISC-V.
Simplifier par des composants de protocole de partage
La troisième façon de réduire la complexité totale du protocole (qui est aussi la plus susceptible d'être sous-estimée) consiste à partager des normes unifiées autant que possible entre les différentes parties de la pile de protocoles. Différents protocoles qui font la même chose dans des contextes différents sont souvent inutiles, mais ce modèle apparaît encore fréquemment, principalement en raison du manque de communication entre les différentes parties de la feuille de route du protocole. Voici quelques exemples concrets de simplification d'Ethereum grâce au partage de composants.
Code de correction d'effacement unifié
Nous avons besoin de codes de correction dans trois scénarios :
Échantillonnage de la disponibilité des données : le client vérifie que le bloc a été publié.
Diffusion P2P plus rapide : les nœuds peuvent accepter le bloc après avoir reçu n/2 segments, trouvant un équilibre entre latence et redondance.
Stockage historique distribué : les données historiques d'Ethereum sont stockées en morceaux, chaque groupe de n/2 segments peut récupérer les segments restants, réduisant ainsi le risque de perte d'un seul segment.
Si le même code de correction d'erreurs (qu'il s'agisse de Reed-Solomon, de codes linéaires aléatoires, etc.) est utilisé dans les trois scénarios, les avantages suivants seront obtenus :
Minimiser la quantité de code : réduire le nombre total de lignes de code.
Améliorer l'efficacité : Si un nœud télécharge des segments partiels pour un certain scénario, ces données peuvent être utilisées pour d'autres scénarios.
Assurer la vérifiabilité : tous les fragments de scène peuvent être vérifiés selon la racine.
Si vous utilisez des codes de correction d'erreurs différents, vous devez au moins garantir la compatibilité, par exemple, le code Reed-Solomon pour l'échantillonnage de la disponibilité des données et le code linéaire aléatoire vertical fonctionnent dans le même domaine.
Format de sérialisation unifié
Le format de sérialisation d'Ethereum est actuellement seulement partiellement figé, car les données peuvent être re-sérialisées et diffusées dans n'importe quel format. La seule exception est le hachage de la signature de transaction, qui doit être haché dans un format standard. À l'avenir, le degré de solidité du format de sérialisation sera encore renforcé pour les raisons suivantes :
Abstraction complète des comptes (EIP-7701) : le contenu complet des transactions est visible par la machine virtuelle.
Limite de Gas plus élevée : les données de la couche d'exécution doivent être placées dans des blocs de données (blobs).
À ce moment-là, nous aurons l'occasion d'unifier les formats de sérialisation des trois niveaux d'Ethereum : le niveau d'exécution, le niveau de consensus et l'appel ABI des contrats intelligents.
Je propose d'utiliser SSZ, car SSZ :
Facile à décoder : inclus dans le contrat intelligent (en raison de sa conception basée sur 4 octets et de moins de cas particuliers).
Déjà largement utilisé dans la couche de consensus.
Très similaire à l'ABI existant : l'adaptation de l'outil est relativement simple.
Des efforts ont déjà été déployés pour une migration complète vers SSZ, et nous devrions prendre en compte et poursuivre ces efforts lors de la planification des futures mises à niveau.
Structure d'arbre unifiée
Si l'on migre de l'EVM vers RISC-V (ou d'autres machines virtuelles minimales optionnelles), l'arbre Merkle Patricia hexadécimal deviendra le principal goulot d'étranglement pour prouver l'exécution des blocs, même dans des cas moyens. Migrer vers un arbre binaire basé sur une meilleure fonction de hachage améliorera considérablement l'efficacité du prouveur tout en réduisant le coût des données dans des scénarios comme celui des clients légers.
Lors de la migration, il est important de s'assurer que la couche de consensus utilise la même structure d'arbre. Cela permettra à la couche de consensus d'Ethereum d'accéder et d'analyser la couche d'exécution via le même code.
Du présent au futur
La simplicité est, à bien des égards, similaire à la décentralisation, les deux étant des objectifs de résilience en amont. Accorder une importance claire à la simplicité nécessite un certain changement culturel. Ses bénéfices sont souvent difficiles à quantifier, tandis que le coût des efforts supplémentaires et de l'abandon de certaines fonctionnalités brillantes est immédiat. Cependant, avec le temps, les bénéfices deviennent de plus en plus évidents — le Bitcoin lui-même en est un excellent exemple.
Je propose de s'inspirer de tinygrad pour établir un objectif clair de nombre maximal de lignes de code pour la norme à long terme d'Ethereum, afin que le code clé du consensus d'Ethereum se rapproche de la simplicité de Bitcoin. Le code traitant des règles historiques d'Ethereum continuera d'exister, mais devrait être placé en dehors du chemin clé du consensus. En même temps, nous devrions adhérer à l'idée de choisir des solutions plus simples, en privilégiant l'encapsulation de la complexité plutôt que la complexité systémique, et en faisant des choix de conception qui offrent des attributs et des garanties clairs.