Ethereum vise à devenir un registre mondial, nécessitant évolutivité et résilience. Cet article se concentre sur l'importance de la simplicité des protocoles, proposant de réduire considérablement la complexité à travers la simplification de la couche de consensus (finalité en 3 slots, agrégation STARK) et de la couche d'exécution (remplacement de l'EVM par RISC-V ou une machine virtuelle similaire), réduisant ainsi les coûts de développement, les risques d'erreur et la surface d'attaque. Il est suggéré d'effectuer une transition en douceur grâce à une stratégie de compatibilité ascendante (comme un interpréteur EVM en chaîne) et d'unifier le code 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 à se rapprocher de la simplicité de Bitcoin, d'améliorer la résilience et la participation, tout en accordant une importance culturelle à la simplicité et en établissant un objectif de nombre maximal de lignes de code.
L'objectif d'Ethereum est de devenir un grand livre mondial : une plateforme pour stocker les actifs et les enregistrements de la civilisation humaine, au service des domaines tels que la finance, la gouvernance et la certification des données de haute valeur. Cela nécessite un soutien dans deux domaines : l'évolutivité et la résilience. Le plan de hard fork Fusaka augmentera l'espace disponible pour les données L2 par 10, tandis que la feuille de route proposée pour 2026 prévoit également d'apporter une amélioration similaire pour la couche L1. Pendant ce temps, Ethereum a achevé sa transition vers la preuve d'enjeu (PoS), la diversité des clients a rapidement augmenté, la vérification par zéro connaissance (ZK) et la recherche sur la résistance quantique avancent également de manière constante, et l'écosystème applicatif devient de plus en plus robuste.
Cet article vise à se concentrer sur un élément tout aussi important mais souvent sous-estimé de la résilience (voire de l'évolutivité) : la simplicité du protocole.
Ce qui est le plus impressionnant dans le protocole Bitcoin, c'est sa simplicité élégante :
Il existe une chaîne composée de blocs, chaque bloc étant lié au bloc précédent par un hachage.
La validité d'un bloc est vérifiée par la preuve de travail (PoW), c'est-à-dire en vérifiant si les premiers chiffres du hachage sont des zéros.
Chaque bloc contient des transactions, les pièces dépensées provenant soit des récompenses de minage, soit des sorties de transactions précédentes.
C'est tout ! Même un lycéen intelligent peut comprendre parfaitement le fonctionnement du protocole Bitcoin, et un programmeur peut même en faire un projet amateur en écrivant un client.
La simplicité du protocole a apporté de nombreux avantages clés au Bitcoin (et à l'Ethereum) pour devenir une couche de base mondiale fiable et neutre :
1. Facile à comprendre : Réduire la complexité des protocoles, permettant à un plus grand nombre de personnes de participer à la recherche, au développement et à la gouvernance des protocoles, réduisant ainsi les risques liés à une domination par une élite technique.
2. Réduction des coûts de développement : Simplifier le protocole réduit considérablement le coût de création de nouvelles infrastructures (comme de nouveaux clients, des prouveurs, des outils pour développeurs, etc.).
3. Réduire la charge de maintenance : réduire le coût de la maintenance des contrats à long terme.
4. 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.
5. Réduire la surface d'attaque : réduire les composants complexes du protocole afin de diminuer le risque d'attaques par des groupes d'intérêts particuliers.
Dans l'histoire, Ethereum (parfois à cause de mes décisions personnelles) n'a souvent pas réussi à rester simple, ce qui a entraîné 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
Le nouveau design de la couche de consensus (historiquement appelée "chaîne de balise") vise à tirer parti des dix dernières années d'expérience en théorie du consensus, développement de ZK-SNARK, économie de staking, etc., pour construire une couche de consensus optimale à long terme et plus simple. Par rapport à la chaîne de balise existante, le nouveau design simplifie considérablement :
1. Conception finale à 3 emplacements : suppression des concepts de slot, d'epoch et de réorganisation du comité, ainsi que des mécanismes de traitement efficaces associés (comme les comités 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 proche de l'optimum.
2. Réduire le nombre de validateurs actifs : Permettre l'utilisation de règles de sélection de fork plus simples pour renforcer la sécurité.
3. Protocole d'agrégation basé sur STARK : Tout le monde peut devenir agrégateur, sans avoir à faire confiance à l'agrégateur ni à 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 le risque systémique.
4. 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.
5. Reconcevoir le mécanisme de validation : y compris les mécanismes d'entrée, de sortie, de retrait, de conversion de clé, de fuite d'inactivité, etc., simplifiant le nombre de lignes de code et fournissant des garanties plus claires (comme les périodes de faibles 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 une plus grande marge d'amélioration continue. Le plus grand défi réside dans la manière d'implémenter une simplification similaire au sein de la couche d'exécution.
Couche d'exécution simplifiée
La complexité de l'EVM augmente de plus en plus, et de nombreuses complexités se sont révélées inutiles (en partie à cause de mes erreurs de jugement personnelles) : les machines virtuelles de 256 bits ont excessivement optimisé des formes cryptographiques spécifiques qui sont désormais progressivement obsolètes, les précompilations (precompiles) étant optimisées pour un seul cas d'utilisation mais rarement utilisées.
Résoudre ces problèmes un par un a un effet limité. Par exemple, éliminer l'opcode SELFDESTRUCT nécessite un effort énorme, mais ne rapporte que peu de bénéfices. Les récents débats 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 obtenir un rendement de 1,5 fois, il vaudrait mieux passer à une machine virtuelle plus optimale et plus simple pour réaliser un rendement de 100 fois. À l'instar de « la fusion » (The Merge), nous réduisons le nombre de changements destructeurs, mais rendons chaque changement plus significatif. Plus précisément, je suggère de remplacer l'EVM par RISC-V, ou une autre machine virtuelle utilisée par le prouveur ZK d'Ethereum. Cela apporterait :
1. Amélioration significative de l'efficacité : L'exécution des contrats intelligents (dans le prouveur) se fait sans frais d'interpréteur, directement. Les données de Succinct montrent que dans de nombreux scénarios, les performances peuvent être améliorées de plus de 100 fois.
2. Amélioration significative de la simplicité : La spécification RISC-V est extrêmement simple par rapport à l'EVM, et les alternatives (comme Cairo) sont tout aussi concises.
3. Motivations pour le support d'EOC : telles que la partition du code, une analyse statique plus conviviale, des limites de taille de code plus grandes, etc.
4. Plus de choix pour les développeurs : Solidity et Vyper peuvent ajouter un backend pour compiler vers la nouvelle machine virtuelle. Si RISC-V est choisi, les développeurs de langages mainstream peuvent également facilement porter leur code vers cette machine virtuelle.
5. Suppression de la plupart des précompilés : il se peut qu'il ne reste que des opérations sur les courbes elliptiques hautement optimisées (même celles-ci disparaîtront avec la généralisation des ordinateurs quantiques).
Le principal inconvénient 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 (comme l'augmentation de la limite de taille du code des contrats, le support de DUP/SWAP17-32).
Cela apportera une machine virtuelle plus simple. Le principal défi est : comment traiter l'EVM existant ?
Stratégie de compatibilité ascendante pour la transition de machines virtuelles
Le plus grand défi pour simplifier (ou améliorer sans augmenter la complexité) l'EVM réside dans la manière 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 le code source 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, la preuve, la vérification, FOCIL (règles de sélection de fork) et la construction de blocs "normaux".
Zone orange non réductible : 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. Mais le nouveau client, ZK-EVM ou le vérificateur formel peuvent complètement ignorer la zone orange.
Nouvelle zone jaune : très précieuse 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 en 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 la complexité de l'encapsulation. Les personnes qui comprennent le protocole peuvent ignorer ces parties, Ethereum peut les négliger, et les erreurs dans ces zones ne déclencheront pas de risque de consensus. Par conséquent, la complexité du code des zones orange et jaune est beaucoup moins dangereuse 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 la couche de traduction Rosetta pour garantir une compatibilité à long terme.
Inspiré par l'article récent de l'équipe Ipsilon, je propose le processus de changement de machine virtuelle suivant (en prenant l'exemple de EVM à RISC-V, mais qui peut également être utilisé pour EVM à Cairo ou RISC-V à une machine virtuelle supérieure) :
1. Exiger une nouvelle précompilation fournissant une implémentation RISC-V en chaîne : permettre à l'écosystème de s'adapter progressivement à la machine virtuelle RISC-V.
2. Introduction de RISC-V comme option de développement : Le protocole prend en charge à la fois RISC-V et EVM, et les contrats des deux machines virtuelles peuvent interagir librement.
3. 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 s'il s'arrête ici, cela simplifie considérablement le protocole.
4. Mise en œuvre d'un interpréteur EVM dans RISC-V : En tant que contrat intelligent sur la chaîne (car le prouveur ZK doit être en place). Des années après la 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.
Simplification par des composants de protocole de partage
La troisième façon de réduire la complexité globale des protocoles (et la plus souvent sous-estimée) est de partager des normes unifiées autant que possible dans les différentes parties de la pile de protocoles. Différents protocoles faisant la même chose dans des contextes différents sont souvent inutiles, mais ce modèle apparaît encore fréquemment, principalement en raison d'un manque de communication entre les différentes parties de la feuille de route des protocoles. Voici quelques exemples concrets de simplification d'Ethereum par le partage de composants.
Code de correction unifié
Nous avons besoin de codes de correction dans trois scénarios :
1. Échantillonnage de la disponibilité des données : le client vérifie que le bloc a été publié.
2. Diffusion P2P plus rapide : Les nœuds peuvent accepter un bloc après avoir reçu n/2 segments, trouvant un équilibre entre retard et redondance.
3. Stockage historique distribué : Les données historiques d'Ethereum sont stockées en fragments, chaque groupe de n/2 fragments peut restaurer les fragments restants, réduisant ainsi le risque de perte d'un fragment unique.
Si le même code de correction d'erreur (qu'il s'agisse de Reed-Solomon, de codes linéaires aléatoires, etc.) est utilisé dans trois scénarios, les avantages suivants seront obtenus :
1. Minimiser la quantité de code : Réduire le nombre total de lignes de code.
2. Améliorer l'efficacité : Si le nœud télécharge des segments de données pour un certain scénario, ces données peuvent être utilisées pour d'autres scénarios.
3. Assurer la vérifiabilité : Tous les fragments des scénarios peuvent être vérifiés en fonction de la racine.
Si vous utilisez différents codes de correction d'erreurs, vous devez au moins garantir la compatibilité, par exemple, les codes Reed-Solomon pour l'échantillonnage de la disponibilité des données doivent fonctionner dans le même domaine que les codes linéaires aléatoires verticaux.
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. Une exception concerne le hachage de la signature des transactions, qui doit être haché dans un format standardisé. À l'avenir, le degré de solidité du format de sérialisation sera encore accru pour les raisons suivantes :
1. Abstraction complète des comptes (EIP-7701) : Le contenu complet de la transaction est visible pour la machine virtuelle.
2. 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'ABI des appels de 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é au niveau de consensus.
Très similaire à l'ABI existant : l'adaptation de l'outil est relativement simple.
Il y a déjà des efforts pour une migration complète vers SSZ, nous devons 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 en 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 fonction de hachage plus optimisée améliorera considérablement l'efficacité du prouveur tout en réduisant le coût des données dans des scénarios tels que les 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 de parser la couche d'exécution via le même code.
Du présent au futur
La simplicité ressemble à la décentralisation à bien des égards, les deux étant des objectifs de résilience en amont. Accorder une attention 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 d'apparence éblouissante est immédiat. Cependant, avec le temps, les bénéfices deviendront de plus en plus significatifs — — le Bitcoin en est un excellent exemple.
Je propose de suivre l'exemple de tinygrad en établissant 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. Parallèlement, 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 faire 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.
Vitalik Blog : Comment rendre Ethereum dans 5 ans aussi simple que Bitcoin
Résumé
Ethereum vise à devenir un registre mondial, nécessitant évolutivité et résilience. Cet article se concentre sur l'importance de la simplicité des protocoles, proposant de réduire considérablement la complexité à travers la simplification de la couche de consensus (finalité en 3 slots, agrégation STARK) et de la couche d'exécution (remplacement de l'EVM par RISC-V ou une machine virtuelle similaire), réduisant ainsi les coûts de développement, les risques d'erreur et la surface d'attaque. Il est suggéré d'effectuer une transition en douceur grâce à une stratégie de compatibilité ascendante (comme un interpréteur EVM en chaîne) et d'unifier le code 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 à se rapprocher de la simplicité de Bitcoin, d'améliorer la résilience et la participation, tout en accordant une importance culturelle à la simplicité et en établissant un objectif de nombre maximal de lignes de code.
L'objectif d'Ethereum est de devenir un grand livre mondial : une plateforme pour stocker les actifs et les enregistrements de la civilisation humaine, au service des domaines tels que la finance, la gouvernance et la certification des données de haute valeur. Cela nécessite un soutien dans deux domaines : l'évolutivité et la résilience. Le plan de hard fork Fusaka augmentera l'espace disponible pour les données L2 par 10, tandis que la feuille de route proposée pour 2026 prévoit également d'apporter une amélioration similaire pour la couche L1. Pendant ce temps, Ethereum a achevé sa transition vers la preuve d'enjeu (PoS), la diversité des clients a rapidement augmenté, la vérification par zéro connaissance (ZK) et la recherche sur la résistance quantique avancent également de manière constante, et l'écosystème applicatif devient de plus en plus robuste.
Cet article vise à se concentrer sur un élément tout aussi important mais souvent sous-estimé de la résilience (voire de l'évolutivité) : la simplicité du protocole.
Ce qui est le plus impressionnant dans le protocole Bitcoin, c'est sa simplicité élégante :
Il existe une chaîne composée de blocs, chaque bloc étant lié au bloc précédent par un hachage.
La validité d'un bloc est vérifiée par la preuve de travail (PoW), c'est-à-dire en vérifiant si les premiers chiffres du hachage sont des zéros.
Chaque bloc contient des transactions, les pièces dépensées provenant soit des récompenses de minage, soit des sorties de transactions précédentes.
C'est tout ! Même un lycéen intelligent peut comprendre parfaitement le fonctionnement du protocole Bitcoin, et un programmeur peut même en faire un projet amateur en écrivant un client.
La simplicité du protocole a apporté de nombreux avantages clés au Bitcoin (et à l'Ethereum) pour devenir une couche de base mondiale fiable et neutre :
1. Facile à comprendre : Réduire la complexité des protocoles, permettant à un plus grand nombre de personnes de participer à la recherche, au développement et à la gouvernance des protocoles, réduisant ainsi les risques liés à une domination par une élite technique.
2. Réduction des coûts de développement : Simplifier le protocole réduit considérablement le coût de création de nouvelles infrastructures (comme de nouveaux clients, des prouveurs, des outils pour développeurs, etc.).
3. Réduire la charge de maintenance : réduire le coût de la maintenance des contrats à long terme.
4. 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.
5. Réduire la surface d'attaque : réduire les composants complexes du protocole afin de diminuer le risque d'attaques par des groupes d'intérêts particuliers.
Dans l'histoire, Ethereum (parfois à cause de mes décisions personnelles) n'a souvent pas réussi à rester simple, ce qui a entraîné 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
Le nouveau design de la couche de consensus (historiquement appelée "chaîne de balise") vise à tirer parti des dix dernières années d'expérience en théorie du consensus, développement de ZK-SNARK, économie de staking, etc., pour construire une couche de consensus optimale à long terme et plus simple. Par rapport à la chaîne de balise existante, le nouveau design simplifie considérablement :
1. Conception finale à 3 emplacements : suppression des concepts de slot, d'epoch et de réorganisation du comité, ainsi que des mécanismes de traitement efficaces associés (comme les comités 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 proche de l'optimum.
2. Réduire le nombre de validateurs actifs : Permettre l'utilisation de règles de sélection de fork plus simples pour renforcer la sécurité.
3. Protocole d'agrégation basé sur STARK : Tout le monde peut devenir agrégateur, sans avoir à faire confiance à l'agrégateur ni à 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 le risque systémique.
4. 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.
5. Reconcevoir le mécanisme de validation : y compris les mécanismes d'entrée, de sortie, de retrait, de conversion de clé, de fuite d'inactivité, etc., simplifiant le nombre de lignes de code et fournissant des garanties plus claires (comme les périodes de faibles 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 une plus grande marge d'amélioration continue. Le plus grand défi réside dans la manière d'implémenter une simplification similaire au sein de la couche d'exécution.
Couche d'exécution simplifiée
La complexité de l'EVM augmente de plus en plus, et de nombreuses complexités se sont révélées inutiles (en partie à cause de mes erreurs de jugement personnelles) : les machines virtuelles de 256 bits ont excessivement optimisé des formes cryptographiques spécifiques qui sont désormais progressivement obsolètes, les précompilations (precompiles) étant optimisées pour un seul cas d'utilisation mais rarement utilisées.
Résoudre ces problèmes un par un a un effet limité. Par exemple, éliminer l'opcode SELFDESTRUCT nécessite un effort énorme, mais ne rapporte que peu de bénéfices. Les récents débats 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 obtenir un rendement de 1,5 fois, il vaudrait mieux passer à une machine virtuelle plus optimale et plus simple pour réaliser un rendement de 100 fois. À l'instar de « la fusion » (The Merge), nous réduisons le nombre de changements destructeurs, mais rendons chaque changement plus significatif. Plus précisément, je suggère de remplacer l'EVM par RISC-V, ou une autre machine virtuelle utilisée par le prouveur ZK d'Ethereum. Cela apporterait :
1. Amélioration significative de l'efficacité : L'exécution des contrats intelligents (dans le prouveur) se fait sans frais d'interpréteur, directement. Les données de Succinct montrent que dans de nombreux scénarios, les performances peuvent être améliorées de plus de 100 fois.
2. Amélioration significative de la simplicité : La spécification RISC-V est extrêmement simple par rapport à l'EVM, et les alternatives (comme Cairo) sont tout aussi concises.
3. Motivations pour le support d'EOC : telles que la partition du code, une analyse statique plus conviviale, des limites de taille de code plus grandes, etc.
4. Plus de choix pour les développeurs : Solidity et Vyper peuvent ajouter un backend pour compiler vers la nouvelle machine virtuelle. Si RISC-V est choisi, les développeurs de langages mainstream peuvent également facilement porter leur code vers cette machine virtuelle.
5. Suppression de la plupart des précompilés : il se peut qu'il ne reste que des opérations sur les courbes elliptiques hautement optimisées (même celles-ci disparaîtront avec la généralisation des ordinateurs quantiques).
Le principal inconvénient 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 (comme l'augmentation de la limite de taille du code des contrats, le support de DUP/SWAP17-32).
Cela apportera une machine virtuelle plus simple. Le principal défi est : comment traiter l'EVM existant ?
Stratégie de compatibilité ascendante pour la transition de machines virtuelles
Le plus grand défi pour simplifier (ou améliorer sans augmenter la complexité) l'EVM réside dans la manière 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 le code source 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, la preuve, la vérification, FOCIL (règles de sélection de fork) et la construction de blocs "normaux".
Zone orange non réductible : 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. Mais le nouveau client, ZK-EVM ou le vérificateur formel peuvent complètement ignorer la zone orange.
Nouvelle zone jaune : très précieuse 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 en 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 la complexité de l'encapsulation. Les personnes qui comprennent le protocole peuvent ignorer ces parties, Ethereum peut les négliger, et les erreurs dans ces zones ne déclencheront pas de risque de consensus. Par conséquent, la complexité du code des zones orange et jaune est beaucoup moins dangereuse 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 la couche de traduction Rosetta pour garantir une compatibilité à long terme.
Inspiré par l'article récent de l'équipe Ipsilon, je propose le processus de changement de machine virtuelle suivant (en prenant l'exemple de EVM à RISC-V, mais qui peut également être utilisé pour EVM à Cairo ou RISC-V à une machine virtuelle supérieure) :
1. Exiger une nouvelle précompilation fournissant une implémentation RISC-V en chaîne : permettre à l'écosystème de s'adapter progressivement à la machine virtuelle RISC-V.
2. Introduction de RISC-V comme option de développement : Le protocole prend en charge à la fois RISC-V et EVM, et les contrats des deux machines virtuelles peuvent interagir librement.
3. 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 s'il s'arrête ici, cela simplifie considérablement le protocole.
4. Mise en œuvre d'un interpréteur EVM dans RISC-V : En tant que contrat intelligent sur la chaîne (car le prouveur ZK doit être en place). Des années après la 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.
Simplification par des composants de protocole de partage
La troisième façon de réduire la complexité globale des protocoles (et la plus souvent sous-estimée) est de partager des normes unifiées autant que possible dans les différentes parties de la pile de protocoles. Différents protocoles faisant la même chose dans des contextes différents sont souvent inutiles, mais ce modèle apparaît encore fréquemment, principalement en raison d'un manque de communication entre les différentes parties de la feuille de route des protocoles. Voici quelques exemples concrets de simplification d'Ethereum par le partage de composants.
Code de correction unifié
Nous avons besoin de codes de correction dans trois scénarios :
1. Échantillonnage de la disponibilité des données : le client vérifie que le bloc a été publié.
2. Diffusion P2P plus rapide : Les nœuds peuvent accepter un bloc après avoir reçu n/2 segments, trouvant un équilibre entre retard et redondance.
3. Stockage historique distribué : Les données historiques d'Ethereum sont stockées en fragments, chaque groupe de n/2 fragments peut restaurer les fragments restants, réduisant ainsi le risque de perte d'un fragment unique.
Si le même code de correction d'erreur (qu'il s'agisse de Reed-Solomon, de codes linéaires aléatoires, etc.) est utilisé dans trois scénarios, les avantages suivants seront obtenus :
1. Minimiser la quantité de code : Réduire le nombre total de lignes de code.
2. Améliorer l'efficacité : Si le nœud télécharge des segments de données pour un certain scénario, ces données peuvent être utilisées pour d'autres scénarios.
3. Assurer la vérifiabilité : Tous les fragments des scénarios peuvent être vérifiés en fonction de la racine.
Si vous utilisez différents codes de correction d'erreurs, vous devez au moins garantir la compatibilité, par exemple, les codes Reed-Solomon pour l'échantillonnage de la disponibilité des données doivent fonctionner dans le même domaine que les codes linéaires aléatoires verticaux.
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. Une exception concerne le hachage de la signature des transactions, qui doit être haché dans un format standardisé. À l'avenir, le degré de solidité du format de sérialisation sera encore accru pour les raisons suivantes :
1. Abstraction complète des comptes (EIP-7701) : Le contenu complet de la transaction est visible pour la machine virtuelle.
2. 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'ABI des appels de 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é au niveau de consensus.
Très similaire à l'ABI existant : l'adaptation de l'outil est relativement simple.
Il y a déjà des efforts pour une migration complète vers SSZ, nous devons 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 en 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 fonction de hachage plus optimisée améliorera considérablement l'efficacité du prouveur tout en réduisant le coût des données dans des scénarios tels que les 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 de parser la couche d'exécution via le même code.
Du présent au futur
La simplicité ressemble à la décentralisation à bien des égards, les deux étant des objectifs de résilience en amont. Accorder une attention 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 d'apparence éblouissante est immédiat. Cependant, avec le temps, les bénéfices deviendront de plus en plus significatifs — — le Bitcoin en est un excellent exemple.
Je propose de suivre l'exemple de tinygrad en établissant 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. Parallèlement, 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 faire des choix de conception qui offrent des attributs et des garanties clairs.