Texte complet de la proposition à long terme de Vitalik pour la couche exécutive L1 : remplacement de l’EVM par RISC-V

Source : Vitalik Buterin

Compilation : KarenZ, Foresight News

Le 20 avril, Vitalik Buterin a présenté une proposition importante sur la plateforme Ethereum Magicians pour la couche d’exécution L1 à long terme d’Ethereum. Il a proposé de remplacer l’EVM (Ethereum Virtual Machine) existant par l’architecture RISC-V en tant que langage de machine virtuelle pour l’écriture de contrats intelligents, dans le but d’améliorer fondamentalement l’efficacité opérationnelle de la couche d’exécution d’Ethereum, de briser l’un des principaux goulets d’étranglement actuels et de simplifier considérablement la simplicité de la couche d’exécution.

Foresight News a compilé le texte intégral de la proposition pour aider les lecteurs à comprendre cette vision technique. Ce qui suit est une compilation de la proposition originale :

Cet article présente une idée radicale sur l’avenir de la couche d’exécution d’Ethereum, non moins ambitieuse que les initiatives de chaîne de faisceaux de la couche de consensus. La proposition vise à améliorer considérablement l’efficacité de la couche d’exécution d’Ethereum, à résoudre l’un des principaux goulets d’étranglement de la mise à l’échelle et à simplifier considérablement la couche d’exécution – en fait, c’est peut-être la seule façon d’y parvenir.

Idée centrale : Remplacer EVM par RISC-V en tant que langage de machine virtuelle pour les contrats intelligents.

Notes importantes :

• Des concepts tels que le système de compte, les appels intercontractuels, le stockage, etc., seront entièrement conservés. Ces conceptions abstraites fonctionnent bien et les développeurs ont l’habitude de les utiliser. LES OPCODES TELS QUE SLOAD, SSTORE, BALANCE, CALL, ETC., SONT CONVERTIS EN APPELS SYSTÈME RISC-V.

• Dans ce mode, les contrats intelligents peuvent être écrits en Rust, mais je m’attends à ce que la plupart des développeurs continuent à écrire des contrats en Solidity (ou Vyper), qui s’adaptera à RISC-V en tant que nouveau backend. Parce que les contrats intelligents écrits en Rust sont en réalité moins lisibles, tandis que Solidity et Vyper sont plus clairs et plus faciles à lire. L’expérience de développement peut être à peine affectée, et les développeurs peuvent même ne pas remarquer le changement.

• L’ancien contrat EVM continuera de fonctionner et est entièrement compatible bidirectionnellement avec le nouveau contrat RISC-V. Il existe plusieurs façons de procéder, qui seront abordées plus en détail plus loin dans cet article.

Nervos CKB VM a créé un précédent et est essentiellement une implémentation RISC-V.

Pourquoi?

À court terme, les prochains EIP (par exemple, les listes d’accès au niveau des blocs, l’exécution différée, le stockage d’historique distribué et l’EIP-4444) permettront de résoudre les principaux goulets d’étranglement de la mise à l’échelle d’Ethereum L1. D’autres problèmes seront résolus à moyen terme avec l’apatridie et la ZK-EVM. À long terme, les principaux facteurs limitant la mise à l’échelle d’Ethereum L1 deviendront :

1. Stabilité de la disponibilité des données, de l’échantillonnage et des protocoles de stockage historiques

2. Maintenir la demande de concurrence sur le marché de la production de blocs

3. Preuve du ZK-EVM

Je soutiendrai que le remplacement de ZK-EVM par RISC-V peut résoudre les principaux goulets d’étranglement en (2) et (3).

Le tableau suivant illustre le nombre de cycles requis pour chaque étape de la couche d’exécution EVM Succinct ZK-EVM Proof :

Description du diagramme : Les quatre principaux segments chronophages sont deserialize_inputs, initialize_witness_db, state_root_computation et block_execution

initialize_witness_db et state_root_computation sont liés à des arbres d’état, et deserialize_inputs impliquent le processus de conversion des données de bloc et de témoin en représentations internes – dont plus de 50 % sont en fait proportionnels à la taille des données témoins.

