Lorsque Ethereum abandonne l'EVM au profit de RISC-V : La refonte de l'architecture qui pourrait redéfinir l'informatique blockchain

Ethereum se trouve à un point d’inflexion. Alors que la Machine Virtuelle Ethereum (EVM) a alimenté une décennie d’innovation blockchain—créant la base du DeFi et des NFTs—il devient de plus en plus évident que cette couche d’exécution sur mesure n’a pas été conçue pour le futur computationnel qui arrive maintenant. Le passage à la vérification à zéro-connaissance (ZK) et l’émergence d’une structure machine générale dans les standards de programmation système obligent à une remise en question : l’architecture vieillissante d’Ethereum peut-elle s’adapter, ou nécessite-t-elle une réinvention complète ?

Selon les chercheurs techniques et la direction de la Fondation Ethereum, la réponse devient de plus en plus claire. Le protocole trace une voie vers le remplacement de l’EVM par RISC-V, une architecture d’instructions open-source qui promet de débloquer la scalabilité, de réduire la complexité et d’aligner Ethereum avec l’écosystème plus large de l’informatique vérifiable.

La crise de performance dont personne ne parle : pourquoi l’EVM ne peut pas suivre la ZK

Le goulot d’étranglement n’est pas immédiatement évident, mais il est fondamental. Lorsque Ethereum commence à prouver ses transitions d’état via des preuves à zéro-connaissance—une voie essentielle pour la montée en charge du L1—l’implémentation zkEVM actuelle crée une pénalité de performance écrasante.

Voici la réalité technique : le zkEVM d’aujourd’hui ne prouve pas directement l’exécution de l’EVM. Au lieu de cela, il prouve un interpréteur qui a été compilé en code RISC-V. Cette couche d’abstraction supplémentaire est la coupable. Le coût de performance ? Les estimations varient de 50 à 800 fois plus lent que l’exécution native. Même après avoir optimisé d’autres composants—comme le passage à des algorithmes de hachage plus efficaces—l’exécution des blocs reste le goulot d’étranglement, représentant 80-90 % de tout le temps de génération de preuve.

Comme Vitalik Buterin a succinctement formulé le problème : si le zkVM compile tout de toute façon en RISC-V, pourquoi forcer les développeurs de contrats intelligents à travailler via un intermédiaire EVM qui n’ajoute que de la surcharge ?

Ce n’est pas théorique. L’écart de performance se traduit directement en économie. Éliminer cette couche d’interprétation pourrait améliorer l’efficacité d’exécution d’environ 100 fois—une différence qui sépare une montée en charge viable d’une congestion continue.

La dette technique enfouie dans le protocole

Les choix de conception de l’EVM avaient parfaitement du sens en 2015, mais ils se sont cristallisés en limitations. Considérons trois problèmes spécifiques :

Les contrats précompilés comme un patch qui a échoué. Lorsque l’EVM ne pouvait pas gérer efficacement certaines opérations cryptographiques, Ethereum a ajouté des fonctions codées en dur—des contrats précompilés. Cela semblait pragmatique temporairement. Aujourd’hui, cela crée ce que Vitalik appelle une situation « mauvaise » : ces modules ont gonflé la base de code de confiance d’Ethereum à des niveaux insoutenables et ont introduit des risques de sécurité répétés qui ont dangereusement failli causer des échecs de consensus.

Ajouter de nouveaux précompilés nécessite des hard forks contestés et implique un code wrapper plus complexe que l’ensemble des implémentations RISC-V. La conclusion de Vitalik : le protocole devrait cesser d’ajouter des précompilés totalement.

Architecture 256 bits pour le mauvais cas d’utilisation. La pile de 256 bits de l’EVM a été conçue pour des valeurs cryptographiques, mais la plupart des contrats intelligents fonctionnent avec des entiers de 32 ou 64 bits. Ce décalage crée une équation d’efficacité cruelle : des nombres plus petits ne permettent pas d’économiser des ressources, tandis que doubler ou quadrupler la complexité. Dans les systèmes de preuve ZK, cette inefficacité est amplifiée.

