Ethereum pourrait remplacer l'EVM par l'architecture RISC-V, la technologie ZK pourrait connaître un développement révolutionnaire

Le cofondateur d'Ethereum a récemment proposé une proposition à long terme, suggérant de remplacer la machine virtuelle d'exécution actuelle (EVM) par l'architecture de jeu d'instructions open source RISC-V. Cette idée a été comparée à Beam Chain au niveau de la couche de consensus, considérée comme le seul moyen potentiel d'atteindre une percée de performance au niveau de la couche d'exécution et de simplifier la logique des protocoles. En particulier en ce qui concerne l'efficacité des preuves à divulgation nulle de connaissance (ZK Proof), il est prévu qu'en remplaçant l'EVM, une optimisation pouvant atteindre jusqu'à 100 fois pourrait être réalisée. Cette proposition vise à résoudre les problèmes de goulet d'étranglement actuels d'Ethereum en termes d'efficacité des preuves ZK, de complexité de construction de blocs et de disponibilité des données.

Les limites de l'EVM et les avantages du RISC-V

Les défis auxquels est confronté l'EVM

1. Architecture obsolète : l'EVM utilise une structure de pile de 256 bits, incompatible avec les CPU modernes, ce qui entraîne une faible efficacité d'exécution du ZK-EVM.
2. Goulot d'étranglement des preuves ZK : Environ la moitié des ressources de ZK-EVM est utilisée pour exécuter l'EVM lui-même, ce qui limite l'efficacité des preuves ZK.
3. Difficultés de maintenance : L'accumulation de fonctionnalités au fil des ans a entraîné un désordre dans les normes, ce qui rend certaines fonctionnalités difficiles à éliminer.
4. Développement limité : un ensemble d'instructions non standard limite le support interlangue, rendant difficile la compilation efficace des langages principaux en bytecode EVM.

Les avantages de RISC-V

1. Performance élevée : RISC-V est un ensemble d'instructions réduit pour CPU réels, convivial pour le matériel, pouvant être utilisé pour l'optimisation JIT et même l'accélération matérielle.
2. Optimisation ZK : Génération de circuits pour les instructions RISC-V directement dans la preuve ZK, ce qui est plus simple que de prouver les opérations EVM.
3. Chaîne d'outils mature : supporte des langages populaires tels que Rust/C/C++, réduisant le seuil de développement et élargissant l'écosystème.
4. Norme générale : des projets de blockchain existants l'ont adopté et en ont des exemples de réussite.

Le co-fondateur d'Ethereum a souligné qu'il serait préférable d'utiliser RISC-V comme architecture d'exécution des contrats plutôt que de compiler l'EVM en RISC-V dans le ZK-EVM, afin d'améliorer fondamentalement l'efficacité d'exécution et le potentiel d'évolutivité.

Chemins et défis de remplacement

trois solutions de remplacement

1. Double VM coexistence (la plus conservatrice) : EVM et RISC-V fonctionnent en parallèle, les nouveaux contrats peuvent choisir RISC-V, garantissant la compatibilité pendant la période de transition.
2. Solution d'interpréteur en chaîne (radicale) : tous les contrats EVM sont interprétés et exécutés par des contrats RISC-V en chaîne.
3. Mécanisme de plugin d'interpréteur (compromis) : intégrer l'interpréteur comme élément de protocole, permettant l'insertion future d'autres VM (comme Move).

défis techniques auxquels la mise en œuvre est confrontée

1. Risque de dégradation des performances d'exécution : RISC-V doit être simulé sur des puces x86, ce qui peut entraîner une efficacité initiale inférieure à celle de l'EVM optimisé.
2. La tarification du Gas doit être reconstruite : il est nécessaire de définir un nouveau modèle de Gas pour les instructions RISC-V afin d'assurer l'équité et la sécurité.
3. Conception de bac à sable sécurisé : limiter les appels système, empêcher l'auto-modification du code, garantir une exécution déterministe.
4. Adaptation des outils de développement : nécessite une mise à jour du compilateur, du débogueur et des outils d'audit de sécurité, supportant le code binaire RISC-V.
5. Problèmes de compatibilité des migrations : certains contrats dépendent des caractéristiques de l'EVM, la migration nécessite une conception prudente d'une couche de compatibilité ou d'un mécanisme de retour.

Le cofondateur d'Ethereum privilégie une solution de coexistence de double VM comme chemin de transition et s'engage à ce que les contrats anciens et nouveaux restent interopérables, garantissant une expérience de développement inchangée et une mise à niveau transparente pour les utilisateurs.

