Ethereum pourrait adopter l'architecture RISC-V en remplacement de l'EVM

Le co-fondateur d'Ethereum a récemment proposé une proposition à long terme sur le forum de la communauté, suggérant de remplacer la machine virtuelle d'exécution actuelle (EVM) par une architecture de jeu d'instructions open source RISC-V. Il a fait une analogie entre cette idée et la chaîne Beam au niveau de consensus, estimant que cela pourrait être le seul chemin viable pour réaliser des percées de performance au niveau d'exécution et simplifier la logique des protocoles. En particulier en ce qui concerne l'efficacité des preuves à connaissance nulle (ZK Proof), il est prévu qu'en remplaçant l'EVM, une optimisation pouvant atteindre jusqu'à 100 fois puisse être réalisée. Cette proposition vise à résoudre les problèmes de goulot d'étranglement d'Ethereum actuels en matière d'efficacité des preuves ZK, de complexité de construction de blocs, de disponibilité des données, etc.

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

Les principaux problèmes liés à l'EVM incluent :

1. Architecture obsolète : utilisation d'une structure à 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 est utilisée pour exécuter l'EVM lui-même, ce qui limite l'efficacité des preuves ZK.
3. Mauvaise maintenabilité : l'accumulation de fonctionnalités sur plusieurs années a entraîné un désordre dans les normes, rendant certaines fonctionnalités difficiles à supprimer.
4. Développement limité : un ensemble d'instructions non standard limite le support interlangue, rendant difficile la compilation efficace des langages de programmation courants en bytecode EVM.

En comparaison, RISC-V présente les avantages suivants :

1. Haute performance : en tant que jeu d'instructions simplifié d'un véritable CPU, 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érer directement des circuits pour les instructions RISC-V dans la preuve ZK est plus simple que de prouver les opérations EVM.
3. Chaîne d'outils mature : prend en charge des langages populaires tels que Rust/C/C++, réduisant ainsi le seuil de développement et élargissant l'écosystème.
4. Normes générales : des projets blockchain existants ont été adoptés, avec des cas de succès.

Chemins de remplacement et défis

Trois solutions de remplacement possibles ont été proposées :

1. Double VM coexistence (la plus conservatrice) : EVM et RISC-V fonctionnent en parallèle, les nouveaux contrats peuvent opter pour 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 désormais 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 d'insérer d'autres VM à l'avenir.

Les défis techniques auxquels nous sommes confrontés lors de la mise en œuvre incluent :

• Risque de dégradation des performances d'exécution : RISC-V doit être exécuté en mode simulation sur des puces x86, l'efficacité initiale peut être inférieure à celle de l'EVM optimisé.
• 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é.
• Conception de sandbox sécurisée : limiter les appels système, empêcher la modification autonome du code, garantir une exécution déterministe.
• Outils de développement adaptés : mise à jour nécessaire du compilateur, du débogueur et des outils d'audit de sécurité, prise en charge du bytecode RISC-V.
• Problèmes de compatibilité de migration : certains contrats dépendent des caractéristiques de l'EVM, la migration doit être conçue avec soin pour inclure une couche de compatibilité ou un mécanisme de retour.

Impact sur les itinéraires d'extension existants

RISC-V est une optimisation de l'infrastructure, il ne remplacera pas les voies d'extension existantes.

• Couche 2 : Rollup reste le principal moteur d'extension d'Ethereum, RISC-V améliore l'efficacité de traitement du L1 et les performances de vérification ZK, et non directement l'extension du débit.
• Sharding des données et EIP-4844 : le goulot d'étranglement de la disponibilité des données doit encore être résolu par l'EIP-4844 et le Danksharding, RISC-V n'affecte pas la capacité des données sur la chaîne.
• FaaS, MEV : indépendants de l'architecture des machines virtuelles, ne deviendront pas obsolètes en raison de l'avancement de RISC-V.

Retours de la communauté et tentatives connexes

La communauté est divisée sur cette proposition :

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

Projets similaires de référence :

• Move VM (Aptos/Sui) : nouvelle VM orientée ressources, avec une forte sécurité du langage, mais non compatible avec l'EVM.
• FuelVM : une nouvelle VM conçue pour le traitement parallèle, accompagnée du langage Sway, avec une compatibilité limitée.
• WASM (Stylus) : introduction de WASM comme langage de contrat dans L2, déjà implémenté dans un certain L2, avec une faisabilité réelle.
• Une blockchain publique : un précédent utilisant RISC-V comme machine virtuelle de contrat sur le réseau principal, fournissant une référence pratique pour Ethereum.

Perspectives d'impact futur

Si Ethereum passe à RISC-V, cela pourrait avoir les impacts suivants :

1. Expérience développeur :

   • Les langages tels que Solidity/Vyper peuvent toujours être utilisés, le backend du compilateur change plutôt que 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.

2. Coûts d'exploitation et performance :

   • L'amélioration de l'efficacité d'exécution entraînera 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, et le modèle de Gas est plus proche du coût des preuves ZK.

3. Compatibilité et développement écologiques :

   • 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 un nouveau format de bytecode, ce qui pourrait entraîner des changements de compatibilité entre chaînes.

4. 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 facilite l'audit et le contrôle de la surface d'attaque.

Cette proposition représente une réflexion approfondie d'Ethereum sur les limites de performance futures et la simplicité du protocole. La mise en œuvre devrait être un processus de plusieurs années, nécessitant de surmonter de nombreux défis techniques, communautaires et écologiques. Ce n'est pas une remise en question de la feuille de route actuelle, mais plutôt un renforcement des bases et une préparation pour l'avenir. Cela peut être considéré comme un pari sur l'avenir, ainsi qu'une exploration approfondie de "la valeur de la refonte de la base".