Pile vs. registres. L’architecture basée sur la pile de l’EVM nécessite plus d’instructions que le modèle de registre RISC-V pour effectuer des opérations identiques, compliquant l’optimisation du compilateur et augmentant la charge de génération de preuve.

Ces choix de conception accumulés ne sont pas des bugs—ce sont des contraintes architecturales qui avaient du sens à un moment donné, mais qui sont devenues incompatibles avec l’avenir d’Ethereum.

RISC-V : pourquoi une norme ouverte l’emporte sur une conception sur mesure

RISC-V n’est pas une technologie propriétaire. C’est une norme d’instructions open-source—essentiellement un plan librement accessible pour la conception de processeurs. Son adoption pour ce rôle n’est ni arbitraire ni expérimentale.

Pourquoi la simplicité est une force. La base d’instructions de RISC-V contient environ 47 instructions. Ce minimalisme radical est intentionnel. Moins d’instructions signifient une base de code de confiance plus petite—plus facile à auditer, à vérifier formellement et à assurer sécuritaire. Comme Jeremy Bruestle l’a souligné lors de conférences industrielles, cette conception est « presque parfaite pour la machine générale ultra-minimale dont nous avons besoin ».

Maturité de l’écosystème via LLVM. En choisissant une norme établie, Ethereum bénéficie de décennies d’infrastructure de compilateurs. Grâce au support LLVM, les développeurs peuvent utiliser n’importe quel langage de programmation grand public—Rust, C++, Go, Python—et compiler directement vers RISC-V. Cela élimine le besoin de reconstruire tout un écosystème de développement à partir de zéro. Justin Drake a exprimé l’avantage stratégique : « Nous bénéficions de tous les langages de haut niveau supportés par LLVM gratuitement. »

La convergence zkVM est déjà en cours. Le marché a déjà voté. Parmi les dix implémentations zkVM les plus avancées capables de prouver des blocs Ethereum, neuf ont choisi RISC-V. Ce n’est pas de la spéculation—c’est une validation pratique. L’écosystème de la connaissance zéro a standardisé RISC-V comme cible d’exécution, faisant de l’adoption d’Ethereum non pas un pari, mais un alignement avec la direction de l’industrie.

La vérification formelle devient possible. Contrairement à la spécification du Yellow Paper de l’EVM—écrite en langage naturel et sujette à ambiguïté—RISC-V dispose d’une spécification officielle SAIL, lisible par machine. Cette rigueur mathématique permet de vérifier directement les circuits zkVM par rapport à la spécification, créant une voie vers une correction prouvable que l’EVM ne pourrait jamais offrir.

Les frontières de sécurité matérielle intégrées. RISC-V inclut une architecture privilégiée avec mode utilisateur et mode superviseur. Les contrats intelligents s’exécutent en mode utilisateur et ne peuvent pas accéder directement à l’état de la blockchain ; ils émettent plutôt des requêtes ECALL vers un noyau de confiance. Cela crée une frontière de sécurité renforcée par l’architecture du processeur lui-même—bien plus robuste que le simple sandboxing logiciel. Comme l’a expliqué Diego de Cartesi, « Tous ces mécanismes de protection font partie de la norme RISC-V. »

La transition en trois phases : atténuation des risques par gradualisme

Ethereum ne prévoit pas une bascule brutale. La migration suit une feuille de route délibérément conservatrice :

Phase 1 : RISC-V comme remplacement des précompilés. Initialement, le protocole cesse d’ajouter de nouveaux précompilés EVM. À la place, de nouvelles fonctionnalités cryptographiques sont implémentées via des programmes RISC-V en liste blanche. Cela permet à la nouvelle architecture de subir des tests sur le réseau principal dans un environnement contrôlé et à faible risque avant une adoption plus large.

Phase 2 : Coexistence de deux machines virtuelles. Les contrats intelligents peuvent déclarer si leur bytecode cible l’EVM ou RISC-V. Crucialement, les contrats dans les deux environnements peuvent s’appeler mutuellement via des appels système ECALL standardisés. Cela crée une période hybride où les deux architectures fonctionnent ensemble, validant l’interopérabilité avant la migration complète.

