Comment le prochain grand changement d'Ethereum pourrait remodeler toute l'industrie de la blockchain

Ethereum se trouve à un point d’inflexion technologique critique. Après des années à s’appuyer sur la Machine Virtuelle Ethereum (EVM) comme colonne vertébrale de ses calculs, le réseau fait face à une pression croissante pour évoluer vers un modèle d’exécution fondamentalement différent—basé sur l’architecture RISC-V, spécifiquement optimisé pour les systèmes de preuve à zéro connaissance.

Ce n’est pas une simple mise à jour de protocole. C’est une restructuration complète de la façon dont Ethereum traite les transactions et valide les changements d’état. Et le calendrier est important : à mesure que les solutions de Layer 2 se multiplient et que la technologie de zéro connaissance mûrit, l’architecture actuelle de l’EVM commence à révéler ses limites de manières qui n’étaient pas évidentes il y a seulement deux ans.

Pourquoi l’EVM devient un goulot d’étranglement

L’EVM était révolutionnaire lors de son lancement. Elle a permis tout l’écosystème des contrats intelligents. Mais une conception vieille de dix ans accumule une dette technique, et l’émergence des systèmes de preuve à zéro connaissance a mis en évidence des inefficacités architecturales désormais impossibles à ignorer.

Le problème central est simple : prouver l’exécution de l’EVM via des circuits ZK entraîne une surcharge énorme. Les implémentations zkEVM actuelles ne prouvent pas directement l’EVM elle-même. Au lieu de cela, elles prouvent un interpréteur de l’EVM, qui se compile finalement en code RISC-V. Comme l’a souligné Vitalik Buterin, cela crée une couche d’abstraction inutile qui peut réduire la performance de 50 à 800 fois par rapport à des preuves RISC-V natives.

Même après avoir optimisé d’autres composants—en passant à des fonctions de hachage plus rapides comme Poseidon—l’exécution des blocs représente encore 80-90 % du temps total de génération de preuve. La surcharge de l’interpréteur est devenue le principal goulot d’étranglement empêchant Ethereum de se développer via la vérification ZK en couche 1.

Le piège de la complexité : la dette technique qui s’accumule

Au-delà des performances, Ethereum a accumulé un autre problème : les contrats précompilés. Ce sont des fonctions codées en dur ajoutées pour compenser les inefficacités de l’EVM dans certaines opérations cryptographiques. Chaque ajout a temporairement résolu un besoin immédiat, mais a progressivement gonflé la base de code de confiance d’Ethereum avec des solutions spécialisées, ponctuelles.

Le code d’enveloppe pour un seul contrat précompilé comme modexp serait apparemment plus complexe que l’ensemble de l’implémentation de l’interpréteur RISC-V. Ajouter de nouvelles fonctions précompilées nécessite un hard fork contesté, créant des frictions politiques et ralentissant l’innovation applicative nécessitant de nouveaux primitives cryptographiques.

La conception architecturale de l’EVM elle-même comporte aussi des liabilities. Son design de pile de 256 bits était pertinent pour gérer des valeurs cryptographiques, mais il est extrêmement inefficace pour les entiers de 32 ou 64 bits réellement utilisés dans la majorité des contrats intelligents. Dans les systèmes de zéro connaissance, ces inefficacités sont particulièrement coûteuses—des nombres plus petits consomment les mêmes ressources tout en augmentant la complexité par deux à quatre fois.

Pourquoi RISC-V émerge comme la solution

RISC-V n’est pas une invention propriétaire conçue spécifiquement pour Ethereum. C’est une norme d’instruction open-source qui est déjà devenue l’architecture de facto pour les machines virtuelles à zéro connaissance. Parmi les dix zkVM capables de prouver des blocs Ethereum, neuf ont déjà standardisé RISC-V.

Ce consensus de marché indique quelque chose d’important : adopter RISC-V n’est pas un pari spéculatif. C’est s’aligner sur une infrastructure que tout l’écosystème de zéro connaissance a déjà validée par le déploiement réel.

L’attrait est multiple :

Conception minimaliste : La base d’instructions RISC-V ne contient qu’environ 47 instructions principales, comparé à la complexité implicite de l’EVM. Un code de confiance plus petit est beaucoup plus facile à auditer, tester et vérifier formellement—critique pour protéger des milliards de valeur en chaîne.

