Ethereum pourrait connaître la plus grande mise à niveau de son histoire : EVM sera désactivée, RISC-V prendra le relais

Titre original : Goodbye EVM, Hello RISC-V

Auteur original : jaehaerys.eth, chercheur en cryptomonnaies

Traduction originale : TechFlow

Résumé

Ethereum se prépare à la transformation architecturale la plus importante depuis sa création : remplacer l’EVM par RISC-V.

La raison est simple : dans un futur centré sur le Zero-Knowledge (ZK), l’EVM est déjà devenu un goulot d’étranglement en termes de performance :

· Les zkEVM actuels dépendent d’interpréteurs, entraînant un ralentissement de 50 à 800 fois ;

· Les modules précompilés complexifient le protocole et augmentent les risques ;

· La conception de la pile 256 bits est extrêmement inefficace lors de la génération de preuves.

Les solutions de RISC-V :

· Conception minimaliste (environ 47 instructions de base) + écosystème LLVM mature (supportant Rust, C++, Go, etc.) ;

· Devenu le standard de facto des zkVM (adopté par 90 % des projets) ;

· Dispose d’une spécification SAIL formelle (comparée au Yellow Paper ambigu) → permet une vérification stricte ;

· Chemin de preuve matériel (ASICs/FPGAs) déjà en phase de test (SP1, Nervos, Cartesi, etc.).

Le processus de migration se divise en trois étapes :

· Remplacer les modules précompilés par RISC-V (test à faible risque) ;

· Ère des doubles machines virtuelles : coexistence et interopérabilité complète entre EVM et RISC-V ;

· Réimplémentation de l’EVM au sein de RISC-V (stratégie Rosetta).

Impact sur l’écosystème :

· Les Rollup optimistes (comme Arbitrum et Optimism) devront reconstruire leur mécanisme de preuve de fraude ;

· Les Rollup Zero-Knowledge (comme Polygon, zkSync, Scroll) bénéficieront d’un avantage considérable → moins cher, plus rapide, plus simple ;

· Les développeurs pourront utiliser directement des bibliothèques de langages comme Rust, Go et Python sur la couche L1 ;

· Les utilisateurs profiteront d’un coût de preuve environ 100 fois inférieur → vers un Gigagas L1 (~10 000 TPS).

Finalement, Ethereum évoluera d’une « machine virtuelle de contrats intelligents » vers une couche de confiance minimaliste et vérifiable pour Internet, avec pour objectif ultime de « ZK-Snarkifier tout ».

Le carrefour d’Ethereum

Vitalik Buterin a déclaré : « Le but final inclut... ZK-Snarkifier tout. »

La fin inévitable du Zero-Knowledge (ZK) est déjà en marche, et l’argument central est simple : Ethereum se reconstruit depuis zéro sur la base des preuves Zero-Knowledge. Cela marque le point d’aboutissement technique du protocole – une reconstruction du L1, propulsée par un zkVM haute performance soutenu par des équipes de développement clés (comme Succinct).

Avec cette vision pour horizon, Ethereum se trouve à la croisée des chemins, prêt pour la transformation architecturale la plus importante depuis sa création. Ce débat ne porte plus sur des mises à niveau progressives, mais sur une refonte complète de son cœur computationnel – le remplacement de l’Ethereum Virtual Machine (EVM). Cette initiative est la pierre angulaire de la vision plus large du « Lean Ethereum ».

La vision Lean Ethereum vise à simplifier systématiquement l’ensemble du protocole, en le divisant en trois modules principaux : Lean Consensus, Lean Data et Lean Execution. Au cœur de la question Lean Execution, un point crucial : l’EVM, moteur de la révolution des smart contracts, est-il devenu le principal goulot d’étranglement pour le futur d’Ethereum ?

