Vers une nouvelle architecture d’exécution d’Ethereum
Cette proposition introduit une idée audacieuse pour transformer la couche d’exécution d’Ethereum en remplaçant l’Ethereum Virtual Machine (EVM) par RISC-V comme machine virtuelle pour les contrats intelligents. L’objectif est d’accroître l’efficacité, de résoudre les principaux goulots d’étranglement liés à la scalabilité et de simplifier la couche d’exécution. Et tout ça en garantissant une interopérabilité totale et une transition fluide pour les développeurs.
L’idée centrale consiste à adopter RISC-V comme langage de machine virtuelle en préservant les concepts fondamentaux d’Ethereum tels que les comptes, les appels inter-contrats et le stockage. Les opcodes actuels de l’EVM, comme SLOAD, SSTORE, BALANCE ou CALL, seraient convertis en appels système RISC-V. Les contrats intelligents pourraient être écrits en Rust, mais il est probable que la majorité des développeurs continuent d’utiliser Solidity ou Vyper, qui seraient adaptés pour générer du code RISC-V.
Grâce à la lisibilité de ces langages par rapport à Rust, l’expérience des développeurs resterait largement inchangée, rendant le changement presque imperceptible. Les contrats EVM existants demeureraient fonctionnels et entièrement interopérables avec les nouveaux contrats RISC-V, s’inspirant de précédents comme la machine virtuelle Nervos CKB, qui repose sur RISC-V.
Un cadre d’évolution pensé pour la scalabilité d’Ethereum
Cette proposition s’inscrit dans le contexte des défis de scalabilité d’Ethereum. À court terme, les Ethereum Improvement Proposals (EIP) telles que les listes d’accès au niveau des blocs, l’exécution différée, le stockage d’historique distribué et l’EIP-4444 adressent les obstacles immédiats. À moyen terme, des avancées sont réalisées sur l’absence d’état et les ZK-EVM. À long terme, les limites principales concernent la disponibilité des données, les protocoles d’échantillonnage, le stockage d’historique, la production compétitive de blocs et les capacités de preuve des ZK-EVM. Ce projet vise à résoudre des goulots d’étranglement critiques dans ces deux derniers domaines.
Les ZK-EVM actuels, comme celui de Succinct, révèlent que plus de la moitié des cycles de preuve sont consommés par des processus tels que la désérialisation des entrées, l’initialisation de la base de témoins et le calcul de la racine d’état, qui sont proportionnels à la taille des témoins. Ces composants peuvent être optimisés en remplaçant l’arbre de Merkle Patricia 16-aire basé sur Keccak par un arbre binaire utilisant une fonction de hachage plus adaptée comme Poseidon, capable de prouver 2 millions de hachages par seconde contre 15’000 pour Keccak. La suppression de l’accrued_logs_bloom offrirait également des gains supplémentaires.
Cependant, l’exécution des blocs représente environ la moitié des cycles de preuve restants. Les prouveurs ZK-EVM compilent déjà l’EVM en RISC-V, et un accès direct à cette machine virtuelle pourrait, dans certains cas, multiplier l’efficacité par plus de 100. En ajustant le gas schedule pour refléter les temps de preuve, les précompilations coûteuses seraient progressivement abandonnées, bien que les gains réels, bien que significatifs, pourraient être moins spectaculaires que prévu.
Une efficacité démultipliée via un accès natif à RISC-V
Plusieurs approches sont envisageables pour mettre en œuvre cette transition. La première, la moins disruptive, consisterait à supporter simultanément l’EVM et RISC-V, permettant aux développeurs d’écrire des contrats dans l’une ou l’autre machine virtuelle. Les deux types de contrats auraient accès aux mêmes fonctionnalités, comme le stockage persistant, la gestion des soldes d’ETH et les appels inter-contrats.
Les contrats EVM et RISC-V pourraient s’appeler mutuellement, un contrat RISC-V percevant l’appel à un contrat EVM comme un appel système avec des paramètres spécifiques. Une deuxième approche, plus radicale, convertirait les contrats EVM existants en contrats RISC-V appelant un interpréteur EVM écrit en RISC-V, qui exécuterait leur code original. Par exemple, un contrat EVM avec un code C serait remplacé par une logique appelant l’interpréteur à l’adresse X avec les paramètres (C, D). Une troisième option, intermédiaire, intégrerait au protocole le concept d’interpréteur de machine virtuelle écrit en RISC-V, avec l’EVM comme première implémentation, mais ouvrant la voie à d’autres machines virtuelles comme Move.
Les deuxième et troisième approches simplifieraient considérablement la spécification de la couche d’exécution, réduisant sa complexité à un niveau comparable à celui visé par des projets comme Tinygrad, qui limite son code à 10’000 lignes. Cette simplification, combinée à une optimisation des performances et à une meilleure scalabilité, pourrait être la seule solution viable pour relever les défis à long terme d’Ethereum, en complément d’initiatives comme Beam Chain pour la couche de consensus. En conclusion, remplacer l’EVM par RISC-V représente une opportunité de transformer la couche d’exécution d’Ethereum en la rendant plus efficace, plus simple et prête à répondre aux exigences d’un écosystème blockchain en constante évolution.