Écosystème mature : En adoptant RISC-V, Ethereum accède immédiatement à l’infrastructure du compilateur LLVM. Cela signifie que des millions de développeurs déjà familiers avec Rust, C++, Go et Python peuvent écrire directement pour la couche L1 sans apprendre un nouveau langage ou environnement. L’expérience de développement ressemblerait à celle du développement cross-platform avec NodeJS.

Avantages de la vérification formelle : Contrairement à la spécification du Yellow Paper de l’EVM (écrite en langage naturel avec des ambiguïtés inhérentes), RISC-V dispose d’une spécification SAIL lisible par machine. Ce “standard d’or” permet des preuves mathématiques strictes de correction—le graal de la sécurité blockchain qui déplace la confiance de l’implémentation humaine vers une preuve vérifiable.

Chemin d’optimisation matérielle : L’architecture supporte l’accélération matérielle via ASICs et FPGAs, permettant la création d’infrastructures spécialisées de génération de preuves (similaires aux travaux en cours chez Succinct Labs, Nervos, et Cartesi).

La feuille de route en trois phases pour la migration

La transition d’Ethereum ne sera pas révolutionnaire mais évolutive. Vitalik Buterin a esquissé une approche prudente et par étapes :

Phase 1 - Déploiement limité : RISC-V entre en tant qu’alternative précompilée, en remplacement des ajouts de nouveaux contrats précompilés. Ce terrain d’essai à faible risque permet au réseau de gagner en confiance dans le nouveau système tout en maintenant une compatibilité totale avec l’EVM. Seuls certains programmes RISC-V, pré-approuvés, s’exécutent via des chemins d’exécution en liste blanche.

Phase 2 - Coexistence : Les contrats intelligents peuvent déclarer leur bytecode comme étant soit EVM, soit RISC-V. Les deux systèmes coexistent et interopèrent sans problème via des appels système (ECALL), permettant aux contrats de différentes architectures de s’appeler mutuellement. Cet environnement hybride permet aux développeurs de migrer progressivement sans décisions immédiates.

Phase 3 - Couche native : L’EVM devient un contrat simulé s’exécutant sur RISC-V lui-même (la stratégie “Rosetta”). Les applications legacy tournent inchangées, mais le moteur d’exécution sous-jacent se simplifie en un seul cœur RISC-V, réduisant drastiquement la complexité et la charge de maintenance pour les développeurs de clients.

Qui gagne et qui struggle dans cette nouvelle ère

Ce changement architectural aura des conséquences très différentes selon les solutions Layer 2.

Les Rollups à zéro connaissance gagnent un avantage structurel. Des projets comme Polygon, zkSync, et Scroll ont déjà standardisé RISC-V en interne. Un L1 qui “parle le même langage” facilite une intégration native avec un minimum de ponts. La réutilisation d’outils, la compatibilité des compilateurs, et l’alignement des incitations économiques jouent tous en leur faveur. Uma Roy, co-fondatrice de Succinct Labs, a démontré cet avantage avec OP Succinct, qui ajoute des capacités de preuve à zéro connaissance aux Rollups Optimistes—réduisant le délai de retrait de sept jours à environ une heure.

Les Rollups Optimistes doivent faire face à des choix plus difficiles. Arbitrum et Optimism s’appuient sur des preuves de fraude exécutées via l’EVM de la couche 1 pour résoudre les litiges. Si l’EVM disparaît, tout ce modèle de sécurité doit être reconstruit. Ces équipes doivent soit concevoir de nouveaux systèmes de preuve de fraude ciblant la nouvelle architecture L1, soit se désolidariser fondamentalement des garanties de sécurité d’Ethereum—aucune de ces options n’est triviale.

Impact économique : coûts plus faibles, débit plus élevé

Pour les utilisateurs finaux, la transition se traduit par des bénéfices tangibles.

Les coûts de génération de preuve devraient diminuer d’environ 100 fois—passant de plusieurs dollars par transaction à quelques cents ou moins. Cela réduit directement les frais en couche 1 et, plus encore, les coûts de règlement en couche 2. Les gains d’efficacité permettent la vision du “Gigagas L1” : environ 10 000 TPS à un coût raisonnable, débloquant des applications actuellement trop coûteuses à exécuter en chaîne.