Comme l’a souligné Justin Drake de la Ethereum Foundation, l’objectif à long terme d’Ethereum a toujours été de « Snarkifier tout », un outil puissant pour renforcer toutes les couches du protocole. Cependant, cet objectif a longtemps semblé être un « plan lointain », car il nécessitait le concept de preuve en temps réel. Aujourd’hui, alors que la preuve en temps réel devient réalité, l’inefficacité théorique de l’EVM est devenue un problème pratique urgent à résoudre.

Cet article analyse en profondeur les arguments techniques et stratégiques pour migrer Ethereum L1 vers l’architecture d’instructions RISC-V (ISA). Cette initiative promet non seulement de libérer une évolutivité sans précédent, mais aussi de simplifier la structure du protocole et d’aligner Ethereum avec l’avenir du calcul vérifiable.

Qu’est-ce qui a changé ?

Avant d’explorer le « pourquoi », il faut d’abord clarifier le « quoi » qui change.

L’EVM (Ethereum Virtual Machine) est l’environnement d’exécution des smart contracts d’Ethereum, surnommé « l’ordinateur mondial » qui traite les transactions et met à jour l’état de la blockchain. Pendant des années, sa conception a été révolutionnaire, jetant les bases de la DeFi et de l’écosystème NFT. Cependant, cette architecture sur-mesure, vieille de près de dix ans, a accumulé une dette technique considérable.

À l’inverse, RISC-V n’est pas un produit, mais une norme ouverte – un « alphabet » de conception de processeur gratuit et universel. Comme l’a souligné Jeremy Bruestle lors de la conférence Ethproofs, ses principes clés en font un choix idéal pour ce rôle :

· Minimalisme : Le jeu d’instructions de base de RISC-V est extrêmement simple, avec seulement 40 à 47 instructions. Comme le dit Jeremy, cela le rend « presque parfaitement adapté à notre cas d’utilisation d’une machine universelle super minimaliste ».

· Conception modulaire : Les fonctionnalités plus complexes sont ajoutées via des extensions optionnelles. Cette caractéristique est cruciale car elle permet au noyau de rester simple tout en étendant les fonctionnalités selon les besoins, sans imposer de complexité inutile au protocole de base.

· Écosystème ouvert : RISC-V bénéficie d’un vaste et mature support d’outils, dont le compilateur LLVM, permettant aux développeurs d’utiliser des langages de programmation populaires comme Rust, C++ et Go. Comme le mentionne Justin Drake : « Les outils autour des compilateurs sont très riches, et construire des compilateurs est extrêmement difficile... donc disposer de ces chaînes d’outils est extrêmement précieux. » RISC-V permet à Ethereum d’hériter gratuitement de ces outils prêts à l’emploi.

Le problème de la surcharge de l’interpréteur

Le remplacement de l’EVM n’est pas motivé par un défaut unique, mais par la convergence de plusieurs limitations fondamentales, devenues impossibles à ignorer dans un futur centré sur les preuves Zero-Knowledge. Ces limitations incluent les goulots d’étranglement de performance dans les systèmes de preuve ZK et les risques liés à la complexité croissante du protocole.

Le moteur le plus pressant de cette transformation est l’inefficacité intrinsèque de l’EVM dans les systèmes de preuve ZK. À mesure qu’Ethereum évolue vers un modèle où l’état du L1 est validé par des preuves ZK, la performance des prouveurs devient le principal goulot d’étranglement.

Le problème vient du mode de fonctionnement actuel des zkEVM. Ils ne prouvent pas directement l’EVM en ZK, mais prouvent l’interpréteur de l’EVM, lequel est lui-même compilé en RISC-V. Vitalik Buterin a souligné ce problème central :

« ...si la façon dont le zkVM est implémenté consiste à compiler l’exécution de l’EVM en code RISC-V, pourquoi ne pas exposer directement le RISC-V sous-jacent aux développeurs de smart contracts ? Cela éliminerait toute la surcharge de la VM externe. »

