Le chemin de l'innovation d'Ethereum : Exploration de la possibilité de RISC-V comme alternative à l'EVM

Le co-fondateur d'Ethereum a récemment proposé dans la communauté un plan à long terme : remplacer la machine virtuelle d'exécution (EVM) existante par une architecture d'instructions RISC-V open source. Cette proposition a été comparée à la Beam Chain du niveau de consensus et est considérée comme le seul moyen potentiel de surmonter les goulets d'étranglement de performance du niveau d'exécution et de simplifier la logique des protocoles. En particulier en ce qui concerne l'efficacité des preuves à connaissance nulle (ZK Proof), on s'attend à ce qu'en remplaçant l'EVM, une optimisation allant jusqu'à 100 fois puisse être réalisée. Cette proposition vise à répondre aux problèmes de goulets d'étranglement d'Ethereum actuels en matière d'efficacité des preuves ZK, de complexité de construction des blocs, de disponibilité des données, etc.

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

Les défis auxquels est confronté l'EVM :

1. Architecture obsolète : la structure en pile de 256 bits n'est pas compatible avec les CPU modernes, ce qui entraîne une faible efficacité d'exécution du ZK-EVM.
2. Bouchon de preuve ZK : une grande quantité de ressources est utilisée pour exécuter l'EVM lui-même, ce qui limite l'efficacité des preuves ZK.
3. Difficulté de maintenance : L'accumulation des fonctionnalités au fil des ans a entraîné une confusion des normes, rendant certaines fonctions difficiles à supprimer.
4. Développement limité : un ensemble d'instructions non standard limite le support multilingue, rendant difficile la compilation efficace des langages mainstream en code binaire EVM.

Les avantages de RISC-V :

1. Performances efficaces : en tant qu'ensemble d'instructions réduit de processeur réel, convivial pour le matériel, prenant en charge l'optimisation JIT voire l'accélération matérielle.
2. Optimisation ZK : génération directe du circuit d'instructions RISC-V, simplifiant le processus de preuve ZK.
3. Outils matures : support des langages principaux tels que Rust/C/C++, réduisant les barrières au développement et élargissant l'écosystème.
4. Normes générales : des projets blockchain existants ont été adoptés avec succès, disposant de cas pratiques.

Deux, chemins de remplacement et défis

Plan de remplacement :

1. Double VM coexistence : 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. Interpréteur en chaîne : tous les contrats EVM sont interprétés et exécutés via des contrats RISC-V en chaîne.
3. Mécanisme de plugin d'interpréteur : utiliser l'interpréteur comme élément de protocole pour réserver de l'espace pour l'introduction de futures VM.

Défis techniques :

1. Performance d'exécution : RISC-V doit être exécuté par simulation sur des puces x86, l'efficacité initiale peut être inférieure à celle de l'EVM optimisé.
2. Refonte de la tarification du Gas : il est nécessaire de définir un nouveau modèle de Gas pour les instructions RISC-V, afin d'assurer équité et sécurité.
3. Sandbox de sécurité : limiter les appels système, empêcher la modification du code par lui-même, garantir une exécution déterministe.
4. Adaptation des outils de développement : mise à jour des compilateurs, des débogueurs et des outils d'audit de sécurité, prise en charge du code byte RISC-V.
5. Compatibilité de migration : certains contrats dépendent des caractéristiques de l'EVM, il est donc nécessaire de concevoir avec précaution une couche de compatibilité ou un mécanisme de retour.

Trois, impact sur les voies d'extension existantes

RISC-V ne remplacera pas les solutions d'extension existantes, mais servira d'optimisation d'infrastructure :

1. Couche 2 : RISC-V améliore l'efficacité de traitement L1 et les performances de vérification ZK, ce qui aide Rollup à soumettre des données à un coût plus bas et plus rapidement.
2. 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, RISC-V n'affecte pas directement la capacité des données sur la chaîne.
3. FaaS, MEV : ces fonctionnalités ne sont pas liées à l'architecture de la machine virtuelle et ne deviendront pas obsolètes en raison de l'avancement du RISC-V.

Quatre, retours de la communauté et tentatives connexes

Divergences communautaires :

• Les partisans estiment qu'il s'agit d'une mise à niveau nécessaire pour relever les défis des blockchains à haute performance, ce qui aidera à attirer des développeurs traditionnels.
• Les conservateurs s'inquiètent de la difficulté de mise en œuvre, du lourd héritage historique et des coûts élevés de mise à jour de la chaîne d'outils écologiques.

Projets similaires de référence :

1. Move VM (Aptos/Sui) : VM orienté ressources entièrement nouveau, avec une forte sécurité linguistique, mais non compatible avec l'EVM.
2. FuelVM : une nouvelle VM conçue pour le traitement parallèle, accompagnée du langage Sway, avec une compatibilité limitée.
3. WASM (Stylus) : Introduction de WASM en tant que langage de contrat dans L2, déjà implémenté sur certaines plateformes L2.
4. Un projet blockchain : un précédent utilisant RISC-V comme VM de contrat sur le mainnet, fournissant une référence pratique pour Ethereum.

Cinq, Perspectives d'impact futur

Si Ethereum passe à RISC-V :

1. Expérience développeur :

   • Les langages comme Solidity/Vyper peuvent toujours être utilisés, seul l'arrière-plan du compilateur a changé.
   • Il est possible d'ouvrir la rédaction de contrats en Rust/C et d'autres nouveaux langages, 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 une limite de Gas plus élevée 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 de preuve ZK.

3. Compatibilité écologique et développement :

   • Les contrats existants peuvent continuer à fonctionner pendant la période de coexistence des doubles VM, tandis que les nouveaux contrats adoptent 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.

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.

Conclusion

La proposition de remplacer l'EVM par RISC-V représente une réflexion approfondie d'Ethereum sur les limites de performance futures et la simplicité du protocole. Cette proposition en est encore à un 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 un renversement de la feuille de route existante, mais un renforcement des bases, en préparation pour l'avenir.

Cette proposition peut être considérée 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". Comme l'a dit le cofondateur d'Ethereum : "Pour réaliser un ordre de grandeur d'amélioration, ce changement radical pourrait être le seul chemin viable."