Nouvelle proposition de Vitalik : remplacer l'EVM actuel par RISC-V

Cet article propose une idée radicale pour l’avenir de la couche d’exécution d’Ethereum, une idée aussi ambitieuse que les efforts de la chaîne Beam sur la couche de consensus. Il vise à améliorer considérablement l’efficacité de la couche d’exécution d’Ethereum, à résoudre l’un des principaux goulets d’étranglement en matière d’évolutivité et peut également simplifier considérablement la couche d’exécution - en fait, c’est peut-être la seule méthode.

Idée : remplacer l’EVM par RISC-V comme langage de machine virtuelle pour écrire des contrats intelligents (note de l’éditeur : RISC-V fait référence à une architecture d’ensemble d’instructions ouverte basée sur le principe RISC des architectures à jeu d’instructions réduit, où V indique la cinquième génération de RISC).

Clarification importante :

• Les concepts tels que les comptes, les appels inter-contrats, le stockage, etc. resteront complètement identiques. Ces abstractions fonctionnent très bien et les développeurs s’y sont habitués. Les codes d’opération SLOAD, SSTORE, BALANCE, CALL, etc. deviendront des appels système RISC-V.
• Dans un tel monde, les contrats intelligents peuvent être écrits en Rust, mais je m’attends à ce que la plupart des développeurs continuent à écrire des contrats intelligents en Solidity (ou Vyper), ce qui s’adaptera à l’ajout de RISC-V comme backend. C’est parce que les contrats intelligents écrits en Rust sont en réalité assez laids, tandis que la lisibilité de Solidity et Vyper est bien supérieure. Peut-être que les changements dans le devex sont minimes, et les développeurs ne remarqueront presque pas ce changement.
• Les anciens contrats EVM resteront valides et seront totalement interopérables dans les deux sens avec les nouveaux contrats RISC-V. Il existe plusieurs façons d’y parvenir, que je décrirai plus loin dans cet article.

Un exemple est Nervos CKB VM, qui est essentiellement RISC-V.

Pourquoi faire cela ?

À court terme, les principaux goulets d’étranglement de la scalabilité de l’Ethereum L1 seront résolus grâce aux EIP à venir, tels que les listes d’accès au niveau des blocs, l’exécution différée et le stockage d’historique distribué ainsi que l’EIP-4444. À moyen terme, nous aborderons d’autres problèmes liés à l’absence d’état et au ZK-EVM. À long terme, les principaux facteurs limitants de l’extension d’Ethereum Layer1 sont :

• Stabilité des protocoles d’échantillonnage de la disponibilité des données et de stockage historique
• Espérons maintenir la compétitivité du marché de la production de blocs
• Capacité de validation ZK-EVM

Je pense que remplacer ZK-EVM par RISC-V peut résoudre un goulot d’étranglement clé dans (2) et (3).

Voici le tableau des nombres de cycles pour prouver les différentes parties de la couche d’exécution EVM de Succinct ZK-EVM :

Quatre parties ont pris beaucoup de temps : deserialize_inputs, initialize_witness_db, state_root_computation et block_execution.

initialize_witness_db et state_root_computation sont tous deux liés à l’arbre d’état, deserialize_inputs fait référence au processus de conversion des données de bloc et de preuve en représentation interne ; par conséquent, en réalité, plus de 50 % est proportionnel à la taille de la preuve.

Nous pouvons considérablement optimiser ces parties en remplaçant l’arbre Merkle patricia de 16 éléments actuel par un arbre binaire utilisant une fonction de hachage conviviale pour les validateurs. Si nous utilisons Poseidon, nous pouvons prouver 2 millions de valeurs de hachage par seconde sur un ordinateur portable (alors que keccak ne permet qu’environ 15 000 valeurs de hachage par seconde). En plus de Poseidon, il existe de nombreuses autres options. En résumé, nous avons l’opportunité de réduire considérablement ces composants. En guise de récompense, nous pouvons nous débarrasser de l’accumulateur de logs en nous débarrassant de bloom.