Cette couche d’interprétation supplémentaire entraîne une perte de performance massive. Les estimations suggèrent qu’elle peut causer une baisse de performance de 50 à 800 fois par rapport à la preuve de programmes natifs. Même après optimisation d’autres goulots d’étranglement (comme le passage au hash Poseidon), cette partie « exécution de bloc » représente encore 80 à 90 % du temps de preuve, faisant de l’EVM le dernier et le plus difficile obstacle à l’extension du L1. En supprimant cette couche, Vitalik prévoit une amélioration de l’efficacité d’exécution d’environ 100 fois.

Le piège de la dette technique

Pour compenser les faiblesses de l’EVM dans certaines opérations cryptographiques, Ethereum a introduit des contrats précompilés – des fonctions spécialisées codées en dur dans le protocole. Bien que cette solution ait été pragmatique à l’époque, elle a aujourd’hui mené à une situation que Vitalik Buterin qualifie de « désastreuse » :

« Les précompilés sont catastrophiques pour nous... ils ont énormément gonflé la base de code de confiance d’Ethereum... et ils ont déjà failli causer plusieurs échecs de consensus majeurs. »

La complexité est stupéfiante. Vitalik cite qu’un seul contrat précompilé (comme modexp) a un code d’enrobage plus complexe que tout l’interpréteur RISC-V, et la logique précompilée est encore plus fastidieuse. Ajouter un nouveau précompilé nécessite un hard fork lent et politiquement controversé, freinant l’innovation pour les applications nécessitant de nouveaux primitifs cryptographiques. Vitalik en conclut :

« Je pense que nous devrions arrêter d’ajouter de nouveaux précompilés à partir d’aujourd’hui. »

La dette technique architecturale d’Ethereum

Le design central de l’EVM reflète les priorités d’une époque révolue, mais il n’est plus adapté aux besoins informatiques modernes. L’EVM a choisi une architecture 256 bits pour gérer les valeurs cryptographiques, mais pour les entiers 32 ou 64 bits couramment utilisés dans les smart contracts, cette architecture est très inefficiente. Cette inefficacité est particulièrement coûteuse dans les systèmes ZK. Comme l’explique Vitalik :

« Lorsqu’on utilise de petits nombres, chaque nombre ne permet en réalité aucune économie de ressources, et la complexité augmente de deux à quatre fois. »

De plus, l’architecture de pile de l’EVM est moins efficace que l’architecture à registres de RISC-V et des CPU modernes. Elle nécessite plus d’instructions pour accomplir la même tâche et complique l’optimisation du compilateur.

Ces problèmes – goulots d’étranglement de performance pour les preuves ZK, complexité des précompilés, choix architecturaux obsolètes – forment un argument convaincant et urgent : Ethereum doit dépasser l’EVM et adopter une architecture technologique plus adaptée au futur.

Le plan RISC-V : refonder l’avenir d’Ethereum sur des bases plus solides

L’avantage de RISC-V ne réside pas seulement dans les faiblesses de l’EVM, mais dans la puissance intrinsèque de sa philosophie de conception. Son architecture offre une base robuste, simple et vérifiable, parfaitement adaptée à un environnement à haut risque comme Ethereum.

Pourquoi une norme ouverte est-elle supérieure à une conception sur-mesure ?

Contrairement à une architecture d’instructions personnalisée (ISA) qui nécessite de construire tout l’écosystème logiciel à partir de zéro, RISC-V est une norme ouverte mature, avec trois avantages clés :

Écosystème mature

En adoptant RISC-V, Ethereum bénéficie de décennies de progrès collectifs en informatique. Comme l’explique Justin Drake, cela permet à Ethereum d’utiliser directement des outils de classe mondiale :

« Il existe un composant d’infrastructure appelé LLVM, une chaîne d’outils de compilation qui permet de compiler des langages de haut niveau vers plusieurs cibles, dont RISC-V. Donc si vous supportez RISC-V, vous supportez automatiquement tous les langages de haut niveau pris en charge par LLVM. »

