Auteur original : jaehaerys.eth, chercheur en cryptographie
Original traduit : Shenchao TechFlow
Résumé
Ethereum se prépare à accueillir la transformation architecturale la plus importante depuis sa création : remplacer l'EVM par RISC-V.
La raison est simple : dans un avenir centré sur les preuves à divulgation nulle de connaissance (ZK), l'EVM est devenu un goulot d'étranglement en matière de performance :
· Actuellement, le zkEVM dépend d'un interpréteur, ce qui entraîne une diminution des performances de 50 à 800 fois ;
· Le module de précompilation rend le protocole plus complexe et augmente les risques ;
· La conception de la pile de 256 bits est très inefficace lors de la génération de preuves.
La solution RISC-V :
· Design minimaliste (environ 47 instructions de base) + écosystème LLVM mature (supporte des langages comme Rust, C++, Go, etc.) ;
· Devenu de facto la norme zkVM (90 % des projets l'adoptent) ;
· Dispose d'une spécification SAIL formelle (par rapport au livre jaune vague) → Mise en œuvre d'une validation stricte ;
· Le chemin de preuve matérielle (ASICs/FPGAs) est en cours de test (SP1, Nervos, Cartesi, etc.).
Le processus de migration se divise en trois étapes :
· Remplacer RISC-V par un module précompilé (test à faible risque);
· L'ère des doubles machines virtuelles : EVM et RISC-V coexistent et sont entièrement interopérables ;
· Réimplémentation de l'EVM dans RISC-V (stratégie Rosetta).
Impact sur l'écosystème :
· Les Rollups optimistes (comme Arbitrum et Optimism) doivent reconstruire le mécanisme de preuve de fraude ;
· Les Rollups de type Zero-Knowledge (comme Polygon, zkSync, Scroll) bénéficieront d'un avantage énorme → moins cher, plus rapide, plus simple ;
· Les développeurs peuvent utiliser directement des bibliothèques de langages tels que Rust, Go et Python au niveau L1 ;
· Les utilisateurs bénéficieront d'un coût de preuve environ 100 fois inférieur → Vers Gigagas L1 (environ 10 000 TPS).
Finalement, Ethereum évoluera d'une « machine virtuelle de contrats intelligents » en une couche de confiance minimaliste et vérifiable sur Internet, dont l'objectif ultime est de « rendre tout ZK-Snarkisé ».
Le carrefour d'Ethereum
Vitalik Buterin a dit : « La fin inclut... de tout rendre ZK-Snark. »
La fin des preuves à divulgation nulle de connaissance (ZK) est inévitable, et son argument central est très simple : Ethereum se reconstruit à partir de zéro, en se basant sur les preuves à divulgation nulle de connaissance. Cela marque le point final technique du protocole - atteignant sa forme ultime grâce à la restructuration de L1, soutenue par des équipes de développement clés (comme Succinct) avec un zkVM haute performance.
Avec cette vision comme point d'arrivée, Ethereum est à un tournant architectural le plus important depuis sa création. Cette discussion ne porte plus sur une mise à niveau progressive, mais sur une reconstruction complète de son cœur de calcul - le remplacement de la machine virtuelle Ethereum (EVM). Cette initiative est la pierre angulaire de la vision plus large de « Lean Ethereum ».
La vision de Lean Ethereum vise à simplifier systématiquement l'ensemble du protocole en le décomposant en trois modules clés : Lean Consensus, Lean Data et Lean Execution. Et dans les questions centrales de Lean Execution, le point le plus crucial est : l'EVM, en tant que moteur de la révolution des contrats intelligents, est-il devenu le principal goulot d'étranglement du développement futur d'Ethereum ?
Comme l'a dit Justin Drake de la Fondation Ethereum, l'objectif à long terme d'Ethereum a toujours été de « Snarkifier tout » (Snarkify everything), un outil puissant capable d'améliorer les différentes couches du protocole. Cependant, pendant longtemps, cet objectif ressemblait plus à un « blueprint inaccessibile », car sa réalisation nécessite le concept de preuve en temps réel (real-time proving). Et maintenant, avec la preuve en temps réel qui devient progressivement une réalité, l'inefficacité théorique de l'EVM s'est transformée en un problème pratique urgent à résoudre.
Cet article analysera en profondeur les arguments techniques et stratégiques liés à la migration d'Ethereum L1 vers l'architecture de jeu d'instructions RISC-V. Cette initiative devrait non seulement libérer une évolutivité sans précédent, mais aussi simplifier la structure du protocole et aligner Ethereum avec l'avenir du calcul vérifiable.
Qu'est-ce qui a vraiment changé ?
Avant d'explorer le « pourquoi », il est d'abord nécessaire de clarifier « quoi » est en train de changer.
EVM (Machine Virtuelle Ethereum) est l'environnement d'exécution des contrats intelligents Ethereum, surnommé le « ordinateur mondial » qui traite les transactions et met à jour l'état de la blockchain. Au fil des ans, sa conception a été révolutionnaire, posant les bases de la finance décentralisée (DeFi) et de l'écosystème NFT. Cependant, cette architecture sur mesure, datant de près de dix ans, a aujourd'hui accumulé une quantité importante de dette technique.
En revanche, RISC-V n'est pas un produit, mais une norme ouverte - un « alphabet » de conception de processeurs gratuit et universel. Comme l'a souligné Jeremy Bruestle lors de la conférence Ethproofs, ses principes clés en font un excellent choix pour ce rôle :
· Minimalisme : L'ensemble d'instructions de base de RISC-V est extrêmement simple, ne contenant qu'environ 40 à 47 instructions. Comme le dit Jeremy, cela le rend « presque parfait pour les cas d'utilisation de la machine universelle super minimaliste dont nous avons besoin ».
· Conception modulaire : des fonctionnalités plus complexes sont ajoutées via des extensions optionnelles. Cette caractéristique est essentielle car elle permet de garder le cœur 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, y compris le compilateur LLVM, permettant aux développeurs d'utiliser des langages de programmation populaires tels que Rust, C++ et Go. Comme le mentionne Justin Drake : « Les outils autour des compilateurs sont très riches, tandis que la construction de compilateurs est extrêmement difficile... Ainsi, la valeur de ces chaînes d'outils de compilation est très élevée. » RISC-V permet à Ethereum d'hériter gratuitement de ces outils prêts à l'emploi.
Problème de coût de l'interpréteur
Les raisons de promouvoir un remplacement de l'EVM ne sont pas dues à un seul défaut, mais plutôt à la convergence de plusieurs limitations fondamentales qui ne peuvent plus être ignorées dans un contexte futur centré sur les preuves à divulgation nulle de connaissance. Ces limitations incluent les goulets d'étranglement de performance dans les systèmes de preuves à divulgation nulle de connaissance, ainsi que les risques associés à la complexité croissante accumulée à l'intérieur des protocoles.
Le moteur le plus pressant de cette transformation est l'inefficacité inhérente de l'EVM dans les systèmes de preuve à connaissance nulle. Alors qu'Ethereum se tourne progressivement vers un modèle de validation de l'état L1 par des preuves ZK, la performance des prouveurs devient le plus grand goulot d'étranglement.
Le problème réside dans la façon dont le zkEVM fonctionne actuellement. Ils ne font pas de preuve à connaissance zéro directement sur l'EVM, mais sur l'interpréteur de l'EVM, qui est lui-même compilé en RISC-V. Vitalik Buterin a clairement souligné ce problème central :
"... si la façon dont 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 contrats intelligents ? Cela permettrait d'éliminer complètement les coûts de la machine virtuelle externe."
Cette couche d'explication supplémentaire entraîne une perte de performance énorme. Les estimations indiquent que, par rapport à la preuve des programmes natifs, cette couche pourrait entraîner une diminution de performance de 50 à 800 fois. Après avoir optimisé d'autres goulets d'étranglement (comme en passant à l'algorithme de hachage Poseidon), cette partie de l'« exécution des blocs » continuera à représenter 80 à 90 % de tout le temps de preuve, rendant l'EVM le dernier et le plus épineux obstacle à l'extension de L1. En supprimant cette couche, Vitalik s'attend à ce que l'efficacité d'exécution puisse être multipliée par 100.
piège de la dette technique
Pour compenser les insuffisances de performance de l'EVM dans certaines opérations cryptographiques, Ethereum a introduit des contrats précompilés - des fonctionnalités spécialisées directement codées dans le protocole. Bien que cette solution ait semblé pragmatique à l'époque, elle a maintenant conduit à ce que Vitalik Buterin appelle une situation "mauvaise" :
« La précompilation est catastrophique pour nous... elle a considérablement gonflé la bibliothèque de code fiable d'Ethereum... et elle a presque provoqué plusieurs échecs de consensus graves. »
Cette complexité est choquante. Vitalik a donné l'exemple selon lequel le code d'emballage d'un seul contrat précompilé (comme modexp) est plus complexe que tout l'interpréteur RISC-V, et que la logique des précompilés est en réalité encore plus compliquée. Ajouter de nouveaux contrats précompilés nécessite de passer par un processus de hard fork lent et politiquement controversé, ce qui entrave gravement l'innovation des applications qui ont besoin de nouveaux primitives cryptographiques. À cela, Vitalik a tiré une conclusion claire :
« Je pense que nous devrions arrêter d'ajouter de nouveaux contrats précompilés à partir d'aujourd'hui. »
La dette technique de l'architecture d'Ethereum
La conception centrale de l'EVM reflète les priorités d'une époque révolue, mais elle n'est plus adaptée aux besoins informatiques modernes. L'EVM a choisi une architecture de 256 bits pour traiter les valeurs cryptographiques, mais cette architecture est extrêmement inefficace pour les entiers de 32 bits ou 64 bits généralement utilisés dans les contrats intelligents. Cette inefficacité est particulièrement coûteuse dans les systèmes ZK. Comme l'a expliqué Vitalik :
« Lorsque des chiffres plus petits sont utilisés, chaque chiffre ne permet en réalité d'économiser aucune ressource, tandis que la complexité augmente de deux à quatre fois. »
En outre, l'architecture de pile de l'EVM est moins efficace que l'architecture de registre du RISC-V et des CPU modernes. Elle nécessite plus d'instructions pour effectuer les mêmes opérations, ce qui rend également l'optimisation des compilateurs plus complexe.
Ces problèmes - y compris les goulets d'étranglement de performance des preuves ZK, la complexité des précompilations et le choix d'architectures obsolètes - constituent ensemble une raison convaincante et urgente : Ethereum doit dépasser l'EVM et adopter une architecture technologique plus adaptée à l'avenir.
RISC-V Blueprint : Redéfinir l'avenir d'Ethereum sur une base plus solide
Les avantages de RISC-V ne résident pas seulement dans les lacunes de l'EVM, mais aussi dans la puissance intrinsèque de sa philosophie de conception. Son architecture fournit une base robuste, simple et vérifiable, parfaitement adaptée à un environnement à haut risque comme celui d'Ethereum.
Pourquoi les standards ouverts sont-ils supérieurs aux conceptions sur mesure ?
Contrairement aux architectures de jeu d'instructions (ISA) personnalisées qui nécessitent de construire un écosystème logiciel complet à partir de zéro, RISC-V est une norme ouverte mature, possédant trois avantages clés :
écosystème mature
En adoptant RISC-V, Ethereum peut bénéficier des avancées collectives de plusieurs décennies dans le domaine de l'informatique. Comme l'explique Justin Drake, cela offre à Ethereum l'opportunité d'utiliser directement des outils de classe mondiale :
« Il existe un composant d'infrastructure appelé LLVM, qui est une suite d'outils de compilation permettant de compiler des langages de programmation de haut niveau vers l'un des nombreux cibles de backend. L'un des backends pris en charge est RISC-V. Donc, si vous supportez RISC-V, vous pouvez automatiquement prendre en charge tous les langages de haut niveau pris en charge par LLVM. »
Cela a considérablement abaissé le seuil de développement, permettant à des millions de développeurs familiers avec des langages tels que Rust, C++ et Go de commencer facilement.
La philosophie de design minimaliste RISC-V est une caractéristique délibérée, et non une limitation. Son jeu d'instructions de base ne contient qu'environ 47 instructions, ce qui maintient le cœur de la machine virtuelle extrêmement simple. Cette simplicité présente des avantages significatifs en matière de sécurité, car une bibliothèque de code de confiance plus petite est plus facile à auditer et à vérifier formellement.
Les normes factuelles dans le domaine des preuves à divulgation nulle de connaissance. Plus important encore, l'écosystème zkVM a déjà fait un choix. Comme l'a souligné Justin Drake, une tendance claire peut être observée à partir des données d'Ethproofs :
« RISC-V est l'architecture de jeu d'instructions (ISA) leader du backend zkVM. »
Dans les dix zkVM capables de prouver les blocs Ethereum, neuf ont choisi RISC-V comme architecture cible. Cette convergence du marché envoie un signal fort : Ethereum n'adopte pas RISC-V dans une tentative spéculative, mais s'aligne sur une norme déjà validée par un projet construit autour de son avenir en connaissance zéro.
Né pour la confiance, pas seulement pour l'exécution.
En plus d'un écosystème étendu, l'architecture interne de RISC-V est également particulièrement adaptée à la construction de systèmes sécurisés et vérifiables. Tout d'abord, RISC-V dispose d'une spécification formalisée et lisible par machine - SAIL. Cela représente un immense progrès par rapport à la spécification de l'EVM (qui existe principalement sous forme de texte dans le "livre jaune"). Le "livre jaune" présente une certaine ambiguïté, tandis que la spécification SAIL fournit un "standard d'or", capable de soutenir des preuves de correction mathématique essentielles pour protéger des protocoles de grande valeur. Comme l'a mentionné Alex Hicks de la Fondation Ethereum (EF) lors de la conférence Ethproofs, cela permet aux circuits zkVM de se "vérifier directement par rapport à la spécification officielle de RISC-V". Ensuite, RISC-V comprend une architecture privilégiée, qui est une caractéristique souvent négligée mais essentielle pour la sécurité. Elle définit différents niveaux d'opération, comprenant principalement le mode utilisateur (pour des applications non fiables, comme les contrats intelligents) et le mode superviseur (pour un "noyau d'exécution" fiable). Diego de Cartesi a expliqué cela en profondeur :
« Le système d'exploitation lui-même doit se protéger des influences d'autres codes. Il doit isoler l'exécution des différents programmes les uns des autres, et tous ces mécanismes font partie de la norme RISC-V. »
Dans l'architecture RISC-V, les contrats intelligents s'exécutant en mode utilisateur (User Mode) ne peuvent pas accéder directement à l'état de la blockchain. Au lieu de cela, ils doivent émettre une demande à un noyau de confiance s'exécutant en mode superviseur (Supervisor Mode) via une instruction ECALL (appel d'environnement) spéciale. Ce mécanisme établit une frontière de sécurité imposée par le matériel, plus robuste et plus facile à vérifier que le modèle de sandbox logiciel purement basé sur l'EVM.
La vision de Vitalik
Cette transformation est envisagée comme un processus progressif et par étapes, afin d'assurer la stabilité du système et la compatibilité descendante. Comme l'a expliqué le fondateur d'Ethereum, Vitalik Buterin, cette approche vise à réaliser un développement « évolutif », plutôt qu'une transformation « révolutionnaire » radicale.
Première étape : précompiler les substituts
La phase initiale adopte une approche très conservatrice en introduisant des fonctionnalités limitées pour la nouvelle machine virtuelle (VM). Comme l'a suggéré Vitalik Buterin : « Nous pouvons commencer à utiliser la nouvelle VM dans des scénarios limités, par exemple en remplaçant les fonctionnalités précompilées. » Plus précisément, cela suspendra l'ajout de nouvelles fonctionnalités précompilées EVM, remplacées par des programmes RISC-V approuvés par une liste blanche pour réaliser les fonctionnalités nécessaires. Cette approche permet à la nouvelle VM de tester en conditions réelles dans le réseau principal avec un faible risque, tout en servant d'intermédiaire entre les deux environnements d'exécution via le client Ethereum.
Deuxième étape : cohabitation de deux machines virtuelles
La prochaine étape sera « d'ouvrir directement le nouveau VM aux utilisateurs ». Les contrats intelligents peuvent indiquer, par le biais de balises, si leur bytecode est EVM ou RISC-V. La caractéristique clé est de réaliser une interopérabilité transparente : « les deux types de contrats peuvent s'appeler mutuellement. » Cette fonctionnalité sera réalisée par des appels système (ECALL), permettant aux deux machines virtuelles de collaborer au sein du même écosystème.
Troisième étape : EVM en tant que contrat simulé (stratégie « Rosetta »)
L'objectif final est de réaliser une simplification extrême du protocole. À ce stade, « nous considérons l'EVM comme une implémentation au sein de la nouvelle VM. » L'EVM normalisée deviendra un contrat intelligent vérifié formellement fonctionnant sur le RISC-V L1 natif. Cela garantit non seulement un soutien permanent pour les anciennes applications, mais permet également aux développeurs de clients de maintenir uniquement un moteur d'exécution simplifié, réduisant ainsi considérablement la complexité et les coûts de maintenance.
l'effet d'entraînement de l'écosystème
La transition de l'EVM vers RISC-V n'est pas seulement une transformation du protocole central, elle aura un impact profond sur l'ensemble de l'écosystème Ethereum. Cette transformation ne va pas seulement remodeler l'expérience des développeurs, mais elle changera fondamentalement le paysage concurrentiel des solutions Layer-2 et débloquera de nouveaux modèles de validation économique.
Le repositionnement des Rollups : La confrontation entre Optimistic et ZK
L'utilisation de la couche d'exécution RISC-V au niveau L1 aura des impacts radicalement différents sur les deux principaux types de Rollup.
Les Optimistic Rollups (comme Arbitrum, Optimism) sont confrontés à des défis architecturaux. Leur modèle de sécurité repose sur la réexécution des transactions contestées via L1 EVM pour résoudre les preuves de fraude. Si l'EVM de L1 est remplacé, ce modèle s'effondrera complètement. Ces projets feront face à un choix difficile : soit procéder à une refonte majeure pour concevoir un système de preuves de fraude pour le nouveau L1 VM, soit se détacher complètement du modèle de sécurité d'Ethereum.
Comparé à cela, le ZK Rollup obtiendra un énorme avantage stratégique. La grande majorité des ZK Rollups ont déjà adopté RISC-V comme leur architecture de jeu d'instructions interne (ISA). Un L1 « parlant la même langue » lui permettra d'atteindre une intégration plus étroite et plus efficace. Justin Drake a proposé une vision d'avenir pour le « Rollup natif » : L2 devient en réalité une instance spécialisée de l'environnement d'exécution de L1 lui-même, utilisant le VM intégré de L1 pour un règlement sans faille. Cet alignement entraînera les changements suivants :
· Simplification de la pile technologique : l'équipe L2 n'aura plus besoin de construire un mécanisme de pont complexe entre l'environnement d'exécution RISC-V interne et l'EVM.
· Outils et réutilisation de code : Les compilateurs, débogueurs et outils de vérification formelle développés pour l'environnement L1 RISC-V peuvent être utilisés directement par L2, réduisant considérablement les coûts de développement.
· Alignement des incitations économiques : Les frais de Gas de L1 refléteront plus précisément le coût réel de la vérification ZK basée sur RISC-V, formant ainsi un modèle économique plus raisonnable.
Une nouvelle ère pour les développeurs et les utilisateurs
Pour les développeurs Ethereum, cette transformation sera progressive et non destructive.
Pour les développeurs, ils pourront accéder à un écosystème de développement logiciel plus large et plus mature. Comme l'a souligné Vitalik Buterin, les développeurs pourront « écrire des contrats en Rust, tandis que ces options peuvent coexister ». Dans le même temps, il prédit que « Solidity et Vyper resteront populaires à long terme en raison de leur conception élégante dans la logique des contrats intelligents ». L'utilisation de langages de programmation grand public et de leurs vastes ressources de bibliothèques via la chaîne d'outils LLVM, cette transformation sera révolutionnaire. Vitalik la compare à une « expérience de type NodeJS », où les développeurs peuvent écrire du code on-chain et off-chain dans le même langage, réalisant ainsi une intégration du développement.
Pour les utilisateurs, cette transformation apportera finalement une expérience réseau à coût réduit et à performance élevée. On prévoit que le coût de preuve diminuera d'environ 100 fois, passant de quelques dollars par transaction à quelques centimes, voire moins. Cela se traduit directement par des frais L1 et des frais de règlement L2 plus bas. Cette viabilité économique débloquera la vision de « Gigagas L1 », visant à atteindre une performance d'environ 10 000 TPS, ouvrant la voie à des applications on-chain plus complexes et de valeur supérieure à l'avenir.
Succinct Labs et SP1 : Construire la preuve de l'avenir aujourd'hui
Ethereum est sur le point de décoller. « Élargir L1, élargir les blocs » est une tâche stratégique urgente au sein du cluster de protocoles EF. Des améliorations de performance significatives sont attendues dans les 6 à 12 mois à venir.
Des équipes comme Succinct Labs ont déjà démontré dans la pratique les avantages théoriques du RISC-V, et leur travail constitue un solide exemple pour valider cette proposition.
Le SP1 développé par Succinct Labs est un zkVM open-source haute performance basé sur RISC-V, qui valide la faisabilité de nouvelles approches architecturales. Le SP1 adopte la philosophie « centrée sur les précompilations » (precompile-centric), résolvant parfaitement le problème des goulots d'étranglement cryptographiques de l'EVM. Contrairement aux méthodes de précompilation traditionnelles qui dépendent de précompilations lentes et codées en dur, le SP1 décharge des opérations intensives telles que le hachage Keccak dans des circuits ZK spécialement conçus et manuellement optimisés, appelés par des instructions ECALL standard. Cette méthode combine la performance du matériel personnalisé avec la flexibilité du logiciel, offrant aux développeurs une solution plus efficace et évolutive.
L'impact réel de Succinct Labs est déjà visible. Leur produit OP Succinct utilise SP1 pour doter les Optimistic Rollups de capacités de preuve à connaissance nulle (ZK-ify). Comme l'explique Uma Roy, co-fondatrice de Succinct :
« Avec les Rollups utilisant OP Stack, il n'est plus nécessaire d'attendre sept jours pour obtenir une confirmation finale et un retrait... maintenant, il suffit d'une heure pour compléter la confirmation. Cette amélioration de la vitesse est vraiment géniale. »
Cette percée résout un point de douleur clé pour l'ensemble de l'écosystème OP Stack. De plus, l'infrastructure de Succinct - le Succinct Prover Network - est conçue comme un marché de génération de preuves décentralisé, démontrant un modèle économique viable pour le calcul vérifiable de demain. Leur travail n'est pas seulement une preuve de concept, mais aussi un plan futur réalisable, comme décrit dans cet article.
Comment Ethereum réduit les risques
Un des grands avantages de RISC-V est qu'il rend l'objectif du Saint Graal de la vérification formelle - prouver mathématiquement la correction d'un système - réalisable. La spécification de l'EVM est écrite en langage naturel dans le Yellow Paper, ce qui rend la formalisation difficile. En revanche, RISC-V dispose d'une spécification SAIL officielle et lisible par machine, fournissant une "référence d'or" claire pour son comportement.
Cela pave la voie à une sécurité plus robuste. Comme l'a souligné Alex Hicks de la Fondation Ethereum, des travaux sont en cours pour "extraire les circuits zkVM RISC-V et la spécification officielle RISC-V dans Lean pour une validation formelle". C'est une avancée décisive qui déplace la confiance des implémentations humaines sujettes à erreurs vers des preuves mathématiques vérifiables, ouvrant de nouvelles hauteurs à la sécurité de la blockchain.
Les principaux risques de transformation
Bien que l'architecture RISC-V L1 présente de nombreux avantages, elle entraîne également de nouveaux défis complexes.
Problème de mesure de gaz
Créer un modèle de Gas déterministe et équitable pour une architecture d'instruction commune (ISA) est un problème non résolu. Les méthodes simples de comptage des instructions sont vulnérables aux attaques par déni de service. Par exemple, un attaquant peut concevoir un programme qui déclenche de manière répétée des échecs de cache, entraînant une consommation de ressources élevée avec un coût de Gas très faible. Ce type de problème pose de sérieux défis à la stabilité du réseau et au modèle économique.
Sécurité de la chaîne d'outils et problème de « construction reproductible »
C'est le risque le plus important et souvent sous-estimé dans le processus de transformation. Le modèle de sécurité passe d'une dépendance aux machines virtuelles sur la chaîne à une dépendance aux compilateurs en dehors de la chaîne (comme LLVM), et ces compilateurs ont une complexité extrême et contiennent des vulnérabilités connues. Les attaquants peuvent exploiter les vulnérabilités des compilateurs pour transformer un code source apparemment inoffensif en bytecode malveillant. De plus, garantir que les fichiers binaires compilés sur la chaîne correspondent exactement au code source public, c'est-à-dire le problème de "construction reproductible", est également extrêmement difficile. De petites différences dans l'environnement de construction peuvent entraîner la génération de fichiers binaires différents, affectant ainsi la transparence et la confiance. Ces problèmes posent de sérieux défis à la sécurité des développeurs et des utilisateurs.
stratégie d'atténuation
La route vers l'avant nécessite une stratégie de défense multicouche.
Promotion par étapes
Adopter un plan de transition progressif et en plusieurs étapes est la stratégie clé pour faire face aux risques. En introduisant d'abord RISC-V comme solution de précompilation, puis en fonctionnant dans un environnement de double machine virtuelle, la communauté peut accumuler de l'expérience opérationnelle et établir la confiance dans un environnement à faible risque, évitant ainsi toute modification irréversible. Cette approche progressive fournit une base stable pour la transformation technologique.
Audit complet : tests flous et vérification formelle
Bien que la vérification formelle soit l'objectif final, elle doit être combinée avec des tests continus et intensifs. Comme l'a montré Valentine de Diligence Security lors de la conférence téléphonique Ethproofs, leur outil de fuzzing Argus a déjà découvert 11 vulnérabilités critiques en matière de solidité et d'intégrité dans le zkVM leader. Cela démontre que même les systèmes les mieux conçus peuvent contenir des vulnérabilités qui ne peuvent être révélées que par des tests adversariaux rigoureux. La combinaison de fuzzing et de vérification formelle offre une meilleure garantie de sécurité pour les systèmes.
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 d'une combinaison de RV64GC et d'un ABI compatible avec Linux, car cette combinaison bénéficie du soutien le plus large dans les langages de programmation et les outils grand public, maximisant ainsi les avantages du nouvel écosystème. La standardisation peut non seulement améliorer l'efficacité des développeurs, mais aussi établir une base solide pour le développement à long terme de l'écosystème.
L'avenir vérifiable d'Ethereum
La proposition de remplacer la machine virtuelle Ethereum (EVM) par RISC-V n'est pas simplement une mise à niveau progressive, mais une reconstruction fondamentale de la couche d'exécution d'Ethereum. Cette vision ambitieuse vise à résoudre des goulets d'étranglement profonds en matière d'évolutivité, à simplifier la complexité du protocole et à aligner la plateforme avec un écosystème plus vaste dans le domaine du calcul général. Bien que cette transformation fasse face à d'énormes défis techniques et sociaux, ses bénéfices stratégiques à long terme suffisent à justifier cet effort audacieux.
Cette transformation se concentre sur une série de compromis clés :
· L'équilibre entre l'énorme amélioration des performances apportée par l'architecture native ZK et le besoin urgent de compatibilité descendante ;
· Le compromis entre les avantages en termes de sécurité offerts par les protocoles simplifiés et l'inertie des effets de réseau massifs d'EVM ;
· Le choix entre la puissance d'un écosystème universel et les risques associés à la dépendance à des chaînes d'outils tiers complexes.
En fin de compte, cette transformation architecturale sera la clé pour réaliser l'engagement de « Lean Execution » et constituera une partie importante de la vision de « Lean Ethereum ». Elle transformera le L1 d'Ethereum d'une simple plateforme de contrats intelligents en une couche de règlement et de disponibilité des données efficace et sécurisée, spécialement conçue pour soutenir l'immense univers du calcul vérifiable.
Comme l'a dit Vitalik Buterin, « le but est… de fournir ZK-snark pour tout. »
Des projets comme Ethproofs fournissent des données objectives et une plateforme de collaboration pour cette transformation, tandis que l'équipe de Succinct Labs, à travers l'application pratique de son SP1 zkVM, offre une feuille de route opérationnelle pour cet avenir. En adoptant RISC-V, Ethereum ne résout pas seulement son propre goulot d'étranglement en matière d'évolutivité, mais se positionne également comme la couche de confiance fondamentale de la prochaine génération d'Internet - propulsée par le troisième grand principe cryptographique SNARK, après les hachages et les signatures.
La preuve du logiciel mondial, ouvrant une nouvelle ère de cryptographie.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Ethereum ou la plus grande mise à niveau de l'histoire : EVM hors ligne, RISC-V prend le relais
Titre original : Au revoir EVM, Bonjour RISC-V
Auteur original : jaehaerys.eth, chercheur en cryptographie
Original traduit : Shenchao TechFlow
Résumé
Ethereum se prépare à accueillir la transformation architecturale la plus importante depuis sa création : remplacer l'EVM par RISC-V.
La raison est simple : dans un avenir centré sur les preuves à divulgation nulle de connaissance (ZK), l'EVM est devenu un goulot d'étranglement en matière de performance :
· Actuellement, le zkEVM dépend d'un interpréteur, ce qui entraîne une diminution des performances de 50 à 800 fois ;
· Le module de précompilation rend le protocole plus complexe et augmente les risques ;
· La conception de la pile de 256 bits est très inefficace lors de la génération de preuves.
La solution RISC-V :
· Design minimaliste (environ 47 instructions de base) + écosystème LLVM mature (supporte des langages comme Rust, C++, Go, etc.) ;
· Devenu de facto la norme zkVM (90 % des projets l'adoptent) ;
· Dispose d'une spécification SAIL formelle (par rapport au livre jaune vague) → Mise en œuvre d'une validation stricte ;
· Le chemin de preuve matérielle (ASICs/FPGAs) est en cours de test (SP1, Nervos, Cartesi, etc.).
Le processus de migration se divise en trois étapes :
· Remplacer RISC-V par un module précompilé (test à faible risque);
· L'ère des doubles machines virtuelles : EVM et RISC-V coexistent et sont entièrement interopérables ;
· Réimplémentation de l'EVM dans RISC-V (stratégie Rosetta).
Impact sur l'écosystème :
· Les Rollups optimistes (comme Arbitrum et Optimism) doivent reconstruire le mécanisme de preuve de fraude ;
· Les Rollups de type Zero-Knowledge (comme Polygon, zkSync, Scroll) bénéficieront d'un avantage énorme → moins cher, plus rapide, plus simple ;
· Les développeurs peuvent utiliser directement des bibliothèques de langages tels que Rust, Go et Python au niveau L1 ;
· Les utilisateurs bénéficieront d'un coût de preuve environ 100 fois inférieur → Vers Gigagas L1 (environ 10 000 TPS).
Finalement, Ethereum évoluera d'une « machine virtuelle de contrats intelligents » en une couche de confiance minimaliste et vérifiable sur Internet, dont l'objectif ultime est de « rendre tout ZK-Snarkisé ».
Le carrefour d'Ethereum
Vitalik Buterin a dit : « La fin inclut... de tout rendre ZK-Snark. »
La fin des preuves à divulgation nulle de connaissance (ZK) est inévitable, et son argument central est très simple : Ethereum se reconstruit à partir de zéro, en se basant sur les preuves à divulgation nulle de connaissance. Cela marque le point final technique du protocole - atteignant sa forme ultime grâce à la restructuration de L1, soutenue par des équipes de développement clés (comme Succinct) avec un zkVM haute performance.
Avec cette vision comme point d'arrivée, Ethereum est à un tournant architectural le plus important depuis sa création. Cette discussion ne porte plus sur une mise à niveau progressive, mais sur une reconstruction complète de son cœur de calcul - le remplacement de la machine virtuelle Ethereum (EVM). Cette initiative est la pierre angulaire de la vision plus large de « Lean Ethereum ».
La vision de Lean Ethereum vise à simplifier systématiquement l'ensemble du protocole en le décomposant en trois modules clés : Lean Consensus, Lean Data et Lean Execution. Et dans les questions centrales de Lean Execution, le point le plus crucial est : l'EVM, en tant que moteur de la révolution des contrats intelligents, est-il devenu le principal goulot d'étranglement du développement futur d'Ethereum ?
Comme l'a dit Justin Drake de la Fondation Ethereum, l'objectif à long terme d'Ethereum a toujours été de « Snarkifier tout » (Snarkify everything), un outil puissant capable d'améliorer les différentes couches du protocole. Cependant, pendant longtemps, cet objectif ressemblait plus à un « blueprint inaccessibile », car sa réalisation nécessite le concept de preuve en temps réel (real-time proving). Et maintenant, avec la preuve en temps réel qui devient progressivement une réalité, l'inefficacité théorique de l'EVM s'est transformée en un problème pratique urgent à résoudre.
Cet article analysera en profondeur les arguments techniques et stratégiques liés à la migration d'Ethereum L1 vers l'architecture de jeu d'instructions RISC-V. Cette initiative devrait non seulement libérer une évolutivité sans précédent, mais aussi simplifier la structure du protocole et aligner Ethereum avec l'avenir du calcul vérifiable.
Qu'est-ce qui a vraiment changé ?
Avant d'explorer le « pourquoi », il est d'abord nécessaire de clarifier « quoi » est en train de changer.
EVM (Machine Virtuelle Ethereum) est l'environnement d'exécution des contrats intelligents Ethereum, surnommé le « ordinateur mondial » qui traite les transactions et met à jour l'état de la blockchain. Au fil des ans, sa conception a été révolutionnaire, posant les bases de la finance décentralisée (DeFi) et de l'écosystème NFT. Cependant, cette architecture sur mesure, datant de près de dix ans, a aujourd'hui accumulé une quantité importante de dette technique.
En revanche, RISC-V n'est pas un produit, mais une norme ouverte - un « alphabet » de conception de processeurs gratuit et universel. Comme l'a souligné Jeremy Bruestle lors de la conférence Ethproofs, ses principes clés en font un excellent choix pour ce rôle :
· Minimalisme : L'ensemble d'instructions de base de RISC-V est extrêmement simple, ne contenant qu'environ 40 à 47 instructions. Comme le dit Jeremy, cela le rend « presque parfait pour les cas d'utilisation de la machine universelle super minimaliste dont nous avons besoin ».
· Conception modulaire : des fonctionnalités plus complexes sont ajoutées via des extensions optionnelles. Cette caractéristique est essentielle car elle permet de garder le cœur 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, y compris le compilateur LLVM, permettant aux développeurs d'utiliser des langages de programmation populaires tels que Rust, C++ et Go. Comme le mentionne Justin Drake : « Les outils autour des compilateurs sont très riches, tandis que la construction de compilateurs est extrêmement difficile... Ainsi, la valeur de ces chaînes d'outils de compilation est très élevée. » RISC-V permet à Ethereum d'hériter gratuitement de ces outils prêts à l'emploi.
Problème de coût de l'interpréteur
Les raisons de promouvoir un remplacement de l'EVM ne sont pas dues à un seul défaut, mais plutôt à la convergence de plusieurs limitations fondamentales qui ne peuvent plus être ignorées dans un contexte futur centré sur les preuves à divulgation nulle de connaissance. Ces limitations incluent les goulets d'étranglement de performance dans les systèmes de preuves à divulgation nulle de connaissance, ainsi que les risques associés à la complexité croissante accumulée à l'intérieur des protocoles.
Le moteur le plus pressant de cette transformation est l'inefficacité inhérente de l'EVM dans les systèmes de preuve à connaissance nulle. Alors qu'Ethereum se tourne progressivement vers un modèle de validation de l'état L1 par des preuves ZK, la performance des prouveurs devient le plus grand goulot d'étranglement.
Le problème réside dans la façon dont le zkEVM fonctionne actuellement. Ils ne font pas de preuve à connaissance zéro directement sur l'EVM, mais sur l'interpréteur de l'EVM, qui est lui-même compilé en RISC-V. Vitalik Buterin a clairement souligné ce problème central :
"... si la façon dont 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 contrats intelligents ? Cela permettrait d'éliminer complètement les coûts de la machine virtuelle externe."
Cette couche d'explication supplémentaire entraîne une perte de performance énorme. Les estimations indiquent que, par rapport à la preuve des programmes natifs, cette couche pourrait entraîner une diminution de performance de 50 à 800 fois. Après avoir optimisé d'autres goulets d'étranglement (comme en passant à l'algorithme de hachage Poseidon), cette partie de l'« exécution des blocs » continuera à représenter 80 à 90 % de tout le temps de preuve, rendant l'EVM le dernier et le plus épineux obstacle à l'extension de L1. En supprimant cette couche, Vitalik s'attend à ce que l'efficacité d'exécution puisse être multipliée par 100.
piège de la dette technique
Pour compenser les insuffisances de performance de l'EVM dans certaines opérations cryptographiques, Ethereum a introduit des contrats précompilés - des fonctionnalités spécialisées directement codées dans le protocole. Bien que cette solution ait semblé pragmatique à l'époque, elle a maintenant conduit à ce que Vitalik Buterin appelle une situation "mauvaise" :
« La précompilation est catastrophique pour nous... elle a considérablement gonflé la bibliothèque de code fiable d'Ethereum... et elle a presque provoqué plusieurs échecs de consensus graves. »
Cette complexité est choquante. Vitalik a donné l'exemple selon lequel le code d'emballage d'un seul contrat précompilé (comme modexp) est plus complexe que tout l'interpréteur RISC-V, et que la logique des précompilés est en réalité encore plus compliquée. Ajouter de nouveaux contrats précompilés nécessite de passer par un processus de hard fork lent et politiquement controversé, ce qui entrave gravement l'innovation des applications qui ont besoin de nouveaux primitives cryptographiques. À cela, Vitalik a tiré une conclusion claire :
« Je pense que nous devrions arrêter d'ajouter de nouveaux contrats précompilés à partir d'aujourd'hui. »
La dette technique de l'architecture d'Ethereum
La conception centrale de l'EVM reflète les priorités d'une époque révolue, mais elle n'est plus adaptée aux besoins informatiques modernes. L'EVM a choisi une architecture de 256 bits pour traiter les valeurs cryptographiques, mais cette architecture est extrêmement inefficace pour les entiers de 32 bits ou 64 bits généralement utilisés dans les contrats intelligents. Cette inefficacité est particulièrement coûteuse dans les systèmes ZK. Comme l'a expliqué Vitalik :
« Lorsque des chiffres plus petits sont utilisés, chaque chiffre ne permet en réalité d'économiser aucune ressource, tandis que la complexité augmente de deux à quatre fois. »
En outre, l'architecture de pile de l'EVM est moins efficace que l'architecture de registre du RISC-V et des CPU modernes. Elle nécessite plus d'instructions pour effectuer les mêmes opérations, ce qui rend également l'optimisation des compilateurs plus complexe.
Ces problèmes - y compris les goulets d'étranglement de performance des preuves ZK, la complexité des précompilations et le choix d'architectures obsolètes - constituent ensemble une raison convaincante et urgente : Ethereum doit dépasser l'EVM et adopter une architecture technologique plus adaptée à l'avenir.
RISC-V Blueprint : Redéfinir l'avenir d'Ethereum sur une base plus solide
Les avantages de RISC-V ne résident pas seulement dans les lacunes de l'EVM, mais aussi dans la puissance intrinsèque de sa philosophie de conception. Son architecture fournit une base robuste, simple et vérifiable, parfaitement adaptée à un environnement à haut risque comme celui d'Ethereum.
Pourquoi les standards ouverts sont-ils supérieurs aux conceptions sur mesure ?
Contrairement aux architectures de jeu d'instructions (ISA) personnalisées qui nécessitent de construire un écosystème logiciel complet à partir de zéro, RISC-V est une norme ouverte mature, possédant trois avantages clés :
écosystème mature
En adoptant RISC-V, Ethereum peut bénéficier des avancées collectives de plusieurs décennies dans le domaine de l'informatique. Comme l'explique Justin Drake, cela offre à Ethereum l'opportunité d'utiliser directement des outils de classe mondiale :
« Il existe un composant d'infrastructure appelé LLVM, qui est une suite d'outils de compilation permettant de compiler des langages de programmation de haut niveau vers l'un des nombreux cibles de backend. L'un des backends pris en charge est RISC-V. Donc, si vous supportez RISC-V, vous pouvez automatiquement prendre en charge tous les langages de haut niveau pris en charge par LLVM. »
Cela a considérablement abaissé le seuil de développement, permettant à des millions de développeurs familiers avec des langages tels que Rust, C++ et Go de commencer facilement.
La philosophie de design minimaliste RISC-V est une caractéristique délibérée, et non une limitation. Son jeu d'instructions de base ne contient qu'environ 47 instructions, ce qui maintient le cœur de la machine virtuelle extrêmement simple. Cette simplicité présente des avantages significatifs en matière de sécurité, car une bibliothèque de code de confiance plus petite est plus facile à auditer et à vérifier formellement.
Les normes factuelles dans le domaine des preuves à divulgation nulle de connaissance. Plus important encore, l'écosystème zkVM a déjà fait un choix. Comme l'a souligné Justin Drake, une tendance claire peut être observée à partir des données d'Ethproofs :
« RISC-V est l'architecture de jeu d'instructions (ISA) leader du backend zkVM. »
Dans les dix zkVM capables de prouver les blocs Ethereum, neuf ont choisi RISC-V comme architecture cible. Cette convergence du marché envoie un signal fort : Ethereum n'adopte pas RISC-V dans une tentative spéculative, mais s'aligne sur une norme déjà validée par un projet construit autour de son avenir en connaissance zéro.
Né pour la confiance, pas seulement pour l'exécution.
En plus d'un écosystème étendu, l'architecture interne de RISC-V est également particulièrement adaptée à la construction de systèmes sécurisés et vérifiables. Tout d'abord, RISC-V dispose d'une spécification formalisée et lisible par machine - SAIL. Cela représente un immense progrès par rapport à la spécification de l'EVM (qui existe principalement sous forme de texte dans le "livre jaune"). Le "livre jaune" présente une certaine ambiguïté, tandis que la spécification SAIL fournit un "standard d'or", capable de soutenir des preuves de correction mathématique essentielles pour protéger des protocoles de grande valeur. Comme l'a mentionné Alex Hicks de la Fondation Ethereum (EF) lors de la conférence Ethproofs, cela permet aux circuits zkVM de se "vérifier directement par rapport à la spécification officielle de RISC-V". Ensuite, RISC-V comprend une architecture privilégiée, qui est une caractéristique souvent négligée mais essentielle pour la sécurité. Elle définit différents niveaux d'opération, comprenant principalement le mode utilisateur (pour des applications non fiables, comme les contrats intelligents) et le mode superviseur (pour un "noyau d'exécution" fiable). Diego de Cartesi a expliqué cela en profondeur :
« Le système d'exploitation lui-même doit se protéger des influences d'autres codes. Il doit isoler l'exécution des différents programmes les uns des autres, et tous ces mécanismes font partie de la norme RISC-V. »
Dans l'architecture RISC-V, les contrats intelligents s'exécutant en mode utilisateur (User Mode) ne peuvent pas accéder directement à l'état de la blockchain. Au lieu de cela, ils doivent émettre une demande à un noyau de confiance s'exécutant en mode superviseur (Supervisor Mode) via une instruction ECALL (appel d'environnement) spéciale. Ce mécanisme établit une frontière de sécurité imposée par le matériel, plus robuste et plus facile à vérifier que le modèle de sandbox logiciel purement basé sur l'EVM.
La vision de Vitalik
Cette transformation est envisagée comme un processus progressif et par étapes, afin d'assurer la stabilité du système et la compatibilité descendante. Comme l'a expliqué le fondateur d'Ethereum, Vitalik Buterin, cette approche vise à réaliser un développement « évolutif », plutôt qu'une transformation « révolutionnaire » radicale.
Première étape : précompiler les substituts
La phase initiale adopte une approche très conservatrice en introduisant des fonctionnalités limitées pour la nouvelle machine virtuelle (VM). Comme l'a suggéré Vitalik Buterin : « Nous pouvons commencer à utiliser la nouvelle VM dans des scénarios limités, par exemple en remplaçant les fonctionnalités précompilées. » Plus précisément, cela suspendra l'ajout de nouvelles fonctionnalités précompilées EVM, remplacées par des programmes RISC-V approuvés par une liste blanche pour réaliser les fonctionnalités nécessaires. Cette approche permet à la nouvelle VM de tester en conditions réelles dans le réseau principal avec un faible risque, tout en servant d'intermédiaire entre les deux environnements d'exécution via le client Ethereum.
Deuxième étape : cohabitation de deux machines virtuelles
La prochaine étape sera « d'ouvrir directement le nouveau VM aux utilisateurs ». Les contrats intelligents peuvent indiquer, par le biais de balises, si leur bytecode est EVM ou RISC-V. La caractéristique clé est de réaliser une interopérabilité transparente : « les deux types de contrats peuvent s'appeler mutuellement. » Cette fonctionnalité sera réalisée par des appels système (ECALL), permettant aux deux machines virtuelles de collaborer au sein du même écosystème.
Troisième étape : EVM en tant que contrat simulé (stratégie « Rosetta »)
L'objectif final est de réaliser une simplification extrême du protocole. À ce stade, « nous considérons l'EVM comme une implémentation au sein de la nouvelle VM. » L'EVM normalisée deviendra un contrat intelligent vérifié formellement fonctionnant sur le RISC-V L1 natif. Cela garantit non seulement un soutien permanent pour les anciennes applications, mais permet également aux développeurs de clients de maintenir uniquement un moteur d'exécution simplifié, réduisant ainsi considérablement la complexité et les coûts de maintenance.
l'effet d'entraînement de l'écosystème
La transition de l'EVM vers RISC-V n'est pas seulement une transformation du protocole central, elle aura un impact profond sur l'ensemble de l'écosystème Ethereum. Cette transformation ne va pas seulement remodeler l'expérience des développeurs, mais elle changera fondamentalement le paysage concurrentiel des solutions Layer-2 et débloquera de nouveaux modèles de validation économique.
Le repositionnement des Rollups : La confrontation entre Optimistic et ZK
L'utilisation de la couche d'exécution RISC-V au niveau L1 aura des impacts radicalement différents sur les deux principaux types de Rollup.
Les Optimistic Rollups (comme Arbitrum, Optimism) sont confrontés à des défis architecturaux. Leur modèle de sécurité repose sur la réexécution des transactions contestées via L1 EVM pour résoudre les preuves de fraude. Si l'EVM de L1 est remplacé, ce modèle s'effondrera complètement. Ces projets feront face à un choix difficile : soit procéder à une refonte majeure pour concevoir un système de preuves de fraude pour le nouveau L1 VM, soit se détacher complètement du modèle de sécurité d'Ethereum.
Comparé à cela, le ZK Rollup obtiendra un énorme avantage stratégique. La grande majorité des ZK Rollups ont déjà adopté RISC-V comme leur architecture de jeu d'instructions interne (ISA). Un L1 « parlant la même langue » lui permettra d'atteindre une intégration plus étroite et plus efficace. Justin Drake a proposé une vision d'avenir pour le « Rollup natif » : L2 devient en réalité une instance spécialisée de l'environnement d'exécution de L1 lui-même, utilisant le VM intégré de L1 pour un règlement sans faille. Cet alignement entraînera les changements suivants :
· Simplification de la pile technologique : l'équipe L2 n'aura plus besoin de construire un mécanisme de pont complexe entre l'environnement d'exécution RISC-V interne et l'EVM.
· Outils et réutilisation de code : Les compilateurs, débogueurs et outils de vérification formelle développés pour l'environnement L1 RISC-V peuvent être utilisés directement par L2, réduisant considérablement les coûts de développement.
· Alignement des incitations économiques : Les frais de Gas de L1 refléteront plus précisément le coût réel de la vérification ZK basée sur RISC-V, formant ainsi un modèle économique plus raisonnable.
Une nouvelle ère pour les développeurs et les utilisateurs
Pour les développeurs Ethereum, cette transformation sera progressive et non destructive.
Pour les développeurs, ils pourront accéder à un écosystème de développement logiciel plus large et plus mature. Comme l'a souligné Vitalik Buterin, les développeurs pourront « écrire des contrats en Rust, tandis que ces options peuvent coexister ». Dans le même temps, il prédit que « Solidity et Vyper resteront populaires à long terme en raison de leur conception élégante dans la logique des contrats intelligents ». L'utilisation de langages de programmation grand public et de leurs vastes ressources de bibliothèques via la chaîne d'outils LLVM, cette transformation sera révolutionnaire. Vitalik la compare à une « expérience de type NodeJS », où les développeurs peuvent écrire du code on-chain et off-chain dans le même langage, réalisant ainsi une intégration du développement.
Pour les utilisateurs, cette transformation apportera finalement une expérience réseau à coût réduit et à performance élevée. On prévoit que le coût de preuve diminuera d'environ 100 fois, passant de quelques dollars par transaction à quelques centimes, voire moins. Cela se traduit directement par des frais L1 et des frais de règlement L2 plus bas. Cette viabilité économique débloquera la vision de « Gigagas L1 », visant à atteindre une performance d'environ 10 000 TPS, ouvrant la voie à des applications on-chain plus complexes et de valeur supérieure à l'avenir.
Succinct Labs et SP1 : Construire la preuve de l'avenir aujourd'hui
Ethereum est sur le point de décoller. « Élargir L1, élargir les blocs » est une tâche stratégique urgente au sein du cluster de protocoles EF. Des améliorations de performance significatives sont attendues dans les 6 à 12 mois à venir.
Des équipes comme Succinct Labs ont déjà démontré dans la pratique les avantages théoriques du RISC-V, et leur travail constitue un solide exemple pour valider cette proposition.
Le SP1 développé par Succinct Labs est un zkVM open-source haute performance basé sur RISC-V, qui valide la faisabilité de nouvelles approches architecturales. Le SP1 adopte la philosophie « centrée sur les précompilations » (precompile-centric), résolvant parfaitement le problème des goulots d'étranglement cryptographiques de l'EVM. Contrairement aux méthodes de précompilation traditionnelles qui dépendent de précompilations lentes et codées en dur, le SP1 décharge des opérations intensives telles que le hachage Keccak dans des circuits ZK spécialement conçus et manuellement optimisés, appelés par des instructions ECALL standard. Cette méthode combine la performance du matériel personnalisé avec la flexibilité du logiciel, offrant aux développeurs une solution plus efficace et évolutive.
L'impact réel de Succinct Labs est déjà visible. Leur produit OP Succinct utilise SP1 pour doter les Optimistic Rollups de capacités de preuve à connaissance nulle (ZK-ify). Comme l'explique Uma Roy, co-fondatrice de Succinct :
« Avec les Rollups utilisant OP Stack, il n'est plus nécessaire d'attendre sept jours pour obtenir une confirmation finale et un retrait... maintenant, il suffit d'une heure pour compléter la confirmation. Cette amélioration de la vitesse est vraiment géniale. »
Cette percée résout un point de douleur clé pour l'ensemble de l'écosystème OP Stack. De plus, l'infrastructure de Succinct - le Succinct Prover Network - est conçue comme un marché de génération de preuves décentralisé, démontrant un modèle économique viable pour le calcul vérifiable de demain. Leur travail n'est pas seulement une preuve de concept, mais aussi un plan futur réalisable, comme décrit dans cet article.
Comment Ethereum réduit les risques
Un des grands avantages de RISC-V est qu'il rend l'objectif du Saint Graal de la vérification formelle - prouver mathématiquement la correction d'un système - réalisable. La spécification de l'EVM est écrite en langage naturel dans le Yellow Paper, ce qui rend la formalisation difficile. En revanche, RISC-V dispose d'une spécification SAIL officielle et lisible par machine, fournissant une "référence d'or" claire pour son comportement.
Cela pave la voie à une sécurité plus robuste. Comme l'a souligné Alex Hicks de la Fondation Ethereum, des travaux sont en cours pour "extraire les circuits zkVM RISC-V et la spécification officielle RISC-V dans Lean pour une validation formelle". C'est une avancée décisive qui déplace la confiance des implémentations humaines sujettes à erreurs vers des preuves mathématiques vérifiables, ouvrant de nouvelles hauteurs à la sécurité de la blockchain.
Les principaux risques de transformation
Bien que l'architecture RISC-V L1 présente de nombreux avantages, elle entraîne également de nouveaux défis complexes.
Problème de mesure de gaz
Créer un modèle de Gas déterministe et équitable pour une architecture d'instruction commune (ISA) est un problème non résolu. Les méthodes simples de comptage des instructions sont vulnérables aux attaques par déni de service. Par exemple, un attaquant peut concevoir un programme qui déclenche de manière répétée des échecs de cache, entraînant une consommation de ressources élevée avec un coût de Gas très faible. Ce type de problème pose de sérieux défis à la stabilité du réseau et au modèle économique.
Sécurité de la chaîne d'outils et problème de « construction reproductible »
C'est le risque le plus important et souvent sous-estimé dans le processus de transformation. Le modèle de sécurité passe d'une dépendance aux machines virtuelles sur la chaîne à une dépendance aux compilateurs en dehors de la chaîne (comme LLVM), et ces compilateurs ont une complexité extrême et contiennent des vulnérabilités connues. Les attaquants peuvent exploiter les vulnérabilités des compilateurs pour transformer un code source apparemment inoffensif en bytecode malveillant. De plus, garantir que les fichiers binaires compilés sur la chaîne correspondent exactement au code source public, c'est-à-dire le problème de "construction reproductible", est également extrêmement difficile. De petites différences dans l'environnement de construction peuvent entraîner la génération de fichiers binaires différents, affectant ainsi la transparence et la confiance. Ces problèmes posent de sérieux défis à la sécurité des développeurs et des utilisateurs.
stratégie d'atténuation
La route vers l'avant nécessite une stratégie de défense multicouche.
Promotion par étapes
Adopter un plan de transition progressif et en plusieurs étapes est la stratégie clé pour faire face aux risques. En introduisant d'abord RISC-V comme solution de précompilation, puis en fonctionnant dans un environnement de double machine virtuelle, la communauté peut accumuler de l'expérience opérationnelle et établir la confiance dans un environnement à faible risque, évitant ainsi toute modification irréversible. Cette approche progressive fournit une base stable pour la transformation technologique.
Audit complet : tests flous et vérification formelle
Bien que la vérification formelle soit l'objectif final, elle doit être combinée avec des tests continus et intensifs. Comme l'a montré Valentine de Diligence Security lors de la conférence téléphonique Ethproofs, leur outil de fuzzing Argus a déjà découvert 11 vulnérabilités critiques en matière de solidité et d'intégrité dans le zkVM leader. Cela démontre que même les systèmes les mieux conçus peuvent contenir des vulnérabilités qui ne peuvent être révélées que par des tests adversariaux rigoureux. La combinaison de fuzzing et de vérification formelle offre une meilleure garantie de sécurité pour les systèmes.
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 d'une combinaison de RV64GC et d'un ABI compatible avec Linux, car cette combinaison bénéficie du soutien le plus large dans les langages de programmation et les outils grand public, maximisant ainsi les avantages du nouvel écosystème. La standardisation peut non seulement améliorer l'efficacité des développeurs, mais aussi établir une base solide pour le développement à long terme de l'écosystème.
L'avenir vérifiable d'Ethereum
La proposition de remplacer la machine virtuelle Ethereum (EVM) par RISC-V n'est pas simplement une mise à niveau progressive, mais une reconstruction fondamentale de la couche d'exécution d'Ethereum. Cette vision ambitieuse vise à résoudre des goulets d'étranglement profonds en matière d'évolutivité, à simplifier la complexité du protocole et à aligner la plateforme avec un écosystème plus vaste dans le domaine du calcul général. Bien que cette transformation fasse face à d'énormes défis techniques et sociaux, ses bénéfices stratégiques à long terme suffisent à justifier cet effort audacieux.
Cette transformation se concentre sur une série de compromis clés :
· L'équilibre entre l'énorme amélioration des performances apportée par l'architecture native ZK et le besoin urgent de compatibilité descendante ;
· Le compromis entre les avantages en termes de sécurité offerts par les protocoles simplifiés et l'inertie des effets de réseau massifs d'EVM ;
· Le choix entre la puissance d'un écosystème universel et les risques associés à la dépendance à des chaînes d'outils tiers complexes.
En fin de compte, cette transformation architecturale sera la clé pour réaliser l'engagement de « Lean Execution » et constituera une partie importante de la vision de « Lean Ethereum ». Elle transformera le L1 d'Ethereum d'une simple plateforme de contrats intelligents en une couche de règlement et de disponibilité des données efficace et sécurisée, spécialement conçue pour soutenir l'immense univers du calcul vérifiable.
Comme l'a dit Vitalik Buterin, « le but est… de fournir ZK-snark pour tout. »
Des projets comme Ethproofs fournissent des données objectives et une plateforme de collaboration pour cette transformation, tandis que l'équipe de Succinct Labs, à travers l'application pratique de son SP1 zkVM, offre une feuille de route opérationnelle pour cet avenir. En adoptant RISC-V, Ethereum ne résout pas seulement son propre goulot d'étranglement en matière d'évolutivité, mais se positionne également comme la couche de confiance fondamentale de la prochaine génération d'Internet - propulsée par le troisième grand principe cryptographique SNARK, après les hachages et les signatures.
La preuve du logiciel mondial, ouvrant une nouvelle ère de cryptographie.