Le cofondateur d'Ethereum, Vitalik Buterin, a récemment proposé une proposition à long terme au sein de la communauté Ethereum Magicians : remplacer la machine virtuelle d'exécution actuelle (EVM) par l'architecture d'instructions open source RISC-V. Il a comparé cette idée à la chaîne Beam du niveau de consensus, considérant que c'est le seul chemin potentiel pour réaliser des percées de performance au niveau de l'exécution et simplifier la logique des protocoles. En particulier en ce qui concerne l'efficacité des preuves à divulgation nulle de connaissance (ZK Proof), Vitalik s'attend à ce qu'en remplaçant l'EVM, une optimisation de jusqu'à 100 fois soit possible. 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 expliquera de manière simple 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.
Une, les limitations actuelles de l'EVM et les avantages du RISC-V
Problèmes de l'EVM :
Architecture obsolète : EVM utilise une structure empilée de 256 bits, incompatible avec les CPU modernes, ce qui entraîne une efficacité réduite lors de l'exécution de ZK-EVM.
Bottleneck de preuve ZK : Comme indiqué par 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 fonctionnalités complexes au fil des ans, normes confuses, comme SELFDESTRUCT difficile à abolir.
Développement limité : les ensembles d'instructions non standard restreignent le support interlangue, rendant difficile la compilation efficace des langages courants en code binaire EVM.
Avantages de RISC-V :
Performance élevée : RISC-V est un ensemble d'instructions réduit pour les 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 directement des circuits pour les instructions RISC-V dans les preuves ZK est plus simple que de prouver des opérations EVM.
Chaîne d'outils mature : supporte les langages principaux comme 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 comme Nervos CKB, avec des cas de succès.
Vitalik a souligné qu'il vaut mieux utiliser RISC-V comme architecture d'exécution de contrat 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 de remplacement et défis : 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 opter pour RISC-V, garantissant la compatibilité durant la période de transition.
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.
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 VM (comme Move).
Défis techniques rencontrés lors de la mise en œuvre :
Risque de dégradation de performance d'exécution : RISC-V doit être simulé sur des puces x86, ce qui peut entraîner une efficacité initiale inférieure à celle d'un EVM optimisé.
La tarification du Gas doit être refondue : 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 l'auto-modification du code, garantir une exécution déterministe.
Outils de développement adaptés : nécessite la mise à jour des compilateurs, débogueurs et outils d'audit de sécurité, prenant en charge le code byte 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 anciens et nouveaux contrats restent interopérables, garantissant une expérience développeur inchangée et une mise à niveau transparente pour les utilisateurs.
Trois, impact sur les routes d'extension existantes : RISC-V va-t-il remplacer 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.
Couche 2 :
Le Rollup reste le principal moteur d'extension d'Ethereum, le RISC-V améliore l'efficacité de traitement du L1 et les performances de validation 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 plus bas et plus rapidement, améliorant ainsi l'évolutivité globale.
Sharding de données et EIP-4844 :
Le goulot d'étranglement de la disponibilité des données doit encore être résolu par EIP-4844 (blob) et Danksharding, RISC-V n'affecte pas la capacité des données sur la chaîne.
Les changements d'architecture n'affectent 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 des avancées de RISC-V.
Résumé : RISC-V est un « moteur de changement », L2 / sharding est un « réseau d'expansion », les deux dimensions sont différentes, mais ne s'opposent pas.
Quatre, retour 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 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 de l'histoire, des coûts de mise à jour de l'écosystème d'outils, et remettent en question le rapport coût-bénéfice des ressources investies.
Références de projets similaires :
Move VM (Aptos/Sui) : Nouveau VM orienté 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à réalisé sur Arbitrum, avec une 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 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 :
Des langages comme Solidity/Vyper peuvent toujours être utilisés, le backend du compilateur change et non 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'augmentation 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, et le modèle de Gas est plus proche du coût des preuves ZK.
Compatibilité et développement écologique :
Pendant la période de coexistence des doubles VM, les contrats existants peuvent continuer à fonctionner, 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 changements de compatibilité inter-chaînes (comme les problèmes de présence ou d'absence de BSC et Polygon).
Sécurité et stabilité :
La nouvelle architecture doit être largement testée et vérifiée formellement pour améliorer la fiabilité du protocole.
Une couche d'exécution plus simplifiée 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 à un stade précoce de discussion et sa mise en œuvre devrait prendre 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 en vue 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, mais aussi comme 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.
Proposition radicale de V神 : remplacer l'EVM d'Ethereum par RISC-V, ZK est-il la solution finale pour l'extensibilité ?
Auteur | GaryMa Wu a dit Blockchain
Introduction
Le cofondateur d'Ethereum, Vitalik Buterin, a récemment proposé une proposition à long terme au sein de la communauté Ethereum Magicians : remplacer la machine virtuelle d'exécution actuelle (EVM) par l'architecture d'instructions open source RISC-V. Il a comparé cette idée à la chaîne Beam du niveau de consensus, considérant que c'est le seul chemin potentiel pour réaliser des percées de performance au niveau de l'exécution et simplifier la logique des protocoles. En particulier en ce qui concerne l'efficacité des preuves à divulgation nulle de connaissance (ZK Proof), Vitalik s'attend à ce qu'en remplaçant l'EVM, une optimisation de jusqu'à 100 fois soit possible. 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 expliquera de manière simple 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.
Une, les limitations actuelles de l'EVM et les avantages du RISC-V
Problèmes de l'EVM :
Architecture obsolète : EVM utilise une structure empilée de 256 bits, incompatible avec les CPU modernes, ce qui entraîne une efficacité réduite lors de l'exécution de ZK-EVM.
Bottleneck de preuve ZK : Comme indiqué par 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 fonctionnalités complexes au fil des ans, normes confuses, comme SELFDESTRUCT difficile à abolir.
Développement limité : les ensembles d'instructions non standard restreignent le support interlangue, rendant difficile la compilation efficace des langages courants en code binaire EVM.
Avantages de RISC-V :
Performance élevée : RISC-V est un ensemble d'instructions réduit pour les 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 directement des circuits pour les instructions RISC-V dans les preuves ZK est plus simple que de prouver des opérations EVM.
Chaîne d'outils mature : supporte les langages principaux comme 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 comme Nervos CKB, avec des cas de succès.
Vitalik a souligné qu'il vaut mieux utiliser RISC-V comme architecture d'exécution de contrat 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 de remplacement et défis : 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 opter pour RISC-V, garantissant la compatibilité durant la période de transition.
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.
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 VM (comme Move).
Défis techniques rencontrés lors de la mise en œuvre :
Risque de dégradation de performance d'exécution : RISC-V doit être simulé sur des puces x86, ce qui peut entraîner une efficacité initiale inférieure à celle d'un EVM optimisé.
La tarification du Gas doit être refondue : 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 l'auto-modification du code, garantir une exécution déterministe.
Outils de développement adaptés : nécessite la mise à jour des compilateurs, débogueurs et outils d'audit de sécurité, prenant en charge le code byte 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 anciens et nouveaux contrats restent interopérables, garantissant une expérience développeur inchangée et une mise à niveau transparente pour les utilisateurs.
Trois, impact sur les routes d'extension existantes : RISC-V va-t-il remplacer 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.
Couche 2 :
Le Rollup reste le principal moteur d'extension d'Ethereum, le RISC-V améliore l'efficacité de traitement du L1 et les performances de validation 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 plus bas et plus rapidement, améliorant ainsi l'évolutivité globale.
Sharding de données et EIP-4844 :
Le goulot d'étranglement de la disponibilité des données doit encore être résolu par EIP-4844 (blob) et Danksharding, RISC-V n'affecte pas la capacité des données sur la chaîne.
Les changements d'architecture n'affectent 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 des avancées de RISC-V.
Résumé : RISC-V est un « moteur de changement », L2 / sharding est un « réseau d'expansion », les deux dimensions sont différentes, mais ne s'opposent pas.
Quatre, retour 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 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 de l'histoire, des coûts de mise à jour de l'écosystème d'outils, et remettent en question le rapport coût-bénéfice des ressources investies.
Références de projets similaires :
Move VM (Aptos/Sui) : Nouveau VM orienté 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à réalisé sur Arbitrum, avec une 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 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 :
Des langages comme Solidity/Vyper peuvent toujours être utilisés, le backend du compilateur change et non 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'augmentation 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, et le modèle de Gas est plus proche du coût des preuves ZK.
Compatibilité et développement écologique :
Pendant la période de coexistence des doubles VM, les contrats existants peuvent continuer à fonctionner, 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 changements de compatibilité inter-chaînes (comme les problèmes de présence ou d'absence de BSC et Polygon).
Sécurité et stabilité :
La nouvelle architecture doit être largement testée et vérifiée formellement pour améliorer la fiabilité du protocole.
Une couche d'exécution plus simplifiée 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 à un stade précoce de discussion et sa mise en œuvre devrait prendre 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 en vue 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, mais aussi comme une exploration approfondie de la question de savoir si le "sous-jacent mérite d'être remodelé".
Source de référence :