Cela réduit considérablement la barrière à l’entrée, permettant à des millions de développeurs familiers avec Rust, C++ ou Go de contribuer facilement.

Philosophie de conception minimaliste Le minimalisme de RISC-V est une caractéristique délibérée, pas une limitation. Son jeu d’instructions de base ne compte qu’environ 47 instructions, gardant le cœur de la VM extrêmement simple. Cette simplicité offre un avantage significatif en matière de sécurité, car une base de code de confiance plus petite est plus facile à auditer et à vérifier formellement.

Standard de fait dans le domaine Zero-Knowledge Plus important encore, l’écosystème zkVM a déjà fait son choix. Comme le souligne Justin Drake, les données d’Ethproofs montrent une tendance claire :

« RISC-V est l’architecture d’instructions leader pour les backends zkVM. »

Sur dix zkVM capables de prouver des blocs Ethereum, neuf ont choisi RISC-V comme architecture cible. Cette convergence du marché envoie un signal fort : en adoptant RISC-V, Ethereum ne fait pas un pari spéculatif, mais s’aligne sur une norme éprouvée et reconnue par les projets qui construisent l’avenir Zero-Knowledge.

Née pour la confiance, pas seulement pour l’exécution

Au-delà de l’écosystème, l’architecture interne de RISC-V est particulièrement adaptée à la construction de systèmes sûrs et vérifiables. D’abord, RISC-V dispose d’une spécification formelle et lisible par machine – SAIL. Par rapport à la spécification de l’EVM (principalement le Yellow Paper en langage naturel), c’est un progrès majeur. Le Yellow Paper est ambigu, alors que la spécification SAIL fournit un « standard d’or » pour les preuves de correction mathématique, crucial pour protéger un protocole de grande valeur. Comme l’a mentionné Alex Hicks de la Ethereum Foundation lors d’Ethproofs, cela permet aux circuits zkVM d’être directement « vérifiés contre la spécification officielle RISC-V ». Ensuite, RISC-V inclut une architecture privilégiée, une caractéristique souvent négligée mais essentielle pour la sécurité. Elle définit différents niveaux d’opération, principalement le mode utilisateur (pour les applications non fiables comme les smart contracts) et le mode superviseur (pour le « noyau d’exécution » de confiance). Diego de Cartesi l’explique en détail :

« Le système d’exploitation doit se protéger contre le code externe. Il doit isoler les différents programmes, et tous ces mécanismes font partie du standard RISC-V. »

Dans l’architecture RISC-V, les smart contracts s’exécutant en mode utilisateur ne peuvent pas accéder directement à l’état de la blockchain. Ils doivent passer par une instruction spéciale ECALL (appel d’environnement) pour demander au noyau de confiance en mode superviseur. Ce mécanisme crée une frontière de sécurité imposée par le matériel, bien plus robuste et vérifiable que le modèle de sandbox logiciel de l’EVM.

La vision de Vitalik

Cette transformation est envisagée comme un processus progressif et multi-étapes, pour garantir la stabilité du système et la compatibilité ascendante. Comme l’a expliqué Vitalik Buterin, cette approche vise une évolution « incrémentale » plutôt qu’une révolution totale.

Première étape : remplacement des précompilés

La phase initiale adopte l’approche la plus conservatrice, en introduisant des fonctionnalités limitées de la nouvelle VM. Comme le suggère Vitalik Buterin : « Nous pouvons commencer à utiliser la nouvelle VM dans des scénarios limités, comme le remplacement des précompilés. » Concrètement, cela suspend l’ajout de nouveaux précompilés EVM, remplacés par des programmes RISC-V approuvés par liste blanche. Cette méthode permet de tester la nouvelle VM sur le mainnet dans un environnement à faible risque, les clients Ethereum servant de médiateurs entre les deux environnements d’exécution.

Deuxième étape : coexistence des deux machines virtuelles

