RISC-V pourrait devenir une alternative future à l'Ethereum Virtual Machine

Récemment, l'un des cofondateurs d'Ethereum a proposé une proposition à long terme, suggérant de remplacer la machine virtuelle d'exécution actuelle (EVM) par une architecture d'ensemble d'instructions RISC-V open source. Cette idée a été comparée à Beam Chain au niveau de la couche de consensus, et est considérée comme le seul chemin potentiel pour réaliser une percée dans les performances de la couche d'exécution et simplifier la logique des protocoles. En particulier en ce qui concerne l'efficacité de la preuve à divulgation nulle de connaissance (ZK Proof), il est prévu qu'en remplaçant l'EVM, une optimisation maximale de 100 fois pourrait être réalisée. Cette proposition vise à répondre aux problèmes de goulet d'étranglement actuels d'Ethereum en matière d'efficacité des preuves ZK, de complexité de construction des blocs, de disponibilité des données, etc.

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

Problème de la Machine virtuelle :

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é lors de l'exécution de ZK-EVM.
2. Goulot d'étranglement des preuves ZK : environ la moitié des ressources sont utilisées pour exécuter la Machine virtuelle, ce qui limite l'efficacité des preuves ZK.
3. Faible maintenabilité : accumulation de fonctions complexes au fil des ans, normes confuses, certaines fonctions difficiles à abolir.
4. Développement limité : l'ensemble d'instructions non standard limite le support inter-langues, rendant difficile la compilation efficace des langages mainstream en bytecode EVM.

Les avantages de RISC-V :

1. Performance élevée : RISC-V est un ensemble d'instructions réduit pour les véritables 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 mainstream tels que Rust/C/C++, ce qui abaisse le seuil de développement et élargit l'écosystème.
4. Normes générales : Certains projets de blockchain ont déjà adopté ces normes et disposent de cas de succès.

Le cofondateur d'Ethereum a souligné qu'il valait mieux utiliser RISC-V comme architecture d'exécution des contrats plutôt que de compiler l'EVM en RISC-V dans le ZK-EVM, ce qui améliorerait fondamentalement l'efficacité d'exécution et le potentiel d'extension.

Remplacer les chemins et les défis

Trois solutions de remplacement :

1. Double VM cohabitation (la plus conservatrice) : EVM et RISC-V fonctionnent en parallèle, les nouveaux contrats peuvent choisir RISC-V, garantissant la compatibilité durant 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 Machines virtuelles.

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

1. Risque de dégradation des performances d'exécution : RISC-V doit être exécuté en simulation sur des puces x86, ce qui peut entraîner une efficacité initiale inférieure à celle d'une EVM optimisée.
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 la sandbox de sécurité : Limiter les appels système, prévenir la modification automatique du code, garantir l'exécution déterministe.
4. Adaptation des outils de développement : mise à jour des compilateurs, débogueurs et outils d'audit de sécurité, prise en charge du code byte RISC-V.
5. Problèmes de compatibilité de migration : certains contrats dépendent des caractéristiques de l'EVM, une conception prudente d'une couche de compatibilité ou d'un mécanisme de retour en arrière est nécessaire lors de la migration.

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

Impact sur les voies d'extension existantes

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

Couche 2 :

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

Fragmentation 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 (blob) et le Danksharding, RISC-V n'affecte pas la capacité de données sur la chaîne.
• Les changements dans l'architecture d'exécution n'affectent pas les exigences de stockage de données de L1.

FaaS, MEV :

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

Résumé : RISC-V est le "moteur de changement", L2/fragmentation est le "réseau d'expansion", les deux dimensions sont différentes et parallèles sans contradiction.

Retours de la communauté et tentatives connexes

Divergence communautaire :

• Partisans : Estiment qu'il s'agit d'une mise à niveau stratégique nécessaire pour faire face aux défis d'autres blockchains haute performance et qu'elle aide à attirer des développeurs traditionnels.
• Conservateurs : s'inquiètent de la difficulté de mise en œuvre, du poids historique, des coûts de mise à jour de la chaîne d'outils écologiques, et remettent en question le ratio coût-bénéfice des ressources.

Projets similaires de référence :

• Move VM : Machine virtuelle entièrement nouvelle orientée ressources, avec une forte sécurité linguistique, mais non compatible avec EVM.
• FuelVM : une nouvelle machine virtuelle 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.
• Un projet de blockchain : 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.

Le cofondateur d'Ethereum a proposé que le RISC-V ne signifie pas le rejet d'autres options, il estime que les futurs mécanismes d'interpréteur pourraient également être utilisés pour intégrer des VM telles que Move, WASM, afin de 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, le backend du compilateur change mais pas 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ûts d'exploitation et performances :

• L'amélioration de l'efficacité d'exécution entraînera des limites de Gas plus élevées 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 machines virtuelles, 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 est favorable à l'audit et au contrôle de la surface d'attaque.

Conclusion

Le cofondateur d'Ethereum propose de remplacer l'EVM d'Ethereum par RISC-V, représentant une réflexion approfondie d'Ethereum sur les limites de performance futures et la simplicité du protocole. Cette proposition est encore au stade précoce de discussion, et sa mise en œuvre devrait prendre 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 et une préparation pour l'avenir.

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

Nous pouvons le considérer comme un pari sur l'avenir, ainsi qu'une exploration approfondie de "la question de savoir si la base mérite d'être remodelée".