Les développeurs ont accès à une chaîne d’outils beaucoup plus large. Construire du code en chaîne et hors chaîne dans le même langage devient la norme plutôt qu’une exception. Ce “modèle NodeJS” pour le développement blockchain attire de nouveaux créateurs et accélère l’innovation applicative.

Les risques critiques que personne ne doit ignorer

Cette transformation introduit de nouveaux défis qui nécessitent une attention sérieuse.

La mesure du gaz devient mathématiquement plus complexe. Concevoir un modèle de gaz équitable et déterministe pour des jeux d’instructions généraux reste non résolu. Le comptage simple d’instructions invite à des attaques par déni de service—des attaquants peuvent créer des programmes provoquant des échecs répétés de cache, consommant d’énormes ressources à faible coût en gaz. Cela menace la stabilité du réseau et son intégrité économique.

La sécurité de la chaîne d’outils est désormais dans le spectre de menace. La responsabilité de sécurité passe des machines virtuelles en chaîne aux compilateurs hors chaîne comme LLVM. Ce sont des systèmes logiciels extrêmement complexes, avec des vulnérabilités connues. Des attaquants pourraient exploiter des bugs de compilateur pour transformer un code source bénin en bytecode malveillant indétectable lors de l’audit standard.

Les builds reproductibles restent non résolus. Garantir que les binaires compilés correspondent exactement au code source public est techniquement difficile. De petites variations environnementales produisent des sorties différentes, ce qui compromet la transparence et la confiance—ce que la blockchain est censée résoudre.

Ces risques exigent une défense multicouche : un déploiement par phases pour minimiser les dégâts irréversibles, des tests de fuzzing continus pour découvrir des vulnérabilités (le cabinet de sécurité Argus a rapporté avoir trouvé 11 failles de sécurité critiques dans des zkVMs leaders), et la vérification formelle pour renforcer les garanties théoriques.

La voie pratique : le plan de Succinct Labs

Cette transformation n’est pas purement théorique. Des équipes construisent déjà l’infrastructure. SP1 de Succinct Labs est une zkVM open-source de niveau production, démontrant que la génération de preuves basée sur RISC-V fonctionne à grande échelle. SP1 adopte une philosophie “centrée sur la précompilation”—délégant les opérations intensives comme le hachage Keccak à des circuits ZK spécialisés, optimisés manuellement, appelables via des instructions standard—combinant performance hardware personnalisé et flexibilité logicielle.

Leur travail prouve le concept tout en établissant la viabilité économique via le réseau de preuve Succinct, un marché décentralisé pour la génération de preuves qui montre à quoi ressemblera la future couche d’infrastructure.

La vision plus large : Ethereum comme couche de calcul vérifiable

Cette transition redéfinit le rôle fondamental d’Ethereum. Plutôt que de rester principalement une plateforme d’exécution de contrats intelligents, Ethereum devient la couche de confiance pour le calcul vérifiable général—ce que Vitalik appelle le “Snarkify everything” (tout rendre en preuve à zéro connaissance).

Cela s’aligne avec la philosophie plus large de “Lean Ethereum” : simplifier systématiquement le protocole en trois modules clairs (Consensus Léger, Données Légeres, Exécution Léger). En supprimant l’EVM et en adoptant RISC-V, Ethereum affine son objectif central : règlement efficace et disponibilité des données pour un univers d’applications vérifiables.

Ce changement reconnaît une vérité fondamentale : dans un futur dominé par les preuves à zéro connaissance, les primitives de calcul comptent. Ethereum peut soit résister à l’évolution technologique inévitable, soit l’embrasser stratégiquement. La feuille de route discutée lors des conférences EthProofs et forums de recherche indique que la Fondation Ethereum et l’équipe principale ont choisi cette dernière voie.

Ce n’est pas une transformation du jour au lendemain. C’est un processus pluriannuel nécessitant coordination, déploiement par étapes, et une véritable adhésion communautaire. Mais le cas technique devient de plus en plus difficile à contester, et les incitations compétitives des solutions Layer 2 déjà optimisées pour RISC-V exercent une pression croissante pour aligner l’architecture L1 avec le futur que l’écosystème construit déjà.

La question n’est plus de savoir si cela se produira, mais comment Ethereum gérera cette transition avec soin et détermination—et si la communauté pourra réaliser cette restructuration ambitieuse tout en maintenant la confiance et la stabilité sur lesquelles des milliards de valeur reposent.