jakiro
Source: Vitalik Buterin, Magiciens Ethereum; Compilation: Tao Zhu, Vision de Bitchain
Cet article présente une idée agressive pour l’avenir de la couche d’exécution d’Ethereum, qui est aussi ambitieuse que les efforts de la chaîne de faisceau vers la couche consensuelle.Il vise à augmenter considérablement l’efficacité de la couche d’exécution Ethereum, à résoudre l’un des principaux goulots d’étranglement de mise à l’échelle et à améliorer considérablement la simplicité de la couche d’exécution – en fait, c’est peut-être le seul moyen.
Idée: utilisez RISC-V comme langage de machine virtuelle pour rédiger des contrats SMART EVM.
Clarification importante:
-
Les concepts de comptes, d’appels transversaux, de stockage, etc. resteront exactement les mêmes. Ces abstractions fonctionnent bien et les développeurs s’y habituent. SLOAD, SSTORE, Balance, Call et autres OPCodes deviendront des appels du système RISC-V.
-
Dans un monde comme celui-ci, les contrats intelligents peuvent être écrits en rouille, mais je m’attends à ce que la plupart des développeurs continuent d’écrire des contrats intelligents dans Solidity (ou Vyper), qui s’adaptera à l’ajout de RISC-V comme backend. En effet, les contrats intelligents écrits en rouille sont en fait assez laids, tandis que la solidité et le vyper sont beaucoup plus lisibles. Peut-être que le changement de Devex est petit et que les développeurs peuvent à peine remarquer ce changement.
-
Les contrats EVM à l’ancienne continueront d’être valides et seront entièrement bidirectionnels interopérables avec les nouveaux contrats RISC-V. Il existe plusieurs façons de le faire, que je couvrirai plus tard dans cet article.
Un précédent est la VM CKB nerveuse, qui est essentiellement RISC-V.
Pourquoi faire ça?
À court terme, les principaux goulots d’étranglement de l’évolutivité de Ethereum L1 seront traités avec les EIP à venir tels que les listes d’accès au niveau des blocs, l’exécution de latence et le stockage historique distribué et l’EIP-4444. À moyen terme, nous aborderons d’autres problèmes sans état et ZK-EVM. À long terme, les principaux facteurs limitants de l’expansion de la couche Ethereum sont:
-
Échantillonnage de disponibilité des données et stabilité des protocoles de stockage historiques
-
J’espère garder le marché de la production de blocs compétitif
-
Capacité de vérification ZK-EVM
Je pense que le remplacement de ZK-EVM par RISC-V peut résoudre un goulot d’étranglement clé en (2) et (3).
Il s’agit du nombre de boucles utilisées par le ZK-EVM succinct pour prouver 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 sont tous deux liés aux arbres d’État, et Deserialize_inputs fait référence au processus de conversion des blocs et de témoins en représentations internes; Par conséquent, en fait, plus de 50% sont proportionnels à l’échelle des témoins.
Ces pièces peuvent être fortement optimisées en remplaçant l’arbre actuel de Merkle Patricia Keccak à 16 membres par un arbre binaire qui utilise des fonctions de hachage amicales. Si nous utilisons Poséidon, nous pouvons prouver 2 millions de hachages par seconde sur notre ordinateur portable (et les hachages de Keccak environ 15 000 hachages par seconde). Il existe de nombreuses autres options en plus de Poséidon. Dans l’ensemble, nous avons la possibilité de réduire considérablement ces composants. En prime, nous pouvons nous débarrasser de Accume_logs_bloom en se débarrassant de Bloom.
Le reste est block_execution, qui représente environ la moitié du cycle de preuve passé aujourd’hui. Si nous voulons augmenter l’efficacité globale du prover de 100 fois, nous ne pouvons pas éviter le fait que nous devons augmenter l’efficacité du prover 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 dans les cycles de preuve. Une autre chose que nous pouvons faire est de noter que le prover ZK-EVM a fonctionné aujourd’hui en prouvant que la mise en œuvre EVM compilée dans RISC-V et donne aux développeurs de contrats intelligents un accès direct à ce RISC-V VM.
Certaines données suggèrent que cela peut augmenter l’efficacité de plus de 100 fois dans des cas limités:
En fait, je m’attends à ce que le temps de preuve restant soit dominé par la précompilation d’aujourd’hui. Si nous utilisons RISC-V comme principale machine virtuelle, le plan de gaz reflétera le temps de preuve, il y aura donc une pression économique pour cesser d’utiliser des précompilateurs plus chers; Mais même ainsi, les avantages ne seront pas si impressionnants, mais nous avons de bonnes raisons de croire que les avantages seront très importants.
(Soit dit en passant, la division d’environ 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 que les avantages de l’élimination de l’EVM en tant que « l’intermédiaire » devraient être tout aussi importants)
Détails de la mise en œuvre
Il existe plusieurs façons de mettre en œuvre de telles suggestions. L’approche la moins perturbatrice consiste à prendre en charge deux machines virtuelles et à permettre l’écriture de contrats dans l’une ou l’autre machine virtuelle. Les deux types de contrats peuvent utiliser le même type d’installations: stockage persistant (Sload et SSTORE), la possibilité de maintenir les soldes d’ETH, la possibilité de passer et de recevoir des appels, etc. Les contrats EVM et RISC-V sont libres de s’appeler les uns les autres; Du point de vue RISC-V, appeler le contrat EVM semble faire un appel système avec des paramètres spéciaux; Le contrat EVM recevant le message l’interprète comme un appel.
Du point de vue du protocole, une approche plus radicale consiste à convertir un contrat EVM existant en un contrat qui appelle un contrat d’interprète EVM écrit dans RISC-V, qui exécute son code EVM existant. Autrement dit, si le contrat EVM a le code C et l’interprète EVM est à l’adresse X, le contrat sera remplacé par une logique de niveau supérieur, lorsqu’il est appelé depuis l’extérieur en utilisant le paramètre d’appel D, X est appelé avec (C, D), puis attendez la valeur de retour et le transfert. Si l’interprète EVM lui-même appelle le contrat et nécessite un appel en cours d’exécution ou SLOAD / SSTORE, le contrat le fait.
L’itinéraire intermédiaire consiste à prendre la deuxième option, mais à créer une fonction de protocole claire pour elle – en gros, le concept de « interprète de machine virtuelle » est considéré comme un guide et sa logique doit être écrite dans RISC-V. L’EVM sera le premier, mais il peut y en avoir d’autres (par exemple, le déménagement peut être un candidat).
L’un des principaux avantages des deuxième et troisième propositions est qu’ils simplifient considérablement les spécifications de la couche d’exécution – en fait, cette idée peut être la seule approche viable, car même une simplification progressive comme l’élimination de l’autodestruction est très difficile. Tinygrad a une règle stricte selon laquelle le volume de code ne dépasse jamais 10 000 lignes; La meilleure couche de fondation blockchain devrait être capable de bien s’adapter à ces limites, encore plus petites. Les efforts de la chaîne de faisceaux ont un grand espoir de simplifier considérablement la couche consensuelle d’Ethereum. Mais pour la couche d’exécution, ce changement radical peut être le seul moyen viable d’obtenir des avantages similaires.