L’étape suivante consiste à « ouvrir la nouvelle VM directement aux utilisateurs ». Les smart contracts peuvent indiquer via un tag si leur bytecode est EVM ou RISC-V. La clé est d’assurer une interopérabilité transparente : « Les deux types de contrats peuvent s’appeler mutuellement. » Cette fonctionnalité sera réalisée via des appels système (ECALL), permettant aux deux VM de collaborer dans le même écosystème.

Troisième étape : EVM comme contrat simulé (stratégie « Rosetta »)

L’objectif final est la simplification maximale du protocole. À ce stade, « nous implémentons l’EVM comme une instance de la nouvelle VM ». L’EVM normalisé deviendra un smart contract formellement vérifié s’exécutant sur le L1 RISC-V natif. Cela garantit un support permanent pour les anciennes applications, tout en permettant aux développeurs de clients de ne maintenir qu’un moteur d’exécution simplifié, réduisant considérablement la complexité et les coûts de maintenance.

Effets d’entraînement sur l’écosystème

La transition de l’EVM vers RISC-V n’est pas seulement un changement du protocole central, elle aura un impact profond sur tout l’écosystème Ethereum. Cette transformation va remodeler l’expérience des développeurs, changer fondamentalement la dynamique concurrentielle des solutions Layer-2 et débloquer de nouveaux modèles de validation économique.

Repositionnement des Rollup : duel entre Optimistic et ZK

L’adoption de RISC-V comme couche d’exécution L1 aura des effets très différents sur les deux principaux types de Rollup.

Les Optimistic Rollup (comme Arbitrum, Optimism) font face à un défi architectural. Leur modèle de sécurité repose sur la réexécution sur L1 EVM des transactions litigieuses pour prouver la fraude. Si l’EVM du L1 est remplacé, ce modèle s’effondre. Ces projets devront soit entreprendre une refonte majeure pour concevoir un système de preuve de fraude adapté à la nouvelle VM L1, soit s’éloigner complètement du modèle de sécurité d’Ethereum.

À l’inverse, les ZK Rollup bénéficieront d’un avantage stratégique majeur. La grande majorité des ZK Rollup utilisent déjà RISC-V comme architecture d’instructions interne. Un L1 « parlant la même langue » permettra une intégration plus étroite et plus efficace. Justin Drake évoque la vision d’un « Rollup natif » : le L2 devient une instance spécialisée de l’environnement d’exécution du L1, utilisant la VM intégrée du L1 pour un règlement sans couture. Cet alignement apportera :

· Simplification de la stack technique : Les équipes L2 n’auront plus à construire des ponts complexes entre leur environnement RISC-V interne et l’EVM.

· Réutilisation des outils et du code : Les compilateurs, débogueurs et outils de vérification formelle développés pour l’environnement RISC-V L1 pourront être utilisés directement par les L2, réduisant considérablement les coûts de développement.

· Alignement des incitations économiques : Les frais de Gas du L1 refléteront plus fidèlement le coût réel de la vérification ZK basée sur RISC-V, créant un modèle économique plus rationnel.

Nouvelle ère pour les développeurs et les utilisateurs

Pour les développeurs Ethereum, cette transformation sera progressive, non disruptive.

Pour les développeurs, ils auront accès à un écosystème de développement logiciel plus large et plus mature. Comme le souligne Vitalik Buterin, ils pourront « écrire des contrats en Rust, tout en conservant les autres options ». Il prévoit aussi que « Solidity et Vyper resteront populaires pour leur élégance dans la logique des smart contracts ». L’accès à la chaîne d’outils LLVM et à de vastes bibliothèques de langages populaires sera révolutionnaire. Vitalik compare cela à une « expérience à la NodeJS », où les développeurs peuvent écrire du code on-chain et off-chain dans le même langage, unifiant le développement.

Pour les utilisateurs, cette transformation se traduira par des coûts plus bas et des performances accrues. On s’attend à une réduction des coûts de preuve d’environ 100 fois, passant de quelques dollars à quelques centimes, voire moins, par transaction. Cela se traduira directement par des frais L1 et L2 plus bas. Cette viabilité économique ouvrira la voie au « Gigagas L1 », visant environ 10 000 TPS, préparant le terrain pour des applications on-chain plus complexes et de plus grande valeur.

