Dans la feuille de route future d'Ethereum, une nouvelle proposition lancée par Vitalik Buterin, cofondateur d'Ethereum, suscite de vives discussions au sein de la communauté : remplacer l'EVM (Machine virtuelle d'Ethereum) par RISC-V en tant que langage de machine virtuelle pour les smart contracts. Cette idée est comparée à une "mise à niveau de niveau beam chain" pour la couche d'exécution, non seulement pour l'évolutivité, mais aussi pour résoudre les goulots d'étranglement fondamentaux de la complexité et de l'efficacité actuelles de la couche d'exécution.
Qu’est-ce que RISC-V ? Pourquoi remplacer les EVM ?
Le cœur de la proposition est de remplacer l'EVM actuellement utilisé par les contrats intelligents Ethereum par une architecture de jeu d'instructions open source et modulaire — RISC-V. Un tel changement ne renversera pas les outils de développement et les habitudes des développeurs existants d'Ethereum, car :
Les systèmes de comptes existants, les appels inter-contrats, les méthodes de stockage et d'autres couches d'abstraction de base sont toujours conservés.
Les langages Solidity et Vyper d'origine peuvent être compilés en utilisant RISC-V comme backend, l'expérience des développeurs ne devrait pas changer de manière significative.
Les anciens contrats EVM peuvent toujours interagir de manière bidirectionnelle avec les nouveaux contrats RISC-V.
Ainsi, les développeurs n'ont pas besoin d'apprendre tout depuis le début, mais les performances et la simplicité de la couche sous-jacente d'Ethereum devraient être considérablement améliorées.
ZK-EVM est le principal goulot d'étranglement des performances.
Avec l'arrivée de plusieurs propositions d'extension à l'avenir (comme EIP-4444, l'exécution différée et les clients sans état), les véritables facteurs limitant la capacité d'extension d'Ethereum L1 se concentreront sur :
Stabilité des échantillons de disponibilité des données et des protocoles de stockage historique
Concurrence sur le marché de la production de blocs
Efficacité des preuves ZK-EVM
Actuellement, dans le processus de preuve d'un bloc par ZK-EVM, l'exécution de la logique de la machine virtuelle EVM représente environ 50 % des ressources. Cela signifie que si les smart contracts peuvent être exécutés directement dans un environnement RISC-V, il y a une possibilité d'augmenter l'efficacité des preuves ZK jusqu'à 50 fois, voire 100 fois.
Il est intéressant de noter que le processus de preuve de l'actuel ZK-EVM consiste en réalité à compiler l'EVM en RISC-V, puis à faire prouver cela par le système ZK. Ainsi, faire de RISC-V la machine virtuelle native de la couche d'exécution d'Ethereum n'est pas seulement logique, mais permet également d'économiser les ressources consommées lors de la conversion intermédiaire.
Pourquoi RISC-V est-il rapide ? Optimisation complète des fonctions de hachage à la conception structurelle.
Actuellement, les quatre principaux postes de dépenses en ressources pour ZK-EVM sont :
désérialiser_inputs
initialize_witness_db
state_root_computation
exécution de bloc
Les trois premiers peuvent être considérablement optimisés en utilisant des fonctions de hachage plus conviviales (comme Poseidon) et des arbres d'état binaires. Par exemple, Poseidon peut traiter 2 millions de hachages par seconde sur un ordinateur portable, bien au-delà des 15 000 de Keccak. Si ces optimisations sont mises en œuvre, cela réduira considérablement la charge des 50 % précédents.
Mais les 50 % restants proviennent encore de
exécution de bloc
Cette partie ne peut être fondamentalement résolue que par une conception de VM plus efficace, comme RISC-V.
Trois modes de mise en œuvre, avec des choix allant du conservateur à l'agressif.
Vitalik a proposé trois voies d'implémentation technique :
– Option 1 : Coexistence de deux Machines virtuelles (risque minimal) : Permet aux contrats de choisir d'utiliser EVM ou RISC-V, les deux étant interopérables et partageant des ressources, équilibrant compatibilité et innovation.
– Option deux : Interpréteur EVM empaqueté RISC-V (mise à niveau radicale) : tous les contrats EVM seront exécutés via l'interpréteur EVM intégré de RISC-V, permettant une transition de l'ensemble de la couche d'exécution vers une architecture sous-jacente unifiée.
Option 3 : La couche de protocole prend en charge l’interpréteur de machine virtuelle (la route moyenne) : le protocole est conçu avec un « module de machine virtuelle », qui implémente l’interpréteur EVM avec RISC-V par défaut, et permet de futures extensions à d’autres langages, tels que Move.
Les avantages communs de ces chemins sont : la simplification des spécifications de la couche d'exécution, l'amélioration de la maintenabilité et la transparence de la vérification.
Sui développeur Mysten Labs cofondateur : s'il pouvait recommencer, il choisirait Move, sans tenir compte des langues multiples.
Concernant cette proposition, Sam Blackshear, co-fondateur de Mysten Labs, la société de développement Sui, a également exprimé son avis. Il a déclaré : « Je pense que l'adoption d'un backend RISC-V est un bon choix pour Ethereum (car il doit prendre en charge les contrats EVM existants). Mais si je devais concevoir une nouvelle chaîne à partir de zéro, je choisirais toujours Move, plutôt que le support multilangue. Les nombreux avantages de Sui viennent précisément de l'utilisation d'objets fortement typés comme couche d'abstraction commune dans l'ensemble de la pile."
Cela reflète les facteurs historiques liés à la "stratégie de choix de machines virtuelles" pour différentes chaînes. Ethereum, qui a été développé le plus tôt, n'a pas pu anticiper de nombreux besoins et développements futurs lors de sa conception initiale. Actuellement, il souligne la compatibilité et la conception de transition en réponse aux changements. En revanche, la nouvelle chaîne publique Sui se concentre sur une intégration complète de la pile, de la langue à la couche inférieure, permettant une intégration étroite entre le développement et la sécurité.
Typus Finance a également partagé sa conversation avec Vitalik lors de l'événement EthTaipei. Il se souvient : « À ce moment-là, j'ai demandé à Vitalik : 'Penses-tu que le langage Move et la programmation orientée objet peuvent améliorer la sécurité de la blockchain ?' »
Il a répondu : « Je ne pense pas que cela change quoi que ce soit, un projet volé est un projet volé, peu importe la langue. »
Mais Kyrie a immédiatement rétorqué que Move peut effectivement réduire la probabilité d'erreurs de développement, qu'il est plus facile à maîtriser que Rust, et que le modèle orienté objet aide à limiter la portée des risques. « Lorsque le contrat est volé, la perte peut être un montant limité plutôt qu'une exposition illimitée. » a-t-il ajouté.
Bien que Vitalik ne se soit pas exprimé à l'époque, le fait qu'il soit maintenant disposé à proposer RISC-V comme une alternative plus robuste et modulaire semble indiquer un léger changement d'attitude concernant l'importance de la conception du langage pour la sécurité de la blockchain.
Cet article parle de l'opération à cœur ouvert d'Éthereum ? La proposition de Vitalik indique que la couche d'exécution d'Ethereum pourrait remplacer complètement la Machine virtuelle, en passant à RISC-V, apparue pour la première fois dans la chaîne d'actualités ABMedia.
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.
Opération de changement de cœur en Ethereum ? Vitalik propose que la couche d'exécution d'Ethereum pourrait remplacer entièrement l'EVM par RISC-V.
Dans la feuille de route future d'Ethereum, une nouvelle proposition lancée par Vitalik Buterin, cofondateur d'Ethereum, suscite de vives discussions au sein de la communauté : remplacer l'EVM (Machine virtuelle d'Ethereum) par RISC-V en tant que langage de machine virtuelle pour les smart contracts. Cette idée est comparée à une "mise à niveau de niveau beam chain" pour la couche d'exécution, non seulement pour l'évolutivité, mais aussi pour résoudre les goulots d'étranglement fondamentaux de la complexité et de l'efficacité actuelles de la couche d'exécution.
Qu’est-ce que RISC-V ? Pourquoi remplacer les EVM ?
Le cœur de la proposition est de remplacer l'EVM actuellement utilisé par les contrats intelligents Ethereum par une architecture de jeu d'instructions open source et modulaire — RISC-V. Un tel changement ne renversera pas les outils de développement et les habitudes des développeurs existants d'Ethereum, car :
Les systèmes de comptes existants, les appels inter-contrats, les méthodes de stockage et d'autres couches d'abstraction de base sont toujours conservés.
Les langages Solidity et Vyper d'origine peuvent être compilés en utilisant RISC-V comme backend, l'expérience des développeurs ne devrait pas changer de manière significative.
Les anciens contrats EVM peuvent toujours interagir de manière bidirectionnelle avec les nouveaux contrats RISC-V.
Ainsi, les développeurs n'ont pas besoin d'apprendre tout depuis le début, mais les performances et la simplicité de la couche sous-jacente d'Ethereum devraient être considérablement améliorées.
ZK-EVM est le principal goulot d'étranglement des performances.
Avec l'arrivée de plusieurs propositions d'extension à l'avenir (comme EIP-4444, l'exécution différée et les clients sans état), les véritables facteurs limitant la capacité d'extension d'Ethereum L1 se concentreront sur :
Stabilité des échantillons de disponibilité des données et des protocoles de stockage historique
Concurrence sur le marché de la production de blocs
Efficacité des preuves ZK-EVM
Actuellement, dans le processus de preuve d'un bloc par ZK-EVM, l'exécution de la logique de la machine virtuelle EVM représente environ 50 % des ressources. Cela signifie que si les smart contracts peuvent être exécutés directement dans un environnement RISC-V, il y a une possibilité d'augmenter l'efficacité des preuves ZK jusqu'à 50 fois, voire 100 fois.
Il est intéressant de noter que le processus de preuve de l'actuel ZK-EVM consiste en réalité à compiler l'EVM en RISC-V, puis à faire prouver cela par le système ZK. Ainsi, faire de RISC-V la machine virtuelle native de la couche d'exécution d'Ethereum n'est pas seulement logique, mais permet également d'économiser les ressources consommées lors de la conversion intermédiaire.
Pourquoi RISC-V est-il rapide ? Optimisation complète des fonctions de hachage à la conception structurelle.
Actuellement, les quatre principaux postes de dépenses en ressources pour ZK-EVM sont :
désérialiser_inputs
initialize_witness_db
state_root_computation
exécution de bloc
Les trois premiers peuvent être considérablement optimisés en utilisant des fonctions de hachage plus conviviales (comme Poseidon) et des arbres d'état binaires. Par exemple, Poseidon peut traiter 2 millions de hachages par seconde sur un ordinateur portable, bien au-delà des 15 000 de Keccak. Si ces optimisations sont mises en œuvre, cela réduira considérablement la charge des 50 % précédents.
Mais les 50 % restants proviennent encore de
exécution de bloc
Cette partie ne peut être fondamentalement résolue que par une conception de VM plus efficace, comme RISC-V.
Trois modes de mise en œuvre, avec des choix allant du conservateur à l'agressif.
Vitalik a proposé trois voies d'implémentation technique :
– Option 1 : Coexistence de deux Machines virtuelles (risque minimal) : Permet aux contrats de choisir d'utiliser EVM ou RISC-V, les deux étant interopérables et partageant des ressources, équilibrant compatibilité et innovation.
– Option deux : Interpréteur EVM empaqueté RISC-V (mise à niveau radicale) : tous les contrats EVM seront exécutés via l'interpréteur EVM intégré de RISC-V, permettant une transition de l'ensemble de la couche d'exécution vers une architecture sous-jacente unifiée.
Option 3 : La couche de protocole prend en charge l’interpréteur de machine virtuelle (la route moyenne) : le protocole est conçu avec un « module de machine virtuelle », qui implémente l’interpréteur EVM avec RISC-V par défaut, et permet de futures extensions à d’autres langages, tels que Move.
Les avantages communs de ces chemins sont : la simplification des spécifications de la couche d'exécution, l'amélioration de la maintenabilité et la transparence de la vérification.
Sui développeur Mysten Labs cofondateur : s'il pouvait recommencer, il choisirait Move, sans tenir compte des langues multiples.
Concernant cette proposition, Sam Blackshear, co-fondateur de Mysten Labs, la société de développement Sui, a également exprimé son avis. Il a déclaré : « Je pense que l'adoption d'un backend RISC-V est un bon choix pour Ethereum (car il doit prendre en charge les contrats EVM existants). Mais si je devais concevoir une nouvelle chaîne à partir de zéro, je choisirais toujours Move, plutôt que le support multilangue. Les nombreux avantages de Sui viennent précisément de l'utilisation d'objets fortement typés comme couche d'abstraction commune dans l'ensemble de la pile."
Cela reflète les facteurs historiques liés à la "stratégie de choix de machines virtuelles" pour différentes chaînes. Ethereum, qui a été développé le plus tôt, n'a pas pu anticiper de nombreux besoins et développements futurs lors de sa conception initiale. Actuellement, il souligne la compatibilité et la conception de transition en réponse aux changements. En revanche, la nouvelle chaîne publique Sui se concentre sur une intégration complète de la pile, de la langue à la couche inférieure, permettant une intégration étroite entre le développement et la sécurité.
Typus Finance a également partagé sa conversation avec Vitalik lors de l'événement EthTaipei. Il se souvient : « À ce moment-là, j'ai demandé à Vitalik : 'Penses-tu que le langage Move et la programmation orientée objet peuvent améliorer la sécurité de la blockchain ?' »
Il a répondu : « Je ne pense pas que cela change quoi que ce soit, un projet volé est un projet volé, peu importe la langue. »
Mais Kyrie a immédiatement rétorqué que Move peut effectivement réduire la probabilité d'erreurs de développement, qu'il est plus facile à maîtriser que Rust, et que le modèle orienté objet aide à limiter la portée des risques. « Lorsque le contrat est volé, la perte peut être un montant limité plutôt qu'une exposition illimitée. » a-t-il ajouté.
Bien que Vitalik ne se soit pas exprimé à l'époque, le fait qu'il soit maintenant disposé à proposer RISC-V comme une alternative plus robuste et modulaire semble indiquer un léger changement d'attitude concernant l'importance de la conception du langage pour la sécurité de la blockchain.
Cet article parle de l'opération à cœur ouvert d'Éthereum ? La proposition de Vitalik indique que la couche d'exécution d'Ethereum pourrait remplacer complètement la Machine virtuelle, en passant à RISC-V, apparue pour la première fois dans la chaîne d'actualités ABMedia.