Phase 3 : L’EVM comme contrat simulé. La fin de course considère l’EVM comme un langage de haut niveau—un contrat intelligent formellement vérifié fonctionnant nativement sur RISC-V L1. Les applications legacy restent supportées en permanence, mais la couche d’exécution principale du protocole devient purement RISC-V, simplifiant considérablement le développement et la maintenance client.

Cette approche par phases transforme une migration potentiellement catastrophique en une évolution gérable.

La réorientation de l’écosystème : gagnants et perdants

Ce changement n’affecte pas tous les Layer 2 de la même manière—il crée des gagnants et des perdants.

Les Optimistic Rollups font face à des défis architecturaux. Des projets comme Arbitrum et Optimism reposent sur des preuves de fraude : contester une transaction nécessite de la réexécuter sur le L1. Si le VM du L1 passe de l’EVM à RISC-V, ce modèle de sécurité s’effondre. Ces projets ont deux options : entreprendre d’énormes efforts d’ingénierie pour repenser leurs preuves de fraude pour la nouvelle architecture, ou se découpler complètement du modèle de sécurité d’Ethereum. Les deux options sont coûteuses.

Les ZK Rollups gagnent un avantage stratégique massif. Des projets comme Polygon, zkSync et Scroll ont déjà standardisé RISC-V en interne. Un L1 qui « parle leur langage » élimine les couches de traduction. Ce que la Fondation Ethereum appelle « Rollups natifs » devient possible : le L2 devient une instance spécialisée de l’environnement d’exécution du L1, partageant outils, compilateurs et infrastructure de vérification formelle. Le résultat pratique : les équipes L2 ne construisent plus de ponts entre VMs incompatibles, les coûts de développement chutent, et l’économie du gaz s’aligne plus rationnellement.

L’expérience développeur se transforme. Au lieu d’apprendre exclusivement Solidity, les développeurs écrivent en Rust, Go ou tout autre langage supporté par LLVM. Les contrats peuvent utiliser des bibliothèques matures de l’écosystème logiciel plus large. Vitalik compare cela à Node.js : code on-chain et off-chain unifié dans le même langage, avec les mêmes outils. Cette réduction de barrière devrait probablement remodeler qui peut participer au développement blockchain.

L’économie utilisateur s’améliore considérablement. Les coûts de preuve chutent d’environ 100 fois. Les frais de transaction pour le règlement L1 et L2 diminuent en conséquence. Cela débloque le « Gigagas L1»—environ 10 000 transactions par seconde—permettant des applications complexes nécessitant à la fois débit et sécurité.

Succinct Labs et SP1 : la preuve que la vision fonctionne dès aujourd’hui

La transition n’est pas uniquement théorique. Succinct Labs a déjà démontré les avantages pratiques de RISC-V via SP1, un zkVM open-source qui prouve que la thèse architecturale fonctionne.

L’innovation de SP1 : il adopte une conception « centrée sur les précompilés » qui résout le goulot cryptographique de l’EVM sans créer le problème de complexité. Des opérations intensives comme le hachage Keccak s’exécutent dans des circuits ZK spécialisés, appelés via des instructions ECALL standard. Cela combine la performance hardware sur mesure avec la flexibilité logicielle.

L’impact pratique est immédiat. Le produit OP Succinct de Succinct donne aux Optimistic Rollups des capacités à connaissance zéro. Le résultat : au lieu d’attendre sept jours pour la confirmation finale et le retrait, les transactions se finalisent en environ une heure. Pour tout l’écosystème OP Stack, cette amélioration de vitesse répond à un point sensible.

Succinct exploite aussi un réseau décentralisé de Provers, créant un marché pour la génération de preuves. Ce n’est pas un simple proof of concept—c’est un plan pour le modèle économique qui régira l’informatique vérifiable à grande échelle.

Les risques cachés : ce qui peut encore mal tourner

Malgré les avantages de RISC-V, la transformation introduit de nouveaux risques :