Succinct Labs et SP1 : construire l’avenir de la preuve dès aujourd’hui

Ethereum est prêt à décoller. « Étendre le L1, étendre les blocs » est une priorité stratégique au sein du cluster de protocoles EF. On s’attend à des gains de performance significatifs dans les 6 à 12 prochains mois.

Des équipes comme Succinct Labs démontrent déjà les avantages théoriques de RISC-V dans la pratique, validant ainsi cette proposition.

SP1, développé par Succinct Labs, est un zkVM open source haute performance basé sur RISC-V, prouvant la viabilité de cette nouvelle approche architecturale. SP1 adopte une philosophie « centrée sur les précompilés », résolvant parfaitement les goulots d’étranglement cryptographiques de l’EVM. Contrairement à la méthode traditionnelle, lente et codée en dur, SP1 délègue des opérations intensives comme le hash Keccak à des circuits ZK spécialisés et optimisés, appelés via l’instruction ECALL standard. Cette méthode combine la performance du matériel sur-mesure et la flexibilité logicielle, offrant aux développeurs une solution plus efficace et évolutive.

L’impact concret de Succinct Labs est déjà visible. Leur produit OP Succinct utilise SP1 pour doter les Optimistic Rollups de capacités Zero-Knowledge (ZK-ify). Comme l’explique Uma Roy, cofondatrice de Succinct :

« Les Rollup utilisant OP Stack n’ont plus besoin d’attendre sept jours pour la finalité et le retrait... la confirmation prend désormais seulement une heure. Ce gain de vitesse est incroyable. »

Cette avancée résout un point de douleur clé pour tout l’écosystème OP Stack. De plus, l’infrastructure de Succinct – Succinct Prover Network – est conçue comme un marché décentralisé de génération de preuves, illustrant un modèle économique viable pour le calcul vérifiable du futur. Leur travail n’est pas qu’une preuve de concept, mais un plan d’action concret pour l’avenir, comme décrit dans cet article.

Comment Ethereum réduit-il les risques

L’un des grands avantages de RISC-V est qu’il rend possible le Graal de la vérification formelle – prouver mathématiquement la correction du système. La spécification de l’EVM, rédigée en langage naturel dans le Yellow Paper, est difficile à formaliser. RISC-V, en revanche, dispose d’une spécification SAIL officielle et lisible par machine, servant de « référence d’or » pour son comportement.

Cela ouvre la voie à une sécurité renforcée. Comme l’a souligné Alex Hicks de la Ethereum Foundation, des travaux sont en cours pour « vérifier formellement les circuits zkVM RISC-V contre la spécification officielle RISC-V extraite dans Lean ». C’est une avancée majeure, transférant la confiance de l’implémentation humaine faillible à la preuve mathématique vérifiable, ouvrant de nouveaux horizons pour la sécurité blockchain.

Principaux risques de la transformation

Bien que le L1 basé sur RISC-V présente de nombreux avantages, il apporte aussi de nouveaux défis complexes.

Problème de mesure du Gas

Créer un modèle de Gas déterministe et équitable pour une architecture d’instructions universelle (ISA) est un problème non résolu. Une simple méthode de comptage des instructions est vulnérable aux attaques par déni de service. Par exemple, un attaquant peut concevoir un programme qui déclenche sans cesse des ratés de cache, consommant beaucoup de ressources pour un coût en Gas très faible. Ce problème menace la stabilité du réseau et le modèle économique.

Sécurité de la chaîne d’outils et problème de « build reproductible »