Ces sections peuvent être considérablement optimisées en remplaçant l’arbre actuel de Merkle patricia keccak 16-ary par un arbre binaire qui utilise une fonction de hachage facile à prouver. Si nous utilisons Poseidon, nous pouvons prouver 2 millions de hachages par seconde sur un ordinateur portable (contre environ 15 000 hachages/s pour keccak). En plus de Poséidon, il existe de nombreuses autres options. Dans l’ensemble, il y a beaucoup de place pour l’optimisation de ces composants. De plus, nous pouvons éliminer accrue_logs_bloom en supprimant la floraison.

Les block_execution restants représentent environ la moitié des cycles actuels d’étalonnage. Pour obtenir une augmentation de 100 fois de l’efficacité globale de l’épreuve, une efficacité d’épreuve EVM d’au moins 50 fois est requise. Une solution consiste à créer une implémentation de preuve plus efficace pour l’EVM, et l’autre consiste à remarquer que le démonstrateur ZK-EVM actuel compile en fait l’EVM en RISC-V pour preuve, donnant aux développeurs de contrats intelligents un accès direct à la machine virtuelle RISC-V.

Certaines données montrent que des gains d’efficacité de plus de 100 fois peuvent se produire dans certaines situations :

En pratique, le temps de démonstration restant peut être principalement occupé par l’opération de précompilation en cours. Avec RISC-V comme VM principal, le calendrier de gaz reflétera le temps d’épreuve réel, et la pression économique poussera les développeurs à réduire l’utilisation de la précompilation à coût élevé. Même dans ce cas, les gains ne seront pas aussi importants, mais nous avons de bonnes raisons de croire qu’ils seront substantiels.

(Il convient de noter que le temps nécessaire pour les « opérations EVM » et les « autres opérations » dans l’exécution régulière de l’EVM est également proche de 50/50, nous supposons donc intuitivement que la suppression de l’EVM en tant que « couche intermédiaire » apportera un gain tout aussi significatif.)

Détails de la mise en œuvre

Il y a plusieurs façons de mettre en œuvre cette proposition. La solution la moins disruptive est de prendre en charge les deux machines virtuelles et de permettre la rédaction du contrat dans l’une d’entre elles. Les deux types de contrats ont accès aux mêmes fonctionnalités : le stockage persistant (SLOAD/SSTORE), la possibilité de conserver des soldes ETH, d’initier/recevoir des appels, etc. Les contrats EVM et RISC-V peuvent être appelés l’un à l’autre - du point de vue RISC-V, l’appel du contrat EVM équivaut à l’exécution d’un appel système avec des paramètres spéciaux ; Le contrat EVM qui reçoit le message l’interprétera comme un CALL.

Une approche plus radicale du point de vue du protocole consiste à convertir un contrat EVM existant en un appel à un contrat d’interpréteur EVM écrit en RISC-V pour exécuter son code EVM existant. C’est-à-dire que si un contrat EVM a le code C et que l’interpréteur EVM se trouve à l’adresse X, le contrat sera remplacé par une logique de niveau supérieur qui, lorsqu’elle est appelée de l’extérieur avec un argument d’appel D, appelle X et passe (C, D), puis attend la valeur de retour et transfère. Si l’interpréteur EVM appelle lui-même le contrat en demandant d’exécuter CALL ou SLOAD/SSTORE, le contrat effectue ces opérations.

Le compromis est la deuxième option, mais avec un support explicite du concept d’un « interpréteur de machine virtuelle » à travers un protocole qui nécessite que sa logique soit écrite en RISC-V. EVM sera la première instance, avec la prise en charge d’autres langues à l’avenir (Move pourrait être un candidat).

Le principal avantage des deuxième et troisième options est qu’elles simplifient considérablement la spécification de la couche d’exécution. ÉTANT DONNÉ LA DIFFICULTÉ MÊME D’ÉLIMINER LES SIMPLIFICATIONS INCRÉMENTIELLES COMME L’AUTODESTRUCTION, CETTE LIGNE DE PENSÉE EST PEUT-ÊTRE LA SEULE VOIE VIABLE POUR SIMPLIFIER. Tinygrad adhère à la règle stricte de « pas plus de 10 000 lignes de code », et la blockchain optimale sous-jacente devrait être en mesure de répondre facilement à cette limite et de la rationaliser davantage. L’initiative Beam Chain promet de simplifier considérablement la couche de consensus d’Ethereum, et un changement aussi radical pourrait être le seul moyen d’obtenir une augmentation similaire au niveau de l’exécution.