Vitalik Buterin a proposé une refonte à long terme à l’environnement d’exécution d’Ethereum pour remplacer la machine virtuelle Ethereum par RISC-V, une architecture d’instructions standardisée et extensible.
La proposition, partagée dans le Forum des magiciens Ethereum le 20 avril, décrit un changement multi-phases pour améliorer l’efficacité de la prestation et simplifier la couche d’exécution, sans modifier les abstractions de base comme les comptes, le stockage ou les appels transversaux.
Le changement conserverait la solidité et le vyper en tant que langages de développement primaires, qui seraient adaptés à la compilation à RISC-V.
Selon Buterin, bien que la rédaction de contrats directement dans Rust serait techniquement possible, les préoccupations de lisibilité et la familiarité des développeurs avec les langues existantes suggèrent que la rouille ne remplacera pas la solidité de la couche d’application. Les contrats EVM existants continueraient de fonctionner et d’interagir pleinement avec de nouveaux contrats basés sur RISC-V, préservant la compatibilité en arrière.
Goulot d’étranglement d’exécution et échelle à long terme
Buterin a identifié l’exécution comme l’un des derniers goulots d’étranglement à long terme d’Ethereum, après que les problèmes à court terme soient atténués par les EIP tels que l’exécution retardée, les listes d’accès au niveau des blocs et le stockage historique distribué.
En particulier, il a souligné la prouvance des coûts dans ZK-EVM comme la contrainte clé de l’évolutivité future. L’analyse du ZK-EVM de succinct indique que l’exécution de blocs représente à elle seule près de la moitié de tous les cycles de prover, tandis que le reste est consommé par la manipulation des données des témoins et les opérations d’arbres d’État.
Bien que les frais généraux liés à l’État puissent être réduits en passant des arbres Patricia à base de keccak vers des arbres binaires avec des fonctions de hachage optimisées par des prover comme le Poséidon, l’efficacité de l’exécution des blocs restera limite à moins que l’EVM ne soit traité directement.
Buterin a noté que ZK-EVMS se compilait déjà avec RISC-V sous le capot, suggérant que l’exposition RISC-V comme VM primaire pourrait éliminer une couche d’abstraction et des gains d’efficacité du rendement. Certains scénarios de test afficheraient 100x améliorations des performances des prover en contournant complètement la traduction EVM.
COEXISTENCE, MIGMATION ET LES CHAMPS
Plusieurs voies de mise en œuvre sont à l’étude. Le plus conservateur permettrait un double soutien aux contrats EVM et RISC-V, en maintenant des appels interopérables et un accès partagé à l’État persistant. Les contrats EVM continueraient de fonctionner et pourraient appeler ou être appelés par des contrats RISC-V via des appels système mappés à des opcodes traditionnels tels que Call, Sload et SSTORE.
Une approche plus agressive consiste à transformer les contrats EVM existants en emballages qui déléguent l’exécution à un interprète EVM écrit dans RISC-V. Dans le cadre de ce modèle, le bytecode d’un contrat serait remplacé par une logique qui achemine les appels et les paramètres d’exécution à un contrat d’interpréteur RISC-V désigné, reçoit la valeur de retour et le transmet à l’appelant.
Une stratégie intermédiaire propose une prise en charge au niveau du protocole pour les interprètes de machines virtuelles, consacrant ce processus de délégation et permettant à plusieurs formats d’exécution de coexister. Bien que l’EVM serait la première machine virtuelle soutenue sous ce modèle, d’autres, dont Move, pourraient être ajoutées à l’avenir.
Chaque approche cherche à équilibrer la compatibilité avec une simplification à long terme. Selon Buterin, des simplifications incrémentielles à l’EVM, telles que l’élimination de l’autodestruction, se sont révélées difficiles en raison des cas de bord complexes et des comportements hérités.
Une transition complète vers RISC-V pourrait permettre une couche de base plus maintenable avec une logique d’exécution minimale, comparable en compacité à des projets comme Tinygrad qui appliquent des limites de base de code strictes.
Philosophie de conception plus large et alignement avec la chaîne de faisceau
La proposition s’aligne sur les efforts en cours comme l’initiative de la chaîne de faisceau, qui vise à simplifier le mécanisme consensuel d’Ethereum. Le plan RISC-V apporterait des améliorations parallèles à la couche d’exécution, permettant au réseau de poursuivre la modularité et une complexité réduite dans les deux domaines.
Comme affiché sur Ethereum Magiciens, Buterin a qualifié la proposition de radical mais peut-être nécessaire pour réaliser l’efficacité et la simplicité à long terme en L1. Alors que les FPI actifs et les cadres sans état traitent des améliorations d’évolutivité à court et à moyen terme, l’avenir d’Ethereum en tant que protocole performant et durable peut dépendre des changements architecturaux de cette ampleur.
Aucun calendrier n’a été annoncé pour toute phase de mise en œuvre. La communauté Ethereum devrait s’engager dans des discussions plus approfondies pour évaluer les compromis, l’impact de l’outillage et les voies de migration des développeurs dans le cadre d’un cycle de délibération plus long.
La proposition reste exploratoire et vise à ouvrir une conversation plus large sur la direction de l’environnement d’exécution d’Ethereum au cours des prochaines années.
Réponse de la communauté
Certains membres de la communauté ont soulevé des réservations stratégiques et techniques en réponse à la proposition de Buterin. Adam Cochran a remis en question la hiérarchisation de l’efficacité de L1 aux dépens potentiels de l’activation L2, ce qui suggère que la consolidation RISC-V pourrait réduire la feuille de route modulaire d’Ethereum.
Il a souligné des propositions alternatives telles que l’agrégation récursive de preuve, les racines d’engagement sans état et l’unification de signature BLS, qui pourrait potentiellement offrir des gains systémiques plus larges avec moins de coûts de mise en œuvre.
D’autres, dont Ben A Adams, co-fondateur et CTO de Illyriade Games, et Levs57, un développeur Web3, ont souligné les compromis des performances, en particulier autour de la compatibilité matérielle et du rôle persistant des précompiles.
Les préoccupations comprenaient la difficulté d’optimiser les instructions RISC-V de bas niveau dans des opérations efficaces 256 bits et les doutes quant à savoir si les systèmes actuels de ZK-RISC-V sont suffisamment matures ou vérifiables pour justifier un changement fondamental.
Buterin a répondu en minimisant la mesure dans laquelle la taille des mots 256 bits de l’EVM limite l’exécution, indiquant que la plupart des valeurs en pratique sont plus petites, généralement U32, U64 ou U128, que les compilateurs peuvent cartographier efficacement les instructions RISC-V.
Il a réitéré que ZK-EVM d’aujourd’hui fonctionne déjà comme des environnements RISC-V incorporant un interprète EVM, encadrant l’exposition directe de RISC-V comme moyen d’éliminer les couches redondantes. Tout en reconnaissant la gestion de la pile et les sauts comme des points de friction potentiels, il a soutenu que l’élimination des frais généraux d’interprétation reste un gain net.
Mentionné dans cet article
(TagStotranslate) Ethereum (T) Analyse (T) en vedette (T) People (T) web3
