Ce post propose une idée radicale pour l'avenir de la couche d'exécution d'Ethereum, aussi ambitieuse que l'effort de la chaîne de faisceaux pour la couche de consensus. Elle vise à améliorer considérablement l'efficacité de la couche d'exécution d'Ethereum, à résoudre l'un des principaux goulots d'étranglement à l'échelle, et peut également grandement améliorer la simplicité de la couche d'exécution - en fait, c'est peut-être la seule façon de le faire.

L'idée : remplacer l'EVM par RISC-V en tant que langage de machine virtuelle dans lequel les contrats intelligents sont écrits.

Clarifications importantes :

• Les concepts de comptes, d'appels entre contrats, de stockage, etc. resteraient exactement les mêmes. Ces abstractions fonctionnent bien et les développeurs y sont habitués. Les opcodes tels que SLOAD, SSTORE, BALANCE, CALL, etc. deviendraient des appels système RISC-V.
• Dans un tel monde, les contrats intelligents pourraient être écrits en Rust, mais je m'attends à ce que la plupart des développeurs continuent d'écrire des contrats intelligents en Solidity (ou Vyper), qui s'adapteraient pour ajouter RISC-V en tant que backend. Cela est dû au fait que les contrats intelligents écrits en Rust sont en faitassezlaid, et Solidity et Vyper sont beaucouppluslisiblePotentiellement, devex changerait très peu et les développeurs pourraient à peine remarquer le changement.
• Les contrats EVM de style ancien continueront de fonctionner et seront entièrement interopérables dans les deux sens avec les contrats RISC-V de style nouveau. Il existe quelques façons de le faire, sur lesquelles je reviendrai plus tard dans ce post.

Un précédent pour cela est le Nervos CKB VM, qui est fondamentalement RISC-V.

Pourquoi faire cela?

À court terme, les principaux goulets d'étranglement de la scalabilité d'Ethereum L1 sont abordés avec les prochaines EIP comme listes d'accès au niveau du bloc, exécution différéeet stockage d'historique distribué plusEIP-4444. À moyen terme, nous abordons d'autres problèmes avec apatridieetZK-EVMsÀ long terme, les principaux facteurs limitants de la mise à l'échelle d'Ethereum L1 deviennent :

1. Stabilité des protocoles d'échantillonnage de disponibilité des données et de stockage de l'historique
2. Désir de maintenir la production de blocs comme un marché concurrentiel
3. Capacités de preuve ZK-EVM

Je vais soutenir que remplacer le ZK-EVM par RISC-V résout un goulot d'étranglement clé dans (2) et (3).

Il s'agit d'un tableau du nombre de cycles que le Succinct ZK-EVM utilise pour prouver les différentes parties de la couche d'exécution EVM :

Il y a quatre parties qui prennent beaucoup de temps : deserialize_inputs, initialize_witness_db, state_root_computation et block_execution.

initialize_witness_db et state_root_computation ont tous deux à voir avec l'arbre d'état, et deserialize_inputs fait référence au processus de conversion des données de bloc et de témoin en une représentation interne; par conséquent, réaliste plus de 50% est proportionnel aux tailles de témoin.

Ces parties peuvent être fortement optimisées en remplaçant l'actuel arbre patricia Merkle 16-aires de keccak par un arbre binaire qui utilise une fonction de hachage conviviale pour le prouveur. Si nous utilisons Poseidon, nous pouvons prouver 2 millions de hachages par secondesur un ordinateur portable (par rapport à ~15 000 hachages/s pour keccak). Il existe également de nombreuses options autres que Poseidon. Dans l'ensemble, il y a des opportunités pour réduire massivement ces composants. En prime, nous pouvons nous débarrasser de accrue_logs_bloom en, eh bien,se débarrasser de la floraison.

Cela laisse l'exécution de bloc, qui représente environ la moitié des cycles de vérification dépensés aujourd'hui. Si nous voulons augmenter l'efficacité totale du vérificateur de 100 fois, il n'y a pas moyen de contourner le fait que nous devons au moins augmenter l'efficacité du vérificateur EVM de 50 fois. Une chose que nous pourrions faire est d'essayer de créer des implémentations de l'EVM beaucoup plus efficaces en termes de cycles de vérification. L'autre chose que nous pouvons faire est de remarquer que les vérificateurs ZK-EVM travaillent déjà aujourd'hui en prouvant sur des implémentations de l'EVM compilées en RISC-V, et donnent aux développeurs de contrats intelligents un accès direct à ce RISC-V VM.