Complexité de la mesure du gaz. Attribuer un coût de gaz juste et déterministe aux instructions à usage général est un problème non résolu. Le simple comptage d’instructions est vulnérable aux attaques par déni de service. Un attaquant pourrait concevoir des programmes qui déclenchent à répétition des cache misses, consommant d’énormes ressources tout en ayant un coût en gaz minimal. Cela menace la stabilité du réseau et les modèles économiques.

Sécurité de la chaîne d’outils et builds reproductibles. C’est le risque le plus dangereux et sous-estimé. La sécurité passe du recours aux VMs en chaîne à celui aux compilateurs hors chaîne comme LLVM—logiciel complexe connu pour contenir des vulnérabilités. Un attaquant exploitant des bugs de compilateur pourrait transformer un code source apparemment sûr en bytecode malveillant. Tout aussi difficile : assurer que les binaires compilés correspondent au code source public (le problème du build reproductible) à travers différents environnements de build. De légères variations d’environnement produisent des sorties différentes, créant des problèmes de confiance et de transparence.

Ces risques sont résolvables mais pas triviaux.

Atténuation : la défense en profondeur

Déploiement par phases comme stratégie principale. En introduisant RISC-V progressivement via des précompilés, puis des VMs duales, puis le remplacement complet, le protocole construit une expérience opérationnelle et une confiance avant de s’engager irréversiblement. Cette approche par étapes est l’outil fondamental de gestion des risques.

Tests intensifs et vérification formelle. Bien que la vérification formelle soit l’objectif à long terme, elle doit être couplée à des tests continus à haute intensité. Des cabinets de sécurité comme Diligence ont déjà découvert 11 vulnérabilités critiques de cohérence et d’intégrité dans des zkVM leaders via des tests de fuzzing. Ce pattern—des vulnérabilités dissimulées dans des systèmes bien conçus—impose des stratégies parallèles de test et de vérification, pas séquentielles.

Standardisation pour éviter la fragmentation. La communauté devrait adopter une configuration RISC-V unique, probablement RV64GC avec ABI compatible Linux. Cela maximise le support des outils et évite la fragmentation de l’écosystème, permettant aux développeurs de bénéficier pleinement des avantages de l’écosystème LLVM.

La couche Internet vérifiable : le jeu à long terme d’Ethereum

La transition de l’EVM vers RISC-V n’est pas principalement une question de gains de performance incrémentaux. Il s’agit de repositionner Ethereum, passant d’une « machine virtuelle de contrats intelligents » à une fondation de confiance vérifiable pour l’informatique internet à usage général.

La vision de Vitalik résume la fin du jeu : « L’objectif final inclut… rendre tout ZK-snarkifié. »

Cette transformation répond à la « Pièce d’Exécution Lean » d’Ethereum—une partie de la vision plus large « Ethereum Lean ». Le protocole se simplifie d’un VM monolithique à une couche de règlement et de disponibilité des données minimaliste, optimisée pour la computation vérifiable. La preuve matérielle accélérée (ASICs et FPGAs de SP1, Nervos, Cartesi) devient envisageable une fois que l’ensemble d’instructions se stabilise autour de RISC-V.

La transition est inévitable non pas parce qu’elle est optimale isolément, mais parce qu’elle s’aligne avec la direction que prend la computation elle-même. Les preuves ZK représentent le troisième primitive cryptographique après les hash et les signatures. La mise sur le marché d’une couche de confiance fondamentale pour l’informatique vérifiable—intégration native d’une structure machine générale dans la programmation système—contrôle la prochaine ère d’internet.

Malgré d’importants obstacles techniques et sociaux, cette restructuration de la couche d’exécution d’Ethereum représente l’une des décisions architecturales les plus importantes de l’histoire de la blockchain. Elle échange les effets de réseau de la familiarité avec l’EVM contre une position stratégique de leader dans la révolution de l’informatique vérifiable.

La transformation commence dès maintenant. Des projets comme Ethproofs rassemblent les données collaboratives nécessaires pour exécuter ce changement. Des équipes comme Succinct Labs fournissent les plans pratiques. D’ici 6 à 12 mois, attendez-vous aux premières alternatives de précompilés exécutant du code RISC-V sur le mainnet Ethereum—marquant le début de la fin pour la Machine Virtuelle Ethereum telle que nous la connaissons.