Impact sur les stratégies d'extension existantes

RISC-V ne remplacera pas les routes d'extension existantes, mais agira en tant qu'optimisation de l'infrastructure.

Couche 2

• Rollup reste le principal moteur d'extension d'Ethereum, le RISC-V améliore l'efficacité de traitement du L1 et les performances de vérification ZK, et non l'extension directe du débit.
• Une validation L1 plus rapide peut aider les Rollups à soumettre des données à un coût plus bas et plus rapidement, améliorant ainsi l'évolutivité globale.

Partitionnement des données et EIP-4844

• Les goulets d'étranglement de la disponibilité des données doivent encore être résolus par EIP-4844 (blob) et Danksharding, RISC-V n'affecte pas la capacité des données on-chain.
• Les modifications de l'architecture d'exécution ne changent pas les besoins en stockage de données de L1.

FaaS, MEV

• Indépendant de l'architecture de la machine virtuelle, il ne sera pas obsolète en raison de l'avancement de RISC-V.

Dans l'ensemble, RISC-V est le "moteur d'échange", L2/partition est le "réseau d'expansion", les deux dimensions étant différentes, mais parallèles et non contradictoires.

Retours de la communauté et essais connexes

divergences au sein de la communauté

• Les partisans estiment qu'il s'agit d'une mise à niveau stratégique nécessaire pour relever les défis de performance et d'attirer les développeurs traditionnels.
• Les conservateurs s'inquiètent de la difficulté de mise en œuvre, du poids de l'histoire et des coûts de mise à jour de la chaîne d'outils écologiques, remettant en question le rapport coût-bénéfice des ressources investies.

référence de projets similaires

1. Move VM : VM orienté ressources entièrement nouveau, avec une forte sécurité linguistique, mais non compatible avec EVM.
2. FuelVM : une nouvelle VM conçue pour le traitement parallèle, associée au langage Sway, avec une compatibilité limitée.
3. WASM : Introduction de WASM comme langage de contrat dans L2, déjà mis en œuvre sur certaines plateformes L2, avec une faisabilité réelle.
4. Une blockchain publique : L'utilisation de RISC-V comme VM de contrat sur le réseau principal sert de référence pratique pour Ethereum.

Le co-fondateur d'Ethereum a déclaré que le fait de proposer RISC-V ne signifie pas qu'il rejette d'autres options. Il considère que les mécanismes d'interprétation futurs pourraient également être utilisés pour intégrer des VM telles que Move, WASM, afin de construire un écosystème d'exécution multiple.

Perspectives d'impact futur

expérience développeur

• Des langages comme Solidity/Vyper peuvent toujours être utilisés, le backend du compilateur change et non le langage lui-même.
• Il est possible d'ouvrir de nouveaux langages comme Rust/C pour écrire des contrats, mais la migration n'est pas obligatoire.

Coût d'exploitation et performance

• L'amélioration de l'efficacité d'exécution apportera un plafond de Gas plus élevé et des frais plus bas.
• Les contrats RISC-V pourraient réduire la dépendance aux contrats précompilés, le modèle de Gas étant plus proche du coût des preuves ZK.

Compatibilité écologique et développement

• Les contrats existants peuvent continuer à fonctionner pendant la période de coexistence des deux VM, et les nouveaux contrats adopteront progressivement RISC-V.
• L'infrastructure doit prendre en charge le nouveau format de bytecode, ce qui pourrait entraîner des variations de compatibilité entre les chaînes.

Sécurité et stabilité

• La nouvelle architecture nécessite des tests approfondis et une vérification formelle pour améliorer la fiabilité du protocole.
• Une couche d'exécution plus simple favorise l'audit et le contrôle de la surface d'attaque.

Conclusion

Le cofondateur d'Ethereum propose de remplacer l'EVM par RISC-V, reflétant une réflexion approfondie sur les limites de performance futures et la simplicité des protocoles. Cette proposition est encore à un stade précoce de discussion et sa mise en œuvre devrait être un processus de plusieurs années, nécessitant de surmonter de multiples défis techniques, communautaires et écologiques. Ce n'est pas une remise en question de la trajectoire actuelle, mais plutôt un renforcement des bases en vue de l'avenir.

Comme il l'a dit : "Pour réaliser une amélioration d'un ordre de grandeur, ce changement radical peut être le seul chemin viable."

Cela peut être considéré comme un pari sur l'avenir, ainsi qu'une exploration approfondie de la question de savoir si "la couche sous-jacente vaut la peine d'être remodelée".