[Nouveau long thread en anglais] Le nouveau parcours d’Ethereum : vers 10 000 TPS et la vision ultime du « ZK Everything »

Chainfeeds Guide :

Ethereum se prépare à la transformation architecturale la plus importante depuis son lancement : remplacer l’EVM par RISC-V. La raison est simple : dans un futur dominé par le ZK, l’EVM est devenu le principal goulot d’étranglement.

Source de l’article :

https://x.com/0xJaehaerys/status/1960051628129865918

Auteur de l’article :

jaehaerys

Opinion :

jaehaerys : Ethereum se trouve à un tournant architectural majeur depuis sa genèse : remplacer la machine virtuelle Ethereum (EVM) par RISC-V. La raison fondamentale de ce changement est que, dans l’ère des preuves à connaissance nulle (ZK), l’EVM est devenu le principal goulot d’étranglement. Actuellement, le fonctionnement du zkEVM consiste à recompiler d’abord l’interpréteur EVM en RISC-V, puis à effectuer la preuve, ce qui entraîne une perte de performance de 50 à 800 fois. Alors que d’autres éléments comme les fonctions de hachage ont déjà été optimisés, la preuve d’exécution des blocs devient progressivement la partie la plus chronophage, et l’inefficacité de l’EVM est ainsi amplifiée. Vitalik a souligné qu’au lieu d’ajouter une couche EVM supplémentaire, il vaudrait mieux exposer directement RISC-V, éliminant ainsi la couche d’interprétation redondante. Parallèlement, les « contrats précompilés » sur lesquels Ethereum s’est longtemps appuyé se sont révélés être une source de dette technique. Ces fonctions codées en dur augmentent la complexité du protocole et les risques de consensus ; chaque ajout nécessite un hard fork, ce qui ralentit l’innovation. Vitalik a clairement indiqué qu’il fallait suspendre l’introduction de nouveaux precompile et passer à une implémentation RISC-V. De plus, l’architecture de pile 256 bits de l’EVM est extrêmement inefficace, surtout lorsque les calculs d’entiers courants dans les scénarios ZK ne nécessitent que 32/64 bits, ce qui amplifie les coûts de 2 à 4 fois. En résumé, les trois problèmes majeurs — goulot d’étranglement de performance, dette de complexité et architecture obsolète — font de la « reconstruction de la couche d’exécution d’Ethereum avec RISC-V » un choix urgent. RISC-V n’est pas un produit spécifique, mais un ensemble ouvert et modulaire de standards d’instructions. Son noyau minimaliste ne comprend qu’environ 47 instructions de base, offrant une sécurité et une vérifiabilité bien supérieures à l’EVM complexe ; son écosystème ouvert signifie également que les développeurs n’ont pas à construire la chaîne d’outils de compilation à partir de zéro, les langages principaux comme Rust, C++ ou Go pouvant être compilés directement vers RISC-V, abaissant considérablement la barrière d’entrée pour les développeurs Ethereum. Plus important encore, l’écosystème ZK a presque atteint un consensus : 9 projets zkVM sur 10 ont choisi RISC-V comme ISA sous-jacente, prouvant que ce standard est devenu la solution unifiée de facto du secteur. Comparé au « Yellow Paper » obscur, RISC-V dispose d’une spécification SAIL formelle et lisible par machine, fournissant une base pour une vérification mathématique de la correction. Par ailleurs, le « mode privilégié » de RISC-V offre une isolation matérielle pour les environnements d’exécution de confiance : les contrats en mode utilisateur doivent appeler le noyau via l’instruction ECALL, établissant ainsi une frontière de sécurité plus solide que le bac à sable logiciel de l’EVM. La migration se fera en trois phases : la première remplacera les precompile par RISC-V dans des scénarios à faible risque ; la deuxième introduira une ère de double VM, où EVM et les contrats RISC-V pourront s’appeler mutuellement ; la troisième sera la « stratégie Rosetta », où l’EVM sera maintenu comme contrat fonctionnant sur RISC-V pour une compatibilité à long terme. Cette évolution progressive garantit la stabilité tout en préparant la simplification finale du protocole. La transition EVM→RISC-V n’est pas seulement une mise à niveau de la couche d’exécution, mais va remodeler l’ensemble de l’écosystème Ethereum. Pour les Rollups, les solutions optimistes (Arbitrum, Optimism) dépendent du recalcul des preuves de fraude sur l’EVM L1 ; une fois l’EVM remplacé, leur modèle devra être entièrement repensé ou risque d’être déconnecté. Les ZK Rollups, quant à eux, bénéficieront d’un avantage stratégique : la plupart des projets utilisent déjà RISC-V en interne, unifiant nativement les environnements d’exécution L1 et L2, permettant des « Rollups natifs » avec des règlements efficaces et sans couture sur L1, réduisant les coûts de preuve. Pour les développeurs, Rust, Go, Python et d’autres langages pourront s’exécuter directement sur L1, élargissant radicalement les frontières du développement de smart contracts ; pour les utilisateurs, les coûts de preuve pourraient être réduits de cent fois, permettant à Ethereum d’atteindre un « Gigagas L1 » avec des milliers de TPS. À plus long terme, cette transformation s’aligne sur la vision « Lean Ethereum » : rationaliser le consensus, les données et la couche d’exécution pour faire d’Ethereum une couche de confiance minimale et vérifiable pour Internet. L’objectif de Vitalik, « tout ZK-snarkiser », n’est plus un fantasme, mais un plan réalisable grâce à RISC-V. Cela signifie que l’avenir d’Ethereum ne sera plus une « machine virtuelle de smart contracts » au sens traditionnel, mais une base de confiance globale, vérifiable, simple et transparente. [Texte original en anglais]