Certains chiffres suggèrent que dans des cas limités, cela pourrait entraîner des gains d'efficacité de plus de 100 fois :

En pratique, je m'attends à ce que le temps restant du prouveur soit dominé par ce qui sont aujourd'hui des précompilations. Si nous faisons de RISC-V le principal VM, alors le calendrier des gaz reflétera les temps de preuve, et il y aura donc une pression économique pour arrêter d'utiliser des précompilations plus coûteuses; mais même ainsi, les gains ne seront pas tout à fait aussi impressionnants, mais nous avons de bonnes raisons de croire qu'ils seront très significatifs.

(Soit dit en passant, la répartition approximative de 50/50 entre “EVM” et “autres choses” apparaît également dans l'exécution régulière de l'EVM, et nous nous attendons intuitivement à ce que les gains de l'élimination de l'EVM en tant que « l'intermédiaire » soient également importants)

Détails de mise en œuvre

Il existe plusieurs façons de mettre en œuvre ce type de proposition. La moins perturbatrice consiste à prendre en charge deux VM et à permettre aux contrats d'être rédigés dans l'une ou l'autre. Les deux types de contrats auraient accès aux mêmes types de fonctionnalités : stockage persistant (SLOAD et SSTORE), la possibilité de détenir des soldes ETH, la capacité de passer et de recevoir des appels, etc. Les contrats EVM et RISC-V seraient libres de s'appeler mutuellement ; du point de vue de RISC-V, appeler un contrat EVM semblerait, de son point de vue, être un appel système avec certains paramètres spéciaux ; le contrat EVM recevant le message l'interpréterait comme étant un CALL.

Une approche plus radicale d'un point de vue de protocole consiste à convertir les contrats EVM existants en contrats qui appellent un contrat interprète EVM écrit en RISC-V qui exécute leur code EVM existant. Autrement dit, si un contrat EVM a le code C et que l'interprète EVM se trouve à l'adresse X, alors le contrat est remplacé par une logique de niveau supérieur qui, lorsqu'elle est appelée de l'extérieur avec des paramètres d'appel D, appelle X avec (C, D), puis attend la valeur de retour et la transmet. Si l'interprète EVM lui-même appelle le contrat, demandant d'exécuter un CALL ou un SLOAD/SSTORE, alors le contrat le fait.

Une route intermédiaire consiste à choisir la deuxième option, mais à créer une fonctionnalité de protocole explicite pour cela - en gros, consacrer le concept d'un "interprète de machine virtuelle", et exiger que sa logique soit écrite en RISC-V. L'EVM serait le premier, mais il pourrait y en avoir d'autres (par exemple, Move pourrait être un candidat).

Un avantage clé de la deuxième et de la troisième proposition est qu'elles simplifient considérablement la spécification de la couche d'exécution - en effet, ce type d'idée pourrait être le seul moyen pratique de le faire, étant donné la grande difficulté des simplifications même progressives comme la suppression de SELFDESTRUCT. Tinygrad a la règle dure dene jamais dépasser 10000 lignes de code; une couche de base de blockchain optimale devrait pouvoir s'intégrer parfaitement dans ces marges et même devenir encore plus petite. L'effort de la chaîne beam promet de simplifier considérablement la couche de consensus d'Ethereum. Mais pour que la couche d'exécution voie des gains similaires, ce genre de changement radical pourrait être le seul chemin viable.

Clause de non-responsabilité :

1. Cet article est repris de [ Magiciens Ethereum]. Tous les droits d'auteur appartiennent à l'auteur original [Vitalik Buterin]. Si des objections sont formulées à cette réimpression, veuillez contacter le Gate Learnl'équipe et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. L'équipe Gate Learn effectue des traductions de l'article dans d'autres langues. Copier, distribuer ou plagier les articles traduits est interdit sauf mention contraire.