Le reste est un bloc_execution, qui représente environ la moitié des cycles d’épreuve dépensés aujourd’hui. Si nous voulons augmenter l’efficacité globale de l’étalon de 100 fois, nous ne pouvons pas éviter le fait que nous devons augmenter l’efficacité de l’étalon EVM d’au moins 50 fois. Une chose que nous pouvons faire est d’essayer de créer des implémentations EVM qui sont plus efficaces en termes de cycles de preuve. Une autre chose que nous pouvons faire est de remarquer que le promoteur ZK-EVM fonctionne déjà aujourd’hui en prouvant une implémentation EVM compilée en RISC-V et en donnant aux développeurs de contrats intelligents un accès direct à cette VM RISC-V.

Certaines données indiquent que, dans des conditions limitées, cela peut augmenter l’efficacité de plus de 100 fois :

En fait, je prévois que le temps de preuve restant sera principalement dominé par la précompilation d’aujourd’hui. Si nous utilisons RISC-V comme machine virtuelle principale, alors le plan de gas reflétera le temps de preuve, il y aura donc une pression économique pour arrêter l’utilisation des précompilations plus coûteuses ; mais même ainsi, les rendements ne seront pas aussi impressionnants, mais nous avons de bonnes raisons de croire que les rendements seront très significatifs.

(Au fait, une répartition d’environ 50/50 entre “EVM” et “autres choses” apparaît également dans l’exécution EVM classique, nous nous attendons intuitivement à ce que les bénéfices retirés de l’EVM en tant que “intermédiaire” devraient également être importants.)

Détails de mise en œuvre

Il existe plusieurs façons de mettre en œuvre de telles suggestions. La méthode avec le moins de perturbations consiste à supporter deux machines virtuelles et à permettre l’écriture de contrats dans n’importe laquelle des machines virtuelles. Les deux types de contrats peuvent utiliser le même type de fonctionnalités : stockage persistant (SLOAD et SSTORE), capacité à détenir un solde ETH, capacité à passer et recevoir des appels, etc. Les contrats EVM et RISC-V peuvent s’appeler librement ; du point de vue de RISC-V, appeler un contrat EVM semble être un appel système avec certains paramètres spéciaux ; le contrat EVM recevant le message l’interprétera comme un CALL.

D’un point de vue protocoliaire, une approche plus radicale consiste à convertir les contrats EVM existants en contrats qui appellent un interpréteur EVM écrit en RISC-V, qui exécute leur code EVM existant. En d’autres termes, si un contrat EVM a le code C et que l’interpréteur EVM est à l’adresse X, alors ce contrat sera remplacé par une logique de haut niveau qui, lorsqu’elle est appelée avec les paramètres D depuis l’extérieur, utilise (C, D) pour appeler X, puis attend la valeur de retour et la transmet. Si l’interpréteur EVM lui-même appelle le contrat, demandant d’exécuter CALL ou SLOAD/SSTORE, alors le contrat le fera.

La voie intermédiaire consiste à adopter la deuxième option, mais à créer une fonctionnalité de protocole claire pour cela - essentiellement, en considérant le concept d’“interpréteur de machine virtuelle” comme une norme et en exigeant que sa logique soit écrite en RISC-V. L’EVM sera le premier, mais il pourrait aussi y avoir d’autres (par exemple, Move pourrait être un candidat).

Un des principaux avantages des deuxième et troisième propositions est qu’elles simplifient considérablement les spécifications de la couche d’exécution — en fait, cette idée pourrait être la seule méthode viable, car même des simplifications progressives comme la suppression de SELFDESTRUCT sont très difficiles. Tinygrad a une règle stricte selon laquelle le nombre de lignes de code ne dépasse jamais 10 000 ; la meilleure couche de base de blockchain devrait pouvoir s’adapter à ces limites, voire être plus petite. Les efforts de Beam Chain ont de grandes chances de simplifier considérablement la couche de consensus d’Ethereum. Mais pour la couche d’exécution, un changement aussi radical pourrait être la seule voie viable pour obtenir des bénéfices similaires.