Innovation de la couche d'exécution d'Ethereum : Perspectives et défis de l'architecture RISC-V

Le co-fondateur d'Ethereum a récemment proposé une initiative visionnaire au sein de la communauté : remplacer la machine virtuelle d'exécution (EVM) existante par une architecture d'instructions open source RISC-V. Cette idée a été comparée à la Beam Chain de la couche d'exécution, visant à surmonter les goulets d'étranglement de performance et à simplifier la logique des protocoles. En particulier en ce qui concerne l'efficacité des preuves à divulgation nulle de connaissance (ZK Proof), une augmentation de performance allant jusqu'à 100 fois est prévue. Cette proposition vise à résoudre les problèmes de goulets d'étranglement d'Ethereum en matière d'efficacité des preuves ZK, de complexité de construction de blocs et de disponibilité des données.

Limitations actuelles de l'EVM et avantages du RISC-V

Problème EVM :

• Architecture obsolète : une structure empilée de 256 bits incompatible avec les CPU modernes, affectant l'efficacité d'exécution de ZK-EVM.
• Goulot d'étranglement de la preuve ZK : Environ la moitié des ressources de ZK-EVM sont utilisées pour exécuter l'EVM lui-même, ce qui limite l'efficacité de la preuve.
• Mauvaise maintenabilité : l'accumulation de fonctionnalités entraîne une confusion des normes, rendant difficile l'abrogation de SELFDESTRUCT.
• Développement limité : l'ensemble d'instructions non standard limite le support inter-langues, rendant difficile la compilation efficace des langages populaires.

Les avantages de RISC-V :

• Performance efficace : jeu d'instructions simplifié, compatible avec le matériel, pouvant être utilisé pour l'optimisation JIT voire l'accélération matérielle.
• Optimisation ZK : génération directe de circuits pour les instructions RISC-V, simplifiant le processus de preuve ZK.
• Chaîne d'outils mature : prend en charge les langages principaux, réduit les barrières au développement, élargit l'écosystème.
• Norme universelle : des projets de blockchain existants l'ont adoptée, avec des cas de succès.

La proposition estime que l'adoption directe de RISC-V comme architecture d'exécution des contrats est plus susceptible d'améliorer fondamentalement l'efficacité d'exécution et le potentiel d'extension que de compiler l'EVM en RISC-V dans le ZK-EVM.

Remplacer les chemins et les défis

Trois solutions de remplacement :

1. Double VM coexistence (conservateur) : EVM et RISC-V fonctionnent en parallèle, 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 en tant qu'élément de protocole, permettant l'insertion future d'autres VM.

Défis techniques rencontrés lors de la mise en œuvre :

• Risque de dégradation des performances d'exécution : RISC-V doit être exécuté en simulation sur des puces x86, l'efficacité initiale peut être inférieure à celle de l'EVM optimisé.
• Reconstruction de la tarification du Gaz : il est nécessaire de définir un nouveau modèle de Gaz pour les instructions RISC-V.
• Conception de sandbox sécurisée : limitation des appels système, prévention de la modification autonome du code, garantie d'une exécution déterministe.
• Outils de développement adaptés : mise à jour des compilateurs, débogueurs, outils d'audit de sécurité, support du code binaire RISC-V.
• Compatibilité de migration : certains contrats dépendent des caractéristiques EVM, il est nécessaire de concevoir avec prudence une couche de compatibilité ou un mécanisme de retour.

La proposition tend à adopter la coexistence de deux VM comme chemin de transition, s'engageant à maintenir l'interopérabilité des anciens et nouveaux contrats, garantissant une expérience de développement inchangée et une mise à niveau sans impact pour les utilisateurs.

Impact sur les voies d'extension existantes

RISC-V est une optimisation de l'infrastructure, il ne remplacera pas les routes d'extensibilité existantes :

• Couche 2 : RISC-V améliore l'efficacité de traitement L1 et la performance de vérification ZK, ce qui aide Rollup à soumettre des données à un coût plus bas et plus rapidement.
• Sharding de données et EIP-4844 : le goulot d'étranglement de la disponibilité des données doit encore être résolu par les blobs et le Danksharding.
• FaaS, MEV : indépendants de l'architecture de la machine virtuelle, non affectés par les avancées de RISC-V.

RISC-V est le "moteur d'échange", L2/fragments sont le "réseau d'extension", les deux dimensions sont différentes et ne s'opposent pas en parallèle.

Retours de la communauté et essais connexes

Divergences communautaires :

• Partisans : pensent qu'il s'agit d'une mise à niveau nécessaire pour relever les défis de performance et qu'elle aide à attirer des développeurs traditionnels.
• Conservateurs : s'inquiètent des difficultés de mise en œuvre, du fardeau historique et du coût de mise à jour des outils écologiques, remettent en question le rapport coût-bénéfice.

Projets similaires de référence :

• Move VM (Aptos/Sui) : VM orienté ressources, avec une forte sécurité linguistique, mais non compatible avec EVM.
• FuelVM : conçu pour le traitement parallèle, associé au langage Sway, compatibilité limitée.
• WASM (Stylus) : Introduction de WASM comme langage de contrat sur L2, déjà implémenté sur une certaine plateforme.
• Un projet de blockchain : le réseau principal utilise RISC-V comme VM de contrat, fournissant une référence pratique pour Ethereum.

La proposition n'exclut pas d'autres options et considère que le mécanisme d'interpréteur à l'avenir pourrait être utilisé pour insérer des VM telles que Move, WASM, et construire un écosystème d'exécution diversifié.

Perspectives d'impact futur

Expérience développeur :

• Les langages comme Solidity/Vyper peuvent toujours être utilisés, il suffit de changer l'arrière-plan du compilateur.
• Il est possible d'ouvrir des contrats écrits dans de nouveaux langages tels que Rust/C, mais la migration n'est pas obligatoire.

Coûts d'exploitation et performance :

• L'amélioration de l'efficacité d'exécution apportera des limites de Gas plus élevées et des frais plus bas.
• Le contrat RISC-V pourrait réduire la dépendance aux contrats précompilés, et le modèle de Gas est 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, les nouveaux contrats adoptant progressivement RISC-V.
• L'infrastructure doit prendre en charge le nouveau format de bytecode, ce qui pourrait entraîner des changements de compatibilité entre les chaînes.

Sécurité et stabilité :

• La nouvelle architecture doit être largement testée et vérifiée formellement 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

Les développeurs principaux d'Ethereum ont proposé de remplacer l'EVM par RISC-V, ce qui reflète une réflexion approfondie sur les limites de performance futures et la simplicité du protocole. Cette proposition en est encore au stade précoce de discussion, et sa mise en œuvre devrait prendre plusieurs années, nécessitant de surmonter de nombreux défis techniques, communautaires et écologiques. Ce n'est pas un renversement de la trajectoire actuelle, mais plutôt un renforcement des bases et une préparation pour l'avenir.

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

C'est un pari sur l'avenir, mais aussi une exploration approfondie de "la question de savoir si les couches sous-jacentes valent la peine d'être reconstruites".