Le 20 avril, Vitalik Buterin a proposé une importante proposition concernant la couche d'exécution L1 d'Ethereum sur la plateforme Ethereum Magicians. Il a recommandé d'adopter l'architecture RISC-V pour remplacer l'EVM (machine virtuelle Ethereum) actuelle comme langage de machine virtuelle pour écrire des contrats intelligents, visant à améliorer fondamentalement l'efficacité opérationnelle de la couche d'exécution d'Ethereum, à surmonter l'un des principaux goulets d'étranglement de l'évolutivité actuelle, tout en simplifiant considérablement la clarté de la couche d'exécution.
Foresight News a réalisé une traduction complète de cette proposition, dans le but d'aider les lecteurs à comprendre cette idée technique. Voici le contenu traduit du texte original de la proposition :
Cet article propose une idée radicale concernant l'avenir de la couche d'exécution d'Ethereum, dont l'ambition est comparable à celle du plan Beam Chain pour la couche de consensus. Cette proposition vise à améliorer considérablement l'efficacité de la couche d'exécution d'Ethereum, à résoudre l'un des principaux goulots d'étranglement de l'évolutivité et à simplifier de manière significative la couche d'exécution - en fait, cela pourrait être le seul moyen d'atteindre cet objectif.
Concept central : remplacer l'EVM par RISC-V comme langage de machine virtuelle pour la rédaction de contrats intelligents.
Remarque importante :
Le système de comptes, les appels inter-contrats, le stockage et d'autres concepts seront entièrement préservés. Ces conceptions abstraites fonctionnent bien et les développeurs sont habitués à les utiliser. Les codes d'opération tels que SLOAD, SSTORE, BALANCE, CALL seront transformés 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 dans Solidity (ou Vyper), qui s’adaptera à RISC-V en tant que nouveau backend. Parce que les contrats intelligents écrits en Rust sont en fait 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.
Les anciens contrats EVM continueront de fonctionner et seront entièrement compatibles dans les deux sens avec les nouveaux contrats RISC-V. Il existe plusieurs méthodes pour y parvenir, que cet article explorera en détail par la suite.
La VM Nervos CKB a ouvert la voie, elle est essentiellement une réalisation de RISC-V.
Pourquoi faire cela ?
À court terme, les EIP à venir (comme les listes d'accès au niveau des blocs, l'exécution différée, le stockage historique distribué et l'EIP-4444) peuvent résoudre les principaux goulots d'étranglement de l'évolutivité d'Ethereum L1. À moyen terme, davantage de problèmes seront résolus grâce à la non-état et au ZK-EVM. À long terme, les principaux facteurs limitants de l'évolutivité d'Ethereum L1 deviendront :
Stabilité du protocole d'échantillonnage de la disponibilité des données et du stockage historique
Maintenir la demande de compétitivité sur le marché de la production de blocs.
La capacité de preuve de ZK-EVM
Je vais démontrer que remplacer ZK-EVM par RISC-V peut résoudre les goulots d'étranglement clés dans (2) et (3).
Le tableau ci-dessous montre le nombre de cycles nécessaires pour chaque étape de l'exécution de l'EVM par Succinct ZK-EVM :
Explication du graphique : Les quatre principales étapes de traitement sont deserialize_inputs, initialize_witness_db, state_root_computation et block_execution.
Parmi eux, initialize_witness_db et state_root_computation sont liés à l'arbre d'état, tandis que deserialize_inputs concerne le processus de conversion des données de bloc et de témoignage en représentation interne - en fait, plus de 50 % sont proportionnels à la taille des données de témoignage.
Ces sections peuvent être grandement optimisées en remplaçant l’arbre patricia de Merkle keccak 16-ary actuel par un arbre binaire qui utilise une fonction de hachage facile à prouver. Si nous utilisons Poséidon, nous pouvons prouver 2 millions de hachages par seconde sur un ordinateur portable (à titre de comparaison, keccak est d’environ 15 000 hachages/sec). 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 l’accumulation_logs_bloom en supprimant la floraison.
Le block_execution restant représente environ la moitié du cycle de preuve actuel (prover cycles). Pour réaliser une amélioration de 100 fois de l'efficacité globale de la preuve, l'efficacité de la preuve EVM doit être améliorée d'au moins 50 fois. L'une des solutions consiste à créer une implémentation de preuve plus efficace pour l'EVM, une autre solution consiste à noter que l'actuel prouveur ZK-EVM prouve en réalité en compilant l'EVM en RISC-V, permettant ainsi aux développeurs de contrats intelligents d'accéder directement à cette machine virtuelle RISC-V.
Certaines données montrent que l'augmentation de l'efficacité peut dépasser 100 fois dans des cas spécifiques :
Dans les applications réelles, le temps de prover restant peut être principalement occupé par les opérations de précompilation (precompiles) actuelles. Si RISC-V est utilisé comme principale machine virtuelle, le calendrier de gas reflétera le temps de preuve réel, et la pression économique incitera les développeurs à réduire l'utilisation des précompilations coûteuses. Même ainsi, les gains ne seront pas aussi significatifs, mais nous avons de bonnes raisons de croire que ces gains seront très considérables.
(Il convient de noter que dans l'exécution EVM régulière, la répartition du temps entre les "opérations EVM" et les "autres opérations" est également proche de 50/50. Par conséquent, nous pensons intuitivement que le retrait de l'EVM en tant que "couche intermédiaire" apportera des gains significatifs similaires.)
Détails de mise en œuvre
Cette proposition a plusieurs modes de mise en œuvre. La solution la moins destructrice consiste à prendre en charge simultanément deux machines virtuelles, permettant aux contrats de choisir l'un ou l'autre pour leur rédaction. Les deux types de contrats peuvent accéder aux mêmes fonctionnalités : stockage persistant (SLOAD/SSTORE), capacité à détenir un solde ETH, initier / recevoir des appels, etc. Les contrats EVM et RISC-V peuvent s'appeler mutuellement - du point de vue de RISC-V, appeler un contrat EVM équivaut à exécuter un appel système avec des paramètres spéciaux ; tandis que le contrat EVM qui reçoit un message l'interprète comme un CALL.
Une approche plus radicale du point de vue du protocole consiste à convertir les contrats EVM existants en contrats d'interpréteur EVM écrits en RISC-V, exécutant leur code EVM existant. Autrement dit, si un contrat EVM a un code C, et que l'interpréteur EVM est situé à l'adresse X, alors ce contrat sera remplacé par une logique de niveau supérieur, qui, lorsqu'elle est appelée depuis l'extérieur avec les paramètres d'appel D, appelle X et transmet (C, D), puis attend la valeur de retour et la transfère. Si l'interpréteur EVM lui-même appelle ce contrat, demandant d'exécuter CALL ou SLOAD/SSTORE, alors le contrat exécute ces opérations.
La solution de compromis consiste à adopter la deuxième option, mais en précisant par accord le soutien au concept de « interpréteur de machine virtuelle », exigeant que sa logique soit écrite en RISC-V. L'EVM sera le premier exemple, et à l'avenir, d'autres langages pourront également être pris en charge (Move pourrait être une option candidate).
Les principaux avantages des deuxième et troisième propositions résident dans le fait qu'elles peuvent grandement simplifier les spécifications de la couche d'exécution. Étant donné que même la suppression de SELFDESTRUCT représente un défi considérable pour une simplification progressive, cette approche pourrait être le seul chemin de simplification réalisable. Tinygrad adhère à la règle stricte « ne pas dépasser 10 000 lignes de code », tandis qu'une blockchain de base optimale devrait pouvoir respecter cette limite avec aisance et aller encore plus loin dans la simplification. Le projet Beam Chain devrait considérablement simplifier la couche de consensus d'Ethereum, tandis que pour que la couche d'exécution puisse réaliser une amélioration similaire, cette réforme radicale pourrait être le seul chemin viable.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Texte complet de la proposition à long terme de Vitalik pour la couche exécutive L1 : remplacer l’EVM par RISC-V
Source : Vitalik Buterin
Traduit par : KarenZ, Foresight News
Le 20 avril, Vitalik Buterin a proposé une importante proposition concernant la couche d'exécution L1 d'Ethereum sur la plateforme Ethereum Magicians. Il a recommandé d'adopter l'architecture RISC-V pour remplacer l'EVM (machine virtuelle Ethereum) actuelle comme langage de machine virtuelle pour écrire des contrats intelligents, visant à améliorer fondamentalement l'efficacité opérationnelle de la couche d'exécution d'Ethereum, à surmonter l'un des principaux goulets d'étranglement de l'évolutivité actuelle, tout en simplifiant considérablement la clarté de la couche d'exécution.
Foresight News a réalisé une traduction complète de cette proposition, dans le but d'aider les lecteurs à comprendre cette idée technique. Voici le contenu traduit du texte original de la proposition :
Cet article propose une idée radicale concernant l'avenir de la couche d'exécution d'Ethereum, dont l'ambition est comparable à celle du plan Beam Chain pour la couche de consensus. Cette proposition vise à améliorer considérablement l'efficacité de la couche d'exécution d'Ethereum, à résoudre l'un des principaux goulots d'étranglement de l'évolutivité et à simplifier de manière significative la couche d'exécution - en fait, cela pourrait être le seul moyen d'atteindre cet objectif.
Concept central : remplacer l'EVM par RISC-V comme langage de machine virtuelle pour la rédaction de contrats intelligents.
Remarque importante :
Le système de comptes, les appels inter-contrats, le stockage et d'autres concepts seront entièrement préservés. Ces conceptions abstraites fonctionnent bien et les développeurs sont habitués à les utiliser. Les codes d'opération tels que SLOAD, SSTORE, BALANCE, CALL seront transformés 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 dans Solidity (ou Vyper), qui s’adaptera à RISC-V en tant que nouveau backend. Parce que les contrats intelligents écrits en Rust sont en fait 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.
Les anciens contrats EVM continueront de fonctionner et seront entièrement compatibles dans les deux sens avec les nouveaux contrats RISC-V. Il existe plusieurs méthodes pour y parvenir, que cet article explorera en détail par la suite.
La VM Nervos CKB a ouvert la voie, elle est essentiellement une réalisation de RISC-V.
Pourquoi faire cela ?
À court terme, les EIP à venir (comme les listes d'accès au niveau des blocs, l'exécution différée, le stockage historique distribué et l'EIP-4444) peuvent résoudre les principaux goulots d'étranglement de l'évolutivité d'Ethereum L1. À moyen terme, davantage de problèmes seront résolus grâce à la non-état et au ZK-EVM. À long terme, les principaux facteurs limitants de l'évolutivité d'Ethereum L1 deviendront :
Stabilité du protocole d'échantillonnage de la disponibilité des données et du stockage historique
Maintenir la demande de compétitivité sur le marché de la production de blocs.
La capacité de preuve de ZK-EVM
Je vais démontrer que remplacer ZK-EVM par RISC-V peut résoudre les goulots d'étranglement clés dans (2) et (3).
Le tableau ci-dessous montre le nombre de cycles nécessaires pour chaque étape de l'exécution de l'EVM par Succinct ZK-EVM :
Explication du graphique : Les quatre principales étapes de traitement sont deserialize_inputs, initialize_witness_db, state_root_computation et block_execution.
Parmi eux, initialize_witness_db et state_root_computation sont liés à l'arbre d'état, tandis que deserialize_inputs concerne le processus de conversion des données de bloc et de témoignage en représentation interne - en fait, plus de 50 % sont proportionnels à la taille des données de témoignage.
Ces sections peuvent être grandement optimisées en remplaçant l’arbre patricia de Merkle keccak 16-ary actuel par un arbre binaire qui utilise une fonction de hachage facile à prouver. Si nous utilisons Poséidon, nous pouvons prouver 2 millions de hachages par seconde sur un ordinateur portable (à titre de comparaison, keccak est d’environ 15 000 hachages/sec). 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 l’accumulation_logs_bloom en supprimant la floraison.
Le block_execution restant représente environ la moitié du cycle de preuve actuel (prover cycles). Pour réaliser une amélioration de 100 fois de l'efficacité globale de la preuve, l'efficacité de la preuve EVM doit être améliorée d'au moins 50 fois. L'une des solutions consiste à créer une implémentation de preuve plus efficace pour l'EVM, une autre solution consiste à noter que l'actuel prouveur ZK-EVM prouve en réalité en compilant l'EVM en RISC-V, permettant ainsi aux développeurs de contrats intelligents d'accéder directement à cette machine virtuelle RISC-V.
Certaines données montrent que l'augmentation de l'efficacité peut dépasser 100 fois dans des cas spécifiques :
Dans les applications réelles, le temps de prover restant peut être principalement occupé par les opérations de précompilation (precompiles) actuelles. Si RISC-V est utilisé comme principale machine virtuelle, le calendrier de gas reflétera le temps de preuve réel, et la pression économique incitera les développeurs à réduire l'utilisation des précompilations coûteuses. Même ainsi, les gains ne seront pas aussi significatifs, mais nous avons de bonnes raisons de croire que ces gains seront très considérables.
(Il convient de noter que dans l'exécution EVM régulière, la répartition du temps entre les "opérations EVM" et les "autres opérations" est également proche de 50/50. Par conséquent, nous pensons intuitivement que le retrait de l'EVM en tant que "couche intermédiaire" apportera des gains significatifs similaires.)
Détails de mise en œuvre
Cette proposition a plusieurs modes de mise en œuvre. La solution la moins destructrice consiste à prendre en charge simultanément deux machines virtuelles, permettant aux contrats de choisir l'un ou l'autre pour leur rédaction. Les deux types de contrats peuvent accéder aux mêmes fonctionnalités : stockage persistant (SLOAD/SSTORE), capacité à détenir un solde ETH, initier / recevoir des appels, etc. Les contrats EVM et RISC-V peuvent s'appeler mutuellement - du point de vue de RISC-V, appeler un contrat EVM équivaut à exécuter un appel système avec des paramètres spéciaux ; tandis que le contrat EVM qui reçoit un message l'interprète comme un CALL.
Une approche plus radicale du point de vue du protocole consiste à convertir les contrats EVM existants en contrats d'interpréteur EVM écrits en RISC-V, exécutant leur code EVM existant. Autrement dit, si un contrat EVM a un code C, et que l'interpréteur EVM est situé à l'adresse X, alors ce contrat sera remplacé par une logique de niveau supérieur, qui, lorsqu'elle est appelée depuis l'extérieur avec les paramètres d'appel D, appelle X et transmet (C, D), puis attend la valeur de retour et la transfère. Si l'interpréteur EVM lui-même appelle ce contrat, demandant d'exécuter CALL ou SLOAD/SSTORE, alors le contrat exécute ces opérations.
La solution de compromis consiste à adopter la deuxième option, mais en précisant par accord le soutien au concept de « interpréteur de machine virtuelle », exigeant que sa logique soit écrite en RISC-V. L'EVM sera le premier exemple, et à l'avenir, d'autres langages pourront également être pris en charge (Move pourrait être une option candidate).
Les principaux avantages des deuxième et troisième propositions résident dans le fait qu'elles peuvent grandement simplifier les spécifications de la couche d'exécution. Étant donné que même la suppression de SELFDESTRUCT représente un défi considérable pour une simplification progressive, cette approche pourrait être le seul chemin de simplification réalisable. Tinygrad adhère à la règle stricte « ne pas dépasser 10 000 lignes de code », tandis qu'une blockchain de base optimale devrait pouvoir respecter cette limite avec aisance et aller encore plus loin dans la simplification. Le projet Beam Chain devrait considérablement simplifier la couche de consensus d'Ethereum, tandis que pour que la couche d'exécution puisse réaliser une amélioration similaire, cette réforme radicale pourrait être le seul chemin viable.