Le cofondateur d'Ethereum, Vitalik Buterin, a récemment proposé une proposition à long terme dans la communauté Ethereum Magicians : remplacer la machine virtuelle d'exécution actuelle (EVM) par une architecture de jeu d'instructions RISC-V open source. Il a comparé cette idée à la couche de consensus Beam Chain, estimant que c'est le seul chemin potentiel pour réaliser une percée de performance de la couche d'exécution et simplifier la logique du protocole. En particulier en ce qui concerne l'efficacité des preuves à connaissance nulle (ZK Proof), Vitalik s'attend à ce qu'en remplaçant l'EVM, une amélioration maximale de 100 fois puisse être réalisée. Cette proposition vise à résoudre les problèmes de goulet d'étranglement actuels d'Ethereum en matière d'efficacité des preuves ZK, de complexité de construction des blocs et de disponibilité des données.
Cet article expliquera en termes simples les motivations, les détails techniques, les voies de mise en œuvre et les défis de cette proposition, examinera son impact sur les routes d'extension existantes d'Ethereum, et passera en revue les réactions de la communauté ainsi que des tentatives similaires.
I. Les limites actuelles de l'EVM et les avantages du RISC-V
Problème de l'EVM :
Architecture obsolète : 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.
Bottleneck de ZK Proof : Comme l'indique Succinct, 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 ZK.
Mauvaise maintenance : accumulation de fonctions complexes au fil des ans, normes confuses, comme SELFDESTRUCT difficile à abolir.
Développement limité : les ensembles d'instructions non standards restreignent le support multilingue, rendant difficile la compilation efficace des langages courants en bytecode EVM.
Les avantages de RISC-V :
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.
Optimisation ZK : Générer des circuits directement à partir des instructions RISC-V dans la preuve ZK est plus simple que de prouver les opérations EVM.
Chaîne d'outils mature : prend en charge les langages principaux comme Rust/C/C++, abaissant le seuil de développement et élargissant l'écosystème.
Norme générale : déjà adoptée par des blockchains telles que Nervos CKB, avec des cas de succès.
Vitalik a souligné que, plutôt que de compiler l'EVM en RISC-V dans le ZK-EVM, il serait préférable d'utiliser directement RISC-V comme architecture d'exécution des contrats, ce qui améliorerait fondamentalement l'efficacité d'exécution et le potentiel d'extension.
Deux, chemins et défis de remplacement : comment migrer depuis l'EVM ?
Trois solutions de remplacement :
Double VM coexistence (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.
Solution d'interpréteur sur la chaîne (radicale) : tous les contrats EVM sont désormais interprétés et exécutés par des contrats RISC-V sur la chaîne.
Mécanisme de plugin d'interpréteur (compromis) : intégrer l'interpréteur comme élément de protocole, permettant d'insérer à l'avenir d'autres VM (comme Move).
Défis techniques liés à la mise en œuvre :
Risque de dégradation des performances d'exécution : RISC-V doit être simulé sur des puces x 86, ce qui peut entraîner une efficacité initiale inférieure à celle de l'EVM optimisé.
La tarification du gaz doit être reconstruite : il est nécessaire de définir un nouveau modèle de gaz pour les instructions RISC-V afin d'assurer l'équité et la sécurité.
Conception de bac à sable sécurisé : limiter les appels système, empêcher la modification automatique du code, garantir une exécution déterministe.
Outils de développement adaptés : mise à jour du compilateur, du débogueur et des outils d'audit de sécurité, supportant le bytecode RISC-V.
Problèmes de compatibilité de migration : certains contrats dépendent des caractéristiques de l'EVM, la migration doit être soigneusement conçue avec une couche de compatibilité ou un mécanisme de retour.
Vitalik privilégie la solution un comme voie de transition et s'engage à ce que les nouveaux et anciens contrats restent interopérables, garantissant ainsi une expérience constante pour les développeurs et une mise à niveau imperceptible pour les utilisateurs.
Trois, l'impact sur les solutions d'extension existantes : RISC-V remplacera-t-il L 2, le fragment de données, etc. ?
La réponse est négative : RISC-V est une optimisation de l'infrastructure et ne remplacera pas les voies d'extension existantes.
Layer 2 :
Rollup reste le principal moteur d'extension d'Ethereum, RISC-V améliore l'efficacité de traitement du L 1 et les performances de vérification ZK, et non pas l'extension directe du débit.
Une validation L1 plus rapide peut aider les Rollups à soumettre des données à un coût inférieur et plus rapidement, améliorant ainsi l'évolutivité globale.
Fractionnement 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é des données sur la chaîne.
Le changement de l'architecture n'affecte pas les besoins de stockage de données de L 1.
FaaS, MEV :
Indépendant de l'architecture de la machine virtuelle, il ne sera pas obsolète en raison de la promotion de RISC-V.
Résumé : RISC-V est un « moteur de remplacement », L 2/fragmentation est un « réseau d'expansion », les deux dimensions sont différentes et ne s'opposent pas.
Quatre, retours de la communauté et tentatives connexes
Divisions au sein de la communauté :
Partisans : pensent que c'est une mise à niveau stratégique nécessaire pour faire face aux défis de performance de Solana/Sui, ce qui aidera à attirer des développeurs traditionnels.
Conservateurs : s'inquiètent de la difficulté de mise en œuvre, du poids historique, des coûts élevés de mise à jour de la chaîne d'outils écologiques, et remettent en question le rapport coût-bénéfice des investissements en ressources.
Projets similaires de référence :
Move VM (Aptos/Sui) : une nouvelle machine virtuelle orientée ressources, avec une forte sécurité linguistique, mais non compatible avec l'EVM.
FuelVM : une nouvelle VM conçue pour le traitement parallèle, associée au langage Sway, avec une compatibilité limitée.
WASM (Stylus) : introduction de WASM comme langage de contrat dans L 2, désormais réalisé sur Arbitrum, avec une faisabilité pratique.
Nervos CKB : un précédent utilisant RISC-V comme VM de contrat sur le réseau principal, fournissant une référence pratique pour Ethereum.
Vitalik a proposé que RISC-V ne signifie pas le rejet d'autres options, il pense que les mécanismes d'interpréteur futurs pourraient également être utilisés pour intégrer des VM comme Move, WASM, etc., afin de construire un écosystème d'exécution diversifié.
Cinq, Perspectives d'impact futur : que se passerait-il si Ethereum passait à RISC-V
Expérience développeur :
Les langages tels que Solidity/Vyper peuvent toujours être utilisés, c'est l'arrière-plan du compilateur qui a changé et non le langage lui-même.
Il est possible d'ouvrir des contrats écrits dans de nouveaux langages comme Rust/C, 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.
Le contrat RISC-V pourrait 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, tandis que les nouveaux contrats adopteront 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 (comme les problèmes de présence ou d'absence de BSC et Polygon).
Sécurité et stabilité :
La nouvelle architecture nécessite des tests étendus 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
Vitalik a proposé de remplacer la machine virtuelle Ethereum (EVM) par RISC-V, ce qui représente 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 l'implémentation devrait être un processus s'étalant sur plusieurs années, nécessitant de surmonter des 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 en préparation de l'avenir.
Comme l'a dit Vitalik : "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 le "fondement mérite d'être remodelé".
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
La vision radicale de Vitalik : que signifie remplacer l'EVM d'Ethereum par RISC-V ?
Rédigé par : GaryMa Wu parle de Blockchain
Introduction
Le cofondateur d'Ethereum, Vitalik Buterin, a récemment proposé une proposition à long terme dans la communauté Ethereum Magicians : remplacer la machine virtuelle d'exécution actuelle (EVM) par une architecture de jeu d'instructions RISC-V open source. Il a comparé cette idée à la couche de consensus Beam Chain, estimant que c'est le seul chemin potentiel pour réaliser une percée de performance de la couche d'exécution et simplifier la logique du protocole. En particulier en ce qui concerne l'efficacité des preuves à connaissance nulle (ZK Proof), Vitalik s'attend à ce qu'en remplaçant l'EVM, une amélioration maximale de 100 fois puisse être réalisée. Cette proposition vise à résoudre les problèmes de goulet d'étranglement actuels d'Ethereum en matière d'efficacité des preuves ZK, de complexité de construction des blocs et de disponibilité des données.
Cet article expliquera en termes simples les motivations, les détails techniques, les voies de mise en œuvre et les défis de cette proposition, examinera son impact sur les routes d'extension existantes d'Ethereum, et passera en revue les réactions de la communauté ainsi que des tentatives similaires.
I. Les limites actuelles de l'EVM et les avantages du RISC-V
Problème de l'EVM :
Architecture obsolète : 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.
Bottleneck de ZK Proof : Comme l'indique Succinct, 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 ZK.
Mauvaise maintenance : accumulation de fonctions complexes au fil des ans, normes confuses, comme SELFDESTRUCT difficile à abolir.
Développement limité : les ensembles d'instructions non standards restreignent le support multilingue, rendant difficile la compilation efficace des langages courants en bytecode EVM.
Les avantages de RISC-V :
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.
Optimisation ZK : Générer des circuits directement à partir des instructions RISC-V dans la preuve ZK est plus simple que de prouver les opérations EVM.
Chaîne d'outils mature : prend en charge les langages principaux comme Rust/C/C++, abaissant le seuil de développement et élargissant l'écosystème.
Norme générale : déjà adoptée par des blockchains telles que Nervos CKB, avec des cas de succès.
Vitalik a souligné que, plutôt que de compiler l'EVM en RISC-V dans le ZK-EVM, il serait préférable d'utiliser directement RISC-V comme architecture d'exécution des contrats, ce qui améliorerait fondamentalement l'efficacité d'exécution et le potentiel d'extension.
Deux, chemins et défis de remplacement : comment migrer depuis l'EVM ?
Trois solutions de remplacement :
Double VM coexistence (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.
Solution d'interpréteur sur la chaîne (radicale) : tous les contrats EVM sont désormais interprétés et exécutés par des contrats RISC-V sur la chaîne.
Mécanisme de plugin d'interpréteur (compromis) : intégrer l'interpréteur comme élément de protocole, permettant d'insérer à l'avenir d'autres VM (comme Move).
Défis techniques liés à la mise en œuvre :
Risque de dégradation des performances d'exécution : RISC-V doit être simulé sur des puces x 86, ce qui peut entraîner une efficacité initiale inférieure à celle de l'EVM optimisé.
La tarification du gaz doit être reconstruite : il est nécessaire de définir un nouveau modèle de gaz pour les instructions RISC-V afin d'assurer l'équité et la sécurité.
Conception de bac à sable sécurisé : limiter les appels système, empêcher la modification automatique du code, garantir une exécution déterministe.
Outils de développement adaptés : mise à jour du compilateur, du débogueur et des outils d'audit de sécurité, supportant le bytecode RISC-V.
Problèmes de compatibilité de migration : certains contrats dépendent des caractéristiques de l'EVM, la migration doit être soigneusement conçue avec une couche de compatibilité ou un mécanisme de retour.
Vitalik privilégie la solution un comme voie de transition et s'engage à ce que les nouveaux et anciens contrats restent interopérables, garantissant ainsi une expérience constante pour les développeurs et une mise à niveau imperceptible pour les utilisateurs.
Trois, l'impact sur les solutions d'extension existantes : RISC-V remplacera-t-il L 2, le fragment de données, etc. ?
La réponse est négative : RISC-V est une optimisation de l'infrastructure et ne remplacera pas les voies d'extension existantes.
Layer 2 :
Rollup reste le principal moteur d'extension d'Ethereum, RISC-V améliore l'efficacité de traitement du L 1 et les performances de vérification ZK, et non pas l'extension directe du débit.
Une validation L1 plus rapide peut aider les Rollups à soumettre des données à un coût inférieur et plus rapidement, améliorant ainsi l'évolutivité globale.
Fractionnement 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é des données sur la chaîne.
Le changement de l'architecture n'affecte pas les besoins de stockage de données de L 1.
FaaS, MEV :
Indépendant de l'architecture de la machine virtuelle, il ne sera pas obsolète en raison de la promotion de RISC-V.
Résumé : RISC-V est un « moteur de remplacement », L 2/fragmentation est un « réseau d'expansion », les deux dimensions sont différentes et ne s'opposent pas.
Quatre, retours de la communauté et tentatives connexes
Divisions au sein de la communauté :
Partisans : pensent que c'est une mise à niveau stratégique nécessaire pour faire face aux défis de performance de Solana/Sui, ce qui aidera à attirer des développeurs traditionnels.
Conservateurs : s'inquiètent de la difficulté de mise en œuvre, du poids historique, des coûts élevés de mise à jour de la chaîne d'outils écologiques, et remettent en question le rapport coût-bénéfice des investissements en ressources.
Projets similaires de référence :
Move VM (Aptos/Sui) : une nouvelle machine virtuelle orientée ressources, avec une forte sécurité linguistique, mais non compatible avec l'EVM.
FuelVM : une nouvelle VM conçue pour le traitement parallèle, associée au langage Sway, avec une compatibilité limitée.
WASM (Stylus) : introduction de WASM comme langage de contrat dans L 2, désormais réalisé sur Arbitrum, avec une faisabilité pratique.
Nervos CKB : un précédent utilisant RISC-V comme VM de contrat sur le réseau principal, fournissant une référence pratique pour Ethereum.
Vitalik a proposé que RISC-V ne signifie pas le rejet d'autres options, il pense que les mécanismes d'interpréteur futurs pourraient également être utilisés pour intégrer des VM comme Move, WASM, etc., afin de construire un écosystème d'exécution diversifié.
Cinq, Perspectives d'impact futur : que se passerait-il si Ethereum passait à RISC-V
Expérience développeur :
Les langages tels que Solidity/Vyper peuvent toujours être utilisés, c'est l'arrière-plan du compilateur qui a changé et non le langage lui-même.
Il est possible d'ouvrir des contrats écrits dans de nouveaux langages comme Rust/C, 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.
Le contrat RISC-V pourrait 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, tandis que les nouveaux contrats adopteront 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 (comme les problèmes de présence ou d'absence de BSC et Polygon).
Sécurité et stabilité :
La nouvelle architecture nécessite des tests étendus 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
Vitalik a proposé de remplacer la machine virtuelle Ethereum (EVM) par RISC-V, ce qui représente 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 l'implémentation devrait être un processus s'étalant sur plusieurs années, nécessitant de surmonter des 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 en préparation de l'avenir.
Comme l'a dit Vitalik : "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 le "fondement mérite d'être remodelé".