Vitalik : Proposition à long terme pour la couche d'exécution L1 – Remplacer l'EVM par RISC-V
TechFlow SélectionTechFlow Sélection
Vitalik : Proposition à long terme pour la couche d'exécution L1 – Remplacer l'EVM par RISC-V
L'objectif est d'améliorer considérablement l'efficacité et la simplicité de la couche d'exécution, ainsi que de surmonter les goulots d'étranglement en matière de scalabilité.
Dédié à des analyses Web3 approfondiesSource : Vitalik Buterin
Traduction : KarenZ, Foresight News
Le 20 avril, Vitalik Buterin a publié sur la plateforme Ethereum Magicians une proposition importante concernant la couche d'exécution L1 à long terme d'Ethereum. Il suggère d'adopter l'architecture RISC-V pour remplacer l'EVM actuelle (Machine Virtuelle Ethereum) en tant que langage de machine virtuelle pour l'écriture des contrats intelligents, dans le but d'améliorer fondamentalement l'efficacité de la couche d'exécution d'Ethereum, de surmonter l'un des principaux goulots d'étranglement en matière de scalabilité, et de simplifier considérablement cette couche.
Foresight News a traduit intégralement cette proposition afin d'aider les lecteurs à comprendre cette idée technique. Voici le texte intégral traduit de la proposition :
Ce document présente une idée radicale quant à l'avenir de la couche d'exécution d'Ethereum, dont l'ambition est comparable au projet Beam Chain pour la couche de consensus. Cette proposition vise à améliorer massivement l'efficacité de la couche d'exécution d'Ethereum, à résoudre un des principaux goulots d'étranglement en termes de scalabilité, et à simplifier fortement ladite couche — en réalité, il pourrait s'agir de la seule voie réalisable vers cet objectif.
Idée centrale : Remplacer l'EVM par RISC-V comme langage de machine virtuelle pour l'écriture des contrats intelligents.
Précisions importantes :
-
Les concepts tels que le système de comptes, les appels entre contrats et le stockage seront entièrement conservés. Ces abstractions fonctionnent bien et sont familières aux développeurs. Les opcodes comme SLOAD, SSTORE, BALANCE ou CALL deviendront des appels système RISC-V.
-
Dans ce modèle, les contrats intelligents pourront être écrits en Rust, mais je pense que la majorité des développeurs continueront d'utiliser Solidity (ou Vyper), qui seront adaptés pour utiliser RISC-V comme nouveau backend. En effet, les contrats écrits directement en Rust sont souvent peu lisibles, tandis que Solidity et Vyper restent plus clairs. L'expérience de développement sera presque inchangée, et les développeurs ne remarqueront peut-être même pas la transition.
-
Les anciens contrats EVM continueront de fonctionner et seront entièrement compatibles dans les deux sens avec les nouveaux contrats RISC-V. Plusieurs approches sont possibles, comme décrit plus loin dans ce texte.
Nervos CKB VM a déjà ouvert la voie, puisqu'il s'agit essentiellement d'une implémentation RISC-V.
Pourquoi faire cela ?
À court terme, les EIP prévus (comme les listes d'accès au niveau bloc, l'exécution différée, le stockage historique distribué et l'EIP-4444) permettront de résoudre les principaux goulots d'étranglement de scalabilité de la L1 d'Ethereum. À moyen terme, davantage de progrès seront accomplis grâce à l'étatlessness et au ZK-EVM. À long terme, les principaux facteurs limitants du scalabilité de la L1 d'Ethereum seront :
-
La stabilité des protocoles d'échantillonnage de disponibilité des données et de stockage historique
-
La nécessité de maintenir une concurrence viable dans la production de blocs
-
La capacité de preuve du ZK-EVM
J'argumenterai que le remplacement du ZK-EVM par RISC-V peut résoudre les goulots d'étranglement clés dans (2) et (3).
Le tableau ci-dessous montre le nombre de cycles requis par Succinct ZK-EVM pour prouver chaque étape de l'exécution EVM :
Légende : Les quatre étapes principales consommatrices de temps sont deserialize_inputs, initialize_witness_db, state_root_computation et block_execution
Les composants initialize_witness_db et state_root_computation sont liés à l'arbre d'état, tandis que deserialize_inputs concerne la conversion des blocs et des données de témoins en une représentation interne — en réalité, plus de 50 % de ce temps est proportionnel à la taille des données de témoins.
Ces parties peuvent être largement optimisées en remplaçant l'arbre de Merkle-Patricia keccak 16-aire actuel par un arbre binaire utilisant une fonction de hachage facile à prouver. Avec Poseidon, nous pouvons prouver jusqu'à 2 millions de hachages par seconde sur un ordinateur portable (contre environ 15 000 hash/sec pour keccak). Outre Poseidon, de nombreuses autres options existent. Globalement, ces composants offrent un fort potentiel d'optimisation. De plus, on peut éliminer accrue_logs_bloom en supprimant les filtres Bloom.
Il reste block_execution, qui représente environ la moitié des cycles de preuve actuels (prover cycles). Pour atteindre un gain global de 100 fois en efficacité de preuve, l'efficacité de preuve de l'EVM doit augmenter d'au moins 50 fois. Une solution consiste à créer une implémentation de preuve plus efficace pour l'EVM ; une autre est de remarquer que les prouveurs ZK-EVM actuels compilent en réalité l'EVM en RISC-V pour produire les preuves — il serait donc logique de permettre aux développeurs de contrats intelligents d'accéder directement à cette machine virtuelle RISC-V.
Certains chiffres indiquent qu'un gain supérieur à 100 fois pourrait être possible dans certains cas :
Dans la pratique, le temps restant du prouveur serait probablement dominé par les opérations de précompilations actuelles. En adoptant RISC-V comme machine virtuelle principale, le calendrier des coûts en gaz reflétera le temps réel de preuve, et la pression économique incitera les développeurs à réduire l'utilisation des précompilations coûteuses. Même si les gains ne sont pas aussi spectaculaires, il existe de bonnes raisons de croire qu'ils seront très significatifs.
(Notons que dans l'exécution classique de l'EVM, la répartition du temps entre « opérations EVM » et « autres opérations » est également proche de 50/50, ce qui renforce intuitivement l'idée que supprimer l'EVM comme « couche intermédiaire » apporterait un gain similaire)
Détails de mise en œuvre
Plusieurs approches sont possibles pour mettre en œuvre cette proposition. La solution la moins disruptive consiste à supporter simultanément les deux machines virtuelles, en permettant aux contrats de choisir celle qu'ils souhaitent utiliser. Les deux types de contrats auront accès aux mêmes fonctionnalités : stockage persistant (SLOAD/SSTORE), détention d'un solde ETH, envoi / réception d'appels, etc. Les contrats EVM et RISC-V pourront s'appeler mutuellement — du point de vue RISC-V, appeler un contrat EVM revient à exécuter un appel système avec des paramètres spéciaux ; un contrat EVM recevant un message l'interprétera comme un opcode CALL.
Une approche plus radicale du point de vue du protocole consisterait à convertir les contrats EVM existants en appelant un interpréteur EVM écrit en RISC-V, qui exécuterait leur code EVM existant. Autrement dit, si un contrat EVM contient un code C, et que l'interpréteur EVM se trouve à l'adresse X, alors ce contrat serait remplacé par une logique de haut niveau qui, lorsqu'il est appelé depuis l'extérieur avec des paramètres D, invoque X avec (C, D), attend la valeur de retour, puis la transmet. Si l'interpréteur EVM lui-même appelle ce contrat pour exécuter un CALL ou un SLOAD/SSTORE, le contrat effectue alors ces opérations.
Une solution intermédiaire consisterait à adopter cette deuxième approche, mais en intégrant explicitement au protocole le concept d’« interpréteur de machine virtuelle », dont la logique devrait être écrite en RISC-V. L'EVM serait la première instance, mais d'autres langages pourraient suivre à l'avenir (Move étant un candidat possible).
L'avantage principal des deuxième et troisième solutions réside dans la simplification massive qu'elles permettent de la spécification de la couche d'exécution. Étant donné que même des simplifications progressives comme la suppression de SELFDESTRUCT se heurtent à d'énormes difficultés, cette approche pourrait bien être la seule voie praticable. Le projet Tinygrad suit une règle stricte selon laquelle son code ne doit pas dépasser 10 000 lignes. De même, la meilleure infrastructure blockchain devrait non seulement pouvoir respecter aisément cette limite, mais aller encore plus loin dans la concision. Le projet Beam Chain promet de simplifier massivement la couche de consensus d'Ethereum ; pour que la couche d'exécution connaisse des progrès similaires, une transformation aussi radicale pourrait bien être la seule option viable.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@VitalikButerin
