Le co-fondateur d'Ethereum, Vitalik Buterin, a récemment proposé une initiative à long terme au sein de la communauté Ethereum Magicians : remplacer la machine virtuelle actuelle d'exécution (EVM) par une architecture d'ensemble d'instructions open source RISC-V. Il a comparé cette conception à la Beam Chain de la couche de consensus, estimant que cela représente le seul chemin potentiel vers une percée des performances de la couche d'exécution et une simplification de la logique du protocole. En particulier en ce qui concerne l'efficacité des preuves à divulgation nulle de connaissance (ZK Proof), Vitalik prévoit qu'en remplaçant l'EVM, une optimisation pouvant atteindre 100 fois pourrait être réalisée. Cette proposition vise à répondre aux problèmes de goulot 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 analysera, en termes simples, les motivations, les détails techniques, les voies d'implémentation et les défis de cette proposition, explorant son impact sur les routes d'extension existantes d'Ethereum, tout en passant en revue les réactions de la communauté et les tentatives similaires.
Une, les limites actuelles de l'EVM et les avantages du RISC-V
Problèmes 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 la preuve ZK : 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.
Maintenance faible : accumulation de fonctionnalités complexes au fil des ans, normes confuses, comme SELFDESTRUCT difficile à abolir.
Développement limité : les ensembles d'instructions non standards restreignent le support interlangue, rendant difficile la compilation efficace des langages mainstream en bytecode EVM.
Les avantages de RISC-V :
Performance élevée : RISC-V est un ensemble d'instructions simplifiées pour CPU réels, convivial pour le matériel, utilisable pour l'optimisation JIT et même l'accélération matérielle.
Optimisation ZK : La génération de circuits directement à partir des instructions RISC-V dans les preuves ZK est plus simple que de prouver les opérations EVM.
Chaîne d'outils mature : prend en charge les langages populaires tels que Rust/C/C++, abaissant ainsi 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é 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'expansion.
Deux, chemins et défis de remplacement : comment migrer depuis EVM ?
Trois solutions de remplacement :
Double VM coexistence (le plus conservateur) : EVM et RISC-V fonctionnent en parallèle, les nouveaux contrats peuvent utiliser RISC-V, garantissant la compatibilité pendant la période de transition.
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.
Mécanisme de plugin d'interpréteur (compromis) : intégrer l'interpréteur en tant qu'élément de protocole, permettant d'insérer à l'avenir d'autres VM (comme Move).
Défis techniques auxquels l'implémentation est confrontée :
Risques de perte de performance d'exécution : RISC-V doit être exécuté en simulation sur des puces x86, ce qui peut initialement entraîner une efficacité inférieure à celle de l'EVM optimisé.
La tarification du Gas doit être restructurée : 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 d'un sandbox de sécurité : limiter les appels système, empêcher l'auto-modification 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é, supportant le code binaire RISC-V.
Problèmes de compatibilité de migration : certains contrats dépendent des caractéristiques de l'EVM, la migration nécessite une conception prudente d'une couche de compatibilité ou d'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 développeur inchangée et une mise à niveau transparente pour les utilisateurs.
Trois, l'impact sur les solutions d'extension existantes : RISC-V remplacera-t-il L2, le sharding de données, etc. ?
La réponse est négative : RISC-V est une optimisation de l'infrastructure et ne remplacera pas les routes d'extension existantes.
Layer 2 :
Rollup reste le principal moteur d'extension d'Ethereum, RISC-V améliore l'efficacité de traitement de L1 et la performance de validation ZK, mais n'augmente pas directement le débit.
Une validation L1 plus rapide peut aider les Rollups à soumettre des données à moindre coût et plus rapidement, améliorant ainsi l'évolutivité globale.
Shardage 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.
La modification de l'architecture n'affecte pas les besoins de stockage de données de L1.
FaaS, MEV :
Indépendant de l'architecture de la machine virtuelle, il ne sera pas obsolète en raison de l'avancement de RISC-V.
Résumé : RISC-V est un "moteur d'échange", L2/fragmentation est un "réseau de déploiement", les deux dimensions sont différentes et ne s'opposent pas en parallèle.
Quatre, retour de la communauté et tentatives connexes
Divergences communautaires :
Partisans : estiment qu'il s'agit d'une mise à niveau stratégique nécessaire pour faire face aux défis de performance tels que Solana/Sui, et qu'elle contribue à 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 rapport coût-rendement des ressources.
Projets similaires de référence :
Move VM (Aptos/Sui) : une nouvelle VM orientée ressources, avec une forte sécurité linguistique, mais incompatible 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 L2, déjà implémenté sur Arbitrum, avec faisabilité réelle.
Nervos CKB : L'utilisation de RISC-V comme VM de contrat sur le réseau principal est un précédent qui fournit 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étation du futur pourraient également être utilisés pour insérer des VM comme Move, WASM, etc., afin de construire un écosystème d'exécution diversifié.
Cinq, Perspectives d'impact futur : Si Ethereum passe à RISC-V.
Expérience développeur :
Les langages comme Solidity/Vyper peuvent toujours être utilisés, c'est l'arrière-plan du compilateur qui change 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ût d'exploitation et performance :
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 Gas étant plus proche du coût de la preuve ZK.
Compatibilité écologique et développement :
Pendant la période de coexistence des deux VM, les contrats existants peuvent continuer à fonctionner, tandis que les nouveaux contrats adopteront progressivement RISC-V.
L’infrastructure doit prendre en charge le nouveau format de bytecode, ce qui peut entraîner des modifications de compatibilité inter-chaînes (par exemple, BSC, problèmes de rétention 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 l'EVM d'Ethereum 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 à un stade précoce de discussion, et sa mise en œuvre devrait être un processus qui prendra des années, nécessitant de surmonter des défis techniques, communautaires et écologiques. Ce n'est pas un renversement de la trajectoire existante, mais plutôt un renforcement des bases, en préparation pour 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 "sous-jacent 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.
L'idée radicale de Vitalik : que signifie remplacer l'EVM d'Ethereum par RISC-V ?
Auteur | GaryMa 吴 dit Blockchain
Introduction
Le co-fondateur d'Ethereum, Vitalik Buterin, a récemment proposé une initiative à long terme au sein de la communauté Ethereum Magicians : remplacer la machine virtuelle actuelle d'exécution (EVM) par une architecture d'ensemble d'instructions open source RISC-V. Il a comparé cette conception à la Beam Chain de la couche de consensus, estimant que cela représente le seul chemin potentiel vers une percée des performances de la couche d'exécution et une simplification de la logique du protocole. En particulier en ce qui concerne l'efficacité des preuves à divulgation nulle de connaissance (ZK Proof), Vitalik prévoit qu'en remplaçant l'EVM, une optimisation pouvant atteindre 100 fois pourrait être réalisée. Cette proposition vise à répondre aux problèmes de goulot 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 analysera, en termes simples, les motivations, les détails techniques, les voies d'implémentation et les défis de cette proposition, explorant son impact sur les routes d'extension existantes d'Ethereum, tout en passant en revue les réactions de la communauté et les tentatives similaires.
Une, les limites actuelles de l'EVM et les avantages du RISC-V
Problèmes 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 la preuve ZK : 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.
Maintenance faible : accumulation de fonctionnalités complexes au fil des ans, normes confuses, comme SELFDESTRUCT difficile à abolir.
Développement limité : les ensembles d'instructions non standards restreignent le support interlangue, rendant difficile la compilation efficace des langages mainstream en bytecode EVM.
Les avantages de RISC-V :
Performance élevée : RISC-V est un ensemble d'instructions simplifiées pour CPU réels, convivial pour le matériel, utilisable pour l'optimisation JIT et même l'accélération matérielle.
Optimisation ZK : La génération de circuits directement à partir des instructions RISC-V dans les preuves ZK est plus simple que de prouver les opérations EVM.
Chaîne d'outils mature : prend en charge les langages populaires tels que Rust/C/C++, abaissant ainsi 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é 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'expansion.
Deux, chemins et défis de remplacement : comment migrer depuis EVM ?
Trois solutions de remplacement :
Double VM coexistence (le plus conservateur) : EVM et RISC-V fonctionnent en parallèle, les nouveaux contrats peuvent utiliser RISC-V, garantissant la compatibilité pendant la période de transition.
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.
Mécanisme de plugin d'interpréteur (compromis) : intégrer l'interpréteur en tant qu'élément de protocole, permettant d'insérer à l'avenir d'autres VM (comme Move).
Défis techniques auxquels l'implémentation est confrontée :
Risques de perte de performance d'exécution : RISC-V doit être exécuté en simulation sur des puces x86, ce qui peut initialement entraîner une efficacité inférieure à celle de l'EVM optimisé.
La tarification du Gas doit être restructurée : 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 d'un sandbox de sécurité : limiter les appels système, empêcher l'auto-modification 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é, supportant le code binaire RISC-V.
Problèmes de compatibilité de migration : certains contrats dépendent des caractéristiques de l'EVM, la migration nécessite une conception prudente d'une couche de compatibilité ou d'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 développeur inchangée et une mise à niveau transparente pour les utilisateurs.
Trois, l'impact sur les solutions d'extension existantes : RISC-V remplacera-t-il L2, le sharding de données, etc. ?
La réponse est négative : RISC-V est une optimisation de l'infrastructure et ne remplacera pas les routes d'extension existantes.
Layer 2 :
Rollup reste le principal moteur d'extension d'Ethereum, RISC-V améliore l'efficacité de traitement de L1 et la performance de validation ZK, mais n'augmente pas directement le débit.
Une validation L1 plus rapide peut aider les Rollups à soumettre des données à moindre coût et plus rapidement, améliorant ainsi l'évolutivité globale.
Shardage 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.
La modification de l'architecture n'affecte pas les besoins de stockage de données de L1.
FaaS, MEV :
Indépendant de l'architecture de la machine virtuelle, il ne sera pas obsolète en raison de l'avancement de RISC-V.
Résumé : RISC-V est un "moteur d'échange", L2/fragmentation est un "réseau de déploiement", les deux dimensions sont différentes et ne s'opposent pas en parallèle.
Quatre, retour de la communauté et tentatives connexes
Divergences communautaires :
Partisans : estiment qu'il s'agit d'une mise à niveau stratégique nécessaire pour faire face aux défis de performance tels que Solana/Sui, et qu'elle contribue à 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 rapport coût-rendement des ressources.
Projets similaires de référence :
Move VM (Aptos/Sui) : une nouvelle VM orientée ressources, avec une forte sécurité linguistique, mais incompatible 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 L2, déjà implémenté sur Arbitrum, avec faisabilité réelle.
Nervos CKB : L'utilisation de RISC-V comme VM de contrat sur le réseau principal est un précédent qui fournit 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étation du futur pourraient également être utilisés pour insérer des VM comme Move, WASM, etc., afin de construire un écosystème d'exécution diversifié.
Cinq, Perspectives d'impact futur : Si Ethereum passe à RISC-V.
Expérience développeur :
Les langages comme Solidity/Vyper peuvent toujours être utilisés, c'est l'arrière-plan du compilateur qui change 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ût d'exploitation et performance :
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 Gas étant plus proche du coût de la preuve ZK.
Compatibilité écologique et développement :
Pendant la période de coexistence des deux VM, les contrats existants peuvent continuer à fonctionner, tandis que les nouveaux contrats adopteront progressivement RISC-V.
L’infrastructure doit prendre en charge le nouveau format de bytecode, ce qui peut entraîner des modifications de compatibilité inter-chaînes (par exemple, BSC, problèmes de rétention 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 l'EVM d'Ethereum 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 à un stade précoce de discussion, et sa mise en œuvre devrait être un processus qui prendra des années, nécessitant de surmonter des défis techniques, communautaires et écologiques. Ce n'est pas un renversement de la trajectoire existante, mais plutôt un renforcement des bases, en préparation pour 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 "sous-jacent mérite d'être remodelé".
Référence :