C’est le risque le plus important et souvent sous-estimé du processus de transformation. Le modèle de sécurité passe de la VM on-chain au compilateur off-chain (comme LLVM), qui est très complexe et connu pour ses failles. Un attaquant pourrait exploiter une faille du compilateur pour transformer un code source inoffensif en bytecode malveillant. De plus, garantir que le binaire compilé on-chain corresponde exactement au code source public – le problème du « build reproductible » – est très difficile. De petites différences dans l’environnement de compilation peuvent générer des binaires différents, affectant la transparence et la confiance. Ces problèmes posent de sérieux défis à la sécurité des développeurs et des utilisateurs.

Stratégies d’atténuation

La voie à suivre nécessite une défense à plusieurs niveaux.

Déploiement progressif

Adopter un plan de transition progressif et multi-étapes est la clé pour gérer les risques. En introduisant d’abord RISC-V comme remplacement des précompilés, puis en exploitant un environnement à double VM, la communauté peut acquérir de l’expérience et de la confiance dans un cadre à faible risque, évitant tout changement irréversible. Cette approche graduelle offre une base stable à la transformation technique.

Audit complet : fuzzing et vérification formelle

Bien que la vérification formelle soit l’objectif ultime, elle doit être associée à des tests continus et intensifs. Comme l’a montré Valentine de Diligence Security lors d’un appel Ethproofs, leur outil de fuzzing Argus a déjà découvert 11 failles critiques dans les principaux zkVM. Cela prouve que même les systèmes les mieux conçus peuvent receler des vulnérabilités détectables uniquement par des tests adversariaux rigoureux. La combinaison du fuzzing et de la vérification formelle renforce la sécurité du système.

Standardisation

Pour éviter la fragmentation de l’écosystème, la communauté doit adopter une configuration RISC-V unique et standardisée. Il pourrait s’agir de la combinaison RV64GC et ABI compatible Linux, car elle bénéficie du plus large support dans les langages et outils principaux, maximisant les avantages du nouvel écosystème. La standardisation améliore l’efficacité des développeurs et pose des bases solides pour le développement à long terme de l’écosystème.

L’avenir vérifiable d’Ethereum

La proposition de remplacer l’Ethereum Virtual Machine (EVM) par RISC-V n’est pas une simple mise à niveau incrémentale, mais une refonte fondamentale de la couche d’exécution d’Ethereum. Cette vision ambitieuse vise à résoudre les goulots d’étranglement d’évolutivité, à simplifier la complexité du protocole et à aligner la plateforme sur l’écosystème informatique universel. Malgré les défis techniques et sociaux, les bénéfices stratégiques à long terme justifient cet effort audacieux.

Cette transformation implique une série de compromis clés :

· L’équilibre entre l’énorme gain de performance d’une architecture native ZK et le besoin urgent de compatibilité ascendante ;

· Le compromis entre la sécurité accrue d’un protocole simplifié et l’inertie du vaste effet réseau de l’EVM ;

· Le choix entre la puissance d’un écosystème universel et les risques liés à la dépendance à des chaînes d’outils tierces complexes.

En fin de compte, cette transformation architecturale sera la clé pour tenir la promesse du « Lean Execution » et un élément central de la vision « Lean Ethereum ». Elle transformera le L1 d’Ethereum d’une simple plateforme de smart contracts en une couche de règlement et de disponibilité des données efficace et sécurisée, conçue pour soutenir l’univers du calcul vérifiable.

Comme le dit Vitalik Buterin, « le but final est... de fournir des ZK-snark pour tout ».

Des projets comme Ethproofs fournissent des données objectives et une plateforme collaborative pour cette transformation, tandis que l’équipe Succinct Labs, avec son SP1 zkVM, offre un plan d’action concret pour cet avenir. En adoptant RISC-V, Ethereum résout non seulement ses propres goulots d’étranglement d’évolutivité, mais se positionne aussi comme la couche de confiance fondamentale de la prochaine génération d’Internet – propulsée par le troisième grand primitif cryptographique après le hash et la signature : le SNARK.

Prouver le logiciel du monde, ouvrir une nouvelle ère cryptographique.

En savoir plus :