Ethereum se prépare à accueillir sa 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 à connaissance nulle (ZK), l'EVM est devenu un goulot d'étranglement en termes de performance :
Actuellement, le zkEVM dépend d'un interpréteur, ce qui entraîne un ralentissement 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 épuré (environ 47 instructions de base) + écosystème LLVM mature (prend en charge des langages comme Rust, C++, Go, etc.) ;
est devenu le standard de facto zkVM (90 % des projets l'adoptent) ;
Possède une norme SAIL formelle (par rapport au livre jaune flou) → réalise une validation stricte ;
Le chemin de la preuve matérielle (ASICs/FPGA) 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 double machines virtuelles : EVM et RISC-V coexistent et sont complètement interopérables ;
Réimplémenter 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) auront un énorme avantage → moins chers, plus rapides, plus simples ;
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 contrat intelligent" vers une couche de confiance minimaliste et vérifiable sur Internet, dont l'objectif ultime est de "rendre tout ZK-Snarké".
Le carrefour d'Ethereum
Vitalik Buterin a dit : « La destination inclut… faire en sorte que tout soit ZK-Snarké. »
La fin des preuves à connaissance nulle (ZK) est inévitable, et son argument central est très simple : Ethereum se reconstruit à partir de zéro, sur la base des preuves à connaissance nulle. Cela marque le point final technique du protocole - en atteignant sa forme ultime grâce à la reconstruction de L1, soutenue par des équipes de développement clés (comme Succinct) avec un zkVM haute performance.
Avec cette vision comme point d'achèvement, Ethereum se trouve à un tournant architectural le plus important depuis sa création. Cette discussion ne porte plus sur des mises à jour progressives, mais sur une reconstruction complète de son noyau de calcul - le remplacement de la machine virtuelle Ethereum (EVM). Cette initiative est la pierre angulaire d'une vision plus large de "Lean Ethereum".
La vision de Lean Ethereum vise à simplifier systématiquement l'ensemble du protocole en le divisant en trois modules principaux : Lean Consensus, Lean Data et Lean Execution. Dans les problèmes centraux de Lean Execution, le point le plus crucial est le suivant : en tant que moteur de la révolution des contrats intelligents, l'EVM 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 puissant outil capable d'améliorer toutes les couches du protocole. Cependant, pendant longtemps, cet objectif ressemblait davantage à un "plan inaccessibile", car sa réalisation nécessitait 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 de la migration de l'Ethereum L1 vers l'architecture d'ensemble d'instructions RISC-V. Cette initiative devrait non seulement libérer une évolutivité sans précédent, mais également simplifier la structure du protocole et aligner Ethereum sur 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 "ce qui" est en train de changer.
EVM (Machine Virtuelle Ethereum) est l'environnement d'exécution des contrats intelligents Ethereum, souvent qualifié d'« ordinateur mondial » chargé de traiter les transactions et de mettre à 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, conçue il y a près de dix ans, a désormais accumulé une quantité importante de dettes techniques.
En comparaison, 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 parfaitement adapté aux cas d'utilisation de notre machine universelle super minimaliste."
Conception modulaire : des fonctionnalités plus complexes peuvent être ajoutées par des extensions optionnelles. Cette caractéristique est essentielle car elle permet au cœur de rester simple tout en étendant les fonctionnalités selon les besoins, sans imposer une complexité inutile au protocole de base.
Écosystème ouvert : RISC-V dispose 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 l'a mentionné Justin Drake : « Les outils entourant le compilateur sont très riches, et la construction du compilateur est extrêmement difficile... Par conséquent, la valeur de posséder ces chaînes d'outils de compilateur 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 remplacer l'EVM ne relèvent pas d'un seul défaut, mais de la confluence de plusieurs limitations fondamentales, qui ne peuvent plus être ignorées dans le 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 découlant de la complexité croissante accumulée au sein des protocoles.
Problèmes de coût d'interpréteur
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 évolue progressivement vers un modèle de validation de l'état L1 par des preuves ZK, la performance des prouveurs devient le plus grand goulet d'étranglement.
Le problème réside dans la façon dont le zkEVM fonctionne actuellement. Ils ne font pas de preuves à connaissance nulle directement sur l'EVM, mais plutôt 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 mise en œuvre de zkVM consiste à compiler l'exécution de l'EVM en un contenu qui devient finalement du code RISC-V, pourquoi ne pas exposer directement le RISC-V sous-jacent aux développeurs de contrats intelligents ? Cela pourrait complètement éliminer les frais de la machine virtuelle extérieure."
Cette couche d'explications supplémentaires entraîne une énorme perte de performance. Les estimations indiquent que, par rapport à la preuve de programmes natifs, cette couche pourrait entraîner une diminution de performance de 50 à 800 fois. Après avoir optimisé d'autres goulets d'étranglement (par exemple 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, faisant de l'EVM le dernier et le plus difficile obstacle à l'extension de L1. En supprimant cette couche, Vitalik s'attend à ce que l'efficacité d'exécution puisse être améliorée par 100 fois.
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 aujourd'hui provoqué ce que Vitalik Buterin appelle une "mauvaise" situation :
"La précompilation est catastrophique pour nous... elle a considérablement gonflé la bibliothèque de code fiable d'Ethereum... et elle a presque causé de graves problèmes de consensus à plusieurs reprises."
Cette complexité est choquante. Vitalik illustre que le code d'emballage d'un seul contrat précompilé (comme modexp) est plus complexe que l'ensemble de l'interpréteur RISC-V, et la logique des précompilés est en réalité encore plus compliquée. Ajouter de nouveaux contrats précompilés nécessite un processus de hard fork lent et politiquement controversé, ce qui entrave gravement l'innovation des applications nécessitant de nouveaux primitives cryptographiques. À ce sujet, Vitalik a tiré des conclusions claires :
« 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 fondamentale de l'EVM reflète les priorités d'une époque passée, mais elle n'est plus adaptée aux exigences de calcul modernes. L'EVM a choisi une architecture de 256 bits pour traiter des valeurs cryptographiques, mais cette architecture est extrêmement inefficace pour les entiers de 32 bits ou 64 bits couramment 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 processeurs modernes. Elle nécessite plus d'instructions pour accomplir les mêmes opérations, rendant également l'optimisation du compilateur plus complexe.
Ces problèmes — y compris les goulets d'étranglement de performance des preuves ZK, la complexité des précompilations et les choix d'architecture obsolètes — constituent ensemble une raison convaincante et urgente : Ethereum doit dépasser l'EVM et adopter une architecture technologique mieux adaptée à l'avenir.
Plan RISC-V : redéfinir l'avenir d'Ethereum sur des bases plus solides
Les avantages de RISC-V ne résident pas seulement dans les insuffisances de l'EVM, mais aussi 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 les normes ouvertes sont-elles supérieures aux conceptions sur mesure ?
Contrairement aux architectures de jeux d'instructions (ISA) personnalisées qui nécessitent de construire un écosystème logiciel complet depuis zéro, RISC-V est une norme ouverte mature, dotée des trois principaux avantages suivants :
un écosystème mature
En adoptant RISC-V, Ethereum peut bénéficier de décennies de progrès collectif 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 en l'un des nombreux objectifs backend. L'un des backends pris en charge est RISC-V. Donc, si vous prenez en charge 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 familiarisés avec des langages tels que Rust, C++ et Go de commencer facilement.
La philosophie de conception minimaliste Le minimalisme de RISC-V est une caractéristique délibérée, et non une limitation. Son ensemble d'instructions de base ne contient qu'environ 47 instructions, ce qui permet de maintenir le cœur de la machine virtuelle extrêmement simple. Cette simplicité présente un avantage significatif 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 de fait dans le domaine des preuves à divulgation nulle de connaissance. Plus important encore, l'écosystème zkVM a 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 d'instruction (ISA) de premier plan pour le backend zkVM."
Parmi 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, en adoptant RISC-V, ne fait pas une tentative spéculative, mais s'aligne sur une norme reconnue par un projet déjà validé par des faits et construit pour son avenir en zéro connaissance.
Né pour la confiance, pas seulement pour exécuter
En plus d'un écosystème vaste, l'architecture interne de RISC-V est également particulièrement adaptée à la construction de systèmes sûrs et vérifiables. Tout d'abord, RISC-V dispose d'une spécification formalisée et lisible par machine - SAIL. Cela représente un énorme progrès par rapport à la spécification de l'EVM (qui existe principalement sous forme textuelle 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, ce qui est crucial pour la protection de 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 "vérifier directement contre la spécification officielle de RISC-V". Ensuite, RISC-V comprend 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, 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 contre l'influence d'autres codes. Il doit isoler 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 exécutés en mode utilisateur ne peuvent pas accéder directement à l'état de la blockchain. Au contraire, ils doivent émettre une demande via une instruction ECALL (appel d'environnement) spéciale au noyau de confiance fonctionnant en mode superviseur. Ce mécanisme établit une frontière de sécurité imposée par le matériel, qui est plus robuste et facile à vérifier que le modèle de bac à sable purement basé sur le logiciel de l'EVM.
La vision de Vitalik
Cette transformation est envisagée comme un processus progressif et par étapes, visant à garantir la stabilité du système et la compatibilité ascendante. 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" complète.
Étape 1 : Précompiler l'alternative
À ses débuts, la méthode la plus conservatrice sera adoptée, en introduisant des fonctionnalités limitées de 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, au profit de la mise en œuvre des fonctionnalités requises via des programmes RISC-V approuvés par une liste blanche. Cette approche permet à la nouvelle VM de subir des tests en conditions réelles dans un environnement à faible risque sur le réseau principal, tout en agissant comme un 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 une balise si leur bytecode est EVM ou RISC-V. La caractéristique clé est d'assurer une interopérabilité sans faille : "les deux types de contrats peuvent s'appeler mutuellement." Cette fonctionnalité sera réalisée via 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 simplifier le protocole. À ce stade, "nous considérons l'EVM comme une implémentation dans le nouveau VM." L'EVM normalisé deviendra un contrat intelligent vérifié formellement s'exécutant sur un RISC-V L1 natif. Cela garantit non seulement un support 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 le 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 redéfinira non seulement l'expérience des développeurs, mais changera également 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 d'une couche d'exécution RISC-V au niveau L1 aura un impact radicalement différent sur deux types principaux de Rollup.
Les Optimistic Rollups (comme Arbitrum, Optimism) font face à des défis architecturaux. Leur modèle de sécurité repose sur la réexécution de transactions contestées via l'EVM de L1 pour résoudre les preuves de fraude. Si l'EVM de L1 est remplacé, ce modèle s'effondrera totalement. Ces projets seront confrontés à un choix difficile : soit procéder à une refonte massive, concevoir un système de preuves de fraude pour le nouveau VM de L1, soit se détacher complètement du modèle de sécurité d'Ethereum.
En comparaison, le ZK Rollup bénéficiera d'un énorme avantage stratégique. La grande majorité des ZK Rollup ont déjà adopté RISC-V comme leur architecture de jeu d'instructions interne (ISA). Un L1 "parlant la même langue" permettra une intégration plus étroite et plus efficace. Justin Drake a proposé une vision d'avenir pour le "Rollup natif": L2 devenant 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 réaliser un règlement sans faille. Cette alignement entraînera les changements suivants :
Simplification de la pile technologique : l'équipe L2 n'aura plus besoin de construire des mécanismes de pont complexes entre l'environnement d'exécution 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 peuvent être utilisés directement par L2, réduisant ainsi 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 validation ZK basée sur RISC-V, créant 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 destructrice.
Pour les développeurs, ils auront accès à 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, tout en permettant à ces options de coexister". En attendant, il prédit que "Solidity et Vyper resteront populaires à long terme en raison de leur conception élégante de la logique des contrats intelligents". L'utilisation de langages de programmation courants et de leurs vastes ressources de bibliothèque via la chaîne d'outils LLVM rendra cette transition révolutionnaire. Vitalik l'a comparé à une expérience "de type NodeJS", où les développeurs peuvent écrire du code sur la chaîne et hors de la chaîne 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 accrue. On s'attend à ce que les coûts de preuve diminuent 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 ouvrira la voie à la vision de "Gigagas L1", visant à atteindre des performances d'environ 10 000 TPS, préparant le terrain pour des applications on-chain plus complexes et de plus grande valeur à l'avenir.
Succinct Labs et SP1 : construire la preuve de l'avenir aujourd'hui
Ethereum est en pleine préparation. "Étendre L1, étendre les blocs" est une tâche stratégique urgente au sein du groupe de protocoles EF. Une amélioration significative des performances est prévue dans les 6 à 12 prochains mois.
Des équipes comme Succinct Labs ont déjà démontré dans la pratique les avantages théoriques de RISC-V, et leur travail constitue un puissant exemple pour valider cette proposition.
SP1, développé par Succinct Labs, est un zkVM open-source à haute performance basé sur RISC-V, qui valide la faisabilité d'une nouvelle approche architecturale. SP1 adopte la philosophie « centrée sur la précompilation », résolvant parfaitement le problème des goulets 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, 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 approche combine les performances du matériel sur mesure avec la flexibilité du logiciel, offrant aux développeurs des solutions plus efficaces et évolutives.
L'impact réel de Succinct Labs est déjà visible. Leur produit OP Succinct utilise SP1 pour doter les Optimistic Rollups de la capacité de preuves à divulgation nulle (ZK-ify). Comme l'a expliqué Uma Roy, cofondatrice de Succinct :
"Avec les Rollups utilisant OP Stack, il n'est plus nécessaire d'attendre sept jours pour finaliser la confirmation et les retraits... Maintenant, il suffit d'une heure pour finaliser la confirmation. Cette augmentation de vitesse est vraiment géniale."
Cette percée résout les points de douleur clés de l'ensemble de l'écosystème OP Stack. De plus, l'infrastructure de Succinct - Succinct Prover Network - a été conçue comme un marché décentralisé de génération de preuves, montrant un modèle économique viable pour le calcul vérifiable de l'avenir. Leur travail n'est pas seulement une preuve de concept, mais un véritable plan pour l'avenir, comme décrit dans cet article.
Comment Ethereum réduit les risques
Un des grands avantages de RISC-V est qu'il rend réalisable le Saint Graal de la vérification formelle - prouver mathématiquement la correctitude d'un système. La spécification de l'EVM est écrite en langage naturel dans le Yellow Paper, ce qui la rend difficile à formaliser. En revanche, RISC-V possède une spécification SAIL officielle et lisible par machine, qui fournit un "référence en or" claire pour son comportement.
Cela pave la voie à une sécurité renforcée. Comme l'a souligné Alex Hicks de la Fondation Ethereum, des travaux sont actuellement en cours pour « extraire les circuits zkVM RISC-V de la spécification officielle RISC-V afin de les valider formellement dans Lean ». C'est un progrès marquant qui déplace la confiance de l'implémentation humaine sujette à erreurs vers des preuves mathématiques vérifiables, ouvrant de nouveaux sommets pour la sécurité de la blockchain.
Les principaux risques de transformation
Bien que l'architecture RISC-V L1 présente de nombreux avantages, elle pose également de nouveaux défis complexes.
Problème de mesure du gaz
Créer un modèle de Gas déterministe et équitable pour une architecture d'instruction universelle (ISA) est un problème non résolu. La méthode simple 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 à plusieurs reprises des échecs de cache, entraînant une consommation élevée de ressources pour un coût en Gas très faible. Ce 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 de la dépendance aux machines virtuelles de la chaîne à la dépendance aux compilateurs en dehors de la chaîne (comme LLVM), qui sont extrêmement complexes et connus pour contenir des vulnérabilités. Les attaquants pourraient exploiter les failles des compilateurs pour transformer un code source apparemment inoffensif en bytecode malveillant. De plus, il est également très difficile de garantir que les fichiers binaires compilés sur la chaîne correspondent exactement au code source public, ce qu'on appelle le problème de "construction reproductible". 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 un défi sérieux à la sécurité des développeurs et des utilisateurs.
stratégie d'atténuation
La route vers l'avant nécessite des stratégies de défense multicouches.
Promotion par étapes
Adopter un plan de transition progressif et par étapes est la stratégie clé pour faire face aux risques. En introduisant d'abord RISC-V comme solution précompilée, puis en le faisant fonctionner dans un environnement de double machine virtuelle, la communauté peut acquérir de l'expérience opérationnelle et établir la confiance dans un environnement à faible risque, évitant ainsi toute modification irréversible. Cette approche progressive offre 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 à haute intensité. Comme l'a montré Valentine de Diligence Security lors de la conférence téléphonique Ethproofs, leur outil de test 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 indique que même les systèmes les mieux conçus peuvent présenter des vulnérabilités qui ne peuvent être détectées que par des tests d'adversité rigoureux. La combinaison des tests de fuzzing et de la vérification formelle offre une meilleure garantie de sécurité des systèmes.
normalisation
Pour éviter la fragmentation de l'écosystème, la communauté doit adopter une configuration RISC-V unique et standardisée. Cela pourrait être une combinaison de RV64GC et d'un ABI compatible avec Linux, car cette combinaison bénéficie du plus large soutien dans les langages de programmation et les outils mainstream, 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 seulement une mise à niveau progressive, mais une refonte fondamentale de la couche d'exécution d'Ethereum. Cette vision ambitieuse vise à résoudre les goulets d'étranglement de l'évolutivité en profondeur, à simplifier la complexité du protocole et à aligner la plateforme avec un écosystème plus large dans le domaine de l'informatique générale. Bien que cette transformation fasse face à d'énormes défis techniques et sociaux, les bénéfices stratégiques à long terme justifient cet effort audacieux.
Cette transformation se concentre sur une série de compromis clés :
L'équilibre entre l'énorme amélioration de performance apportée par l'architecture ZK native et le besoin urgent de compatibilité descendante ;
Le compromis entre les avantages de sécurité offerts par les protocoles simplifiés et l'inertie des effets de réseau massifs de l'EVM.
Le choix entre la puissance des écosystèmes universels 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 réaliser l'engagement de "Lean Execution" et constituera une partie essentielle de la vision de "Lean Ethereum". Elle transformera la couche 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'univers vaste 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, grâce à l'application pratique de son SP1 zkVM, propose une feuille de route exploitable pour cet avenir. En adoptant RISC-V, Ethereum ne résout pas seulement son propre goulet 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 SNARK, le troisième grand principe cryptographique après les hachages et les signatures.
Prouver le logiciel du monde, ouvrir une nouvelle ère de la cryptographie.
En savoir plus :
Interprétation de Vitalik : cliquez pour regarder
Discussion sur ETHProofs n° 4 : Cliquez pour regarder
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.
La dette technique pèse lourd, Ethereum choisit de tout recommencer avec RISC-V.
Auteur : jaehaerys.eth
Compilation : Deep Tide TechFlow
Résumé
Ethereum se prépare à accueillir sa 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 à connaissance nulle (ZK), l'EVM est devenu un goulot d'étranglement en termes de performance :
Actuellement, le zkEVM dépend d'un interpréteur, ce qui entraîne un ralentissement 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 épuré (environ 47 instructions de base) + écosystème LLVM mature (prend en charge des langages comme Rust, C++, Go, etc.) ;
est devenu le standard de facto zkVM (90 % des projets l'adoptent) ;
Possède une norme SAIL formelle (par rapport au livre jaune flou) → réalise une validation stricte ;
Le chemin de la preuve matérielle (ASICs/FPGA) 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 double machines virtuelles : EVM et RISC-V coexistent et sont complètement interopérables ;
Réimplémenter 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) auront un énorme avantage → moins chers, plus rapides, plus simples ;
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 contrat intelligent" vers une couche de confiance minimaliste et vérifiable sur Internet, dont l'objectif ultime est de "rendre tout ZK-Snarké".
Le carrefour d'Ethereum
Vitalik Buterin a dit : « La destination inclut… faire en sorte que tout soit ZK-Snarké. »
La fin des preuves à connaissance nulle (ZK) est inévitable, et son argument central est très simple : Ethereum se reconstruit à partir de zéro, sur la base des preuves à connaissance nulle. Cela marque le point final technique du protocole - en atteignant sa forme ultime grâce à la reconstruction de L1, soutenue par des équipes de développement clés (comme Succinct) avec un zkVM haute performance.
Avec cette vision comme point d'achèvement, Ethereum se trouve à un tournant architectural le plus important depuis sa création. Cette discussion ne porte plus sur des mises à jour progressives, mais sur une reconstruction complète de son noyau de calcul - le remplacement de la machine virtuelle Ethereum (EVM). Cette initiative est la pierre angulaire d'une vision plus large de "Lean Ethereum".
La vision de Lean Ethereum vise à simplifier systématiquement l'ensemble du protocole en le divisant en trois modules principaux : Lean Consensus, Lean Data et Lean Execution. Dans les problèmes centraux de Lean Execution, le point le plus crucial est le suivant : en tant que moteur de la révolution des contrats intelligents, l'EVM 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 puissant outil capable d'améliorer toutes les couches du protocole. Cependant, pendant longtemps, cet objectif ressemblait davantage à un "plan inaccessibile", car sa réalisation nécessitait 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 de la migration de l'Ethereum L1 vers l'architecture d'ensemble d'instructions RISC-V. Cette initiative devrait non seulement libérer une évolutivité sans précédent, mais également simplifier la structure du protocole et aligner Ethereum sur 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 "ce qui" est en train de changer.
EVM (Machine Virtuelle Ethereum) est l'environnement d'exécution des contrats intelligents Ethereum, souvent qualifié d'« ordinateur mondial » chargé de traiter les transactions et de mettre à 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, conçue il y a près de dix ans, a désormais accumulé une quantité importante de dettes techniques.
En comparaison, 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 parfaitement adapté aux cas d'utilisation de notre machine universelle super minimaliste."
Conception modulaire : des fonctionnalités plus complexes peuvent être ajoutées par des extensions optionnelles. Cette caractéristique est essentielle car elle permet au cœur de rester simple tout en étendant les fonctionnalités selon les besoins, sans imposer une complexité inutile au protocole de base.
Écosystème ouvert : RISC-V dispose 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 l'a mentionné Justin Drake : « Les outils entourant le compilateur sont très riches, et la construction du compilateur est extrêmement difficile... Par conséquent, la valeur de posséder ces chaînes d'outils de compilateur 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 remplacer l'EVM ne relèvent pas d'un seul défaut, mais de la confluence de plusieurs limitations fondamentales, qui ne peuvent plus être ignorées dans le 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 découlant de la complexité croissante accumulée au sein des protocoles.
Problèmes de coût d'interpréteur
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 évolue progressivement vers un modèle de validation de l'état L1 par des preuves ZK, la performance des prouveurs devient le plus grand goulet d'étranglement.
Le problème réside dans la façon dont le zkEVM fonctionne actuellement. Ils ne font pas de preuves à connaissance nulle directement sur l'EVM, mais plutôt 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 mise en œuvre de zkVM consiste à compiler l'exécution de l'EVM en un contenu qui devient finalement du code RISC-V, pourquoi ne pas exposer directement le RISC-V sous-jacent aux développeurs de contrats intelligents ? Cela pourrait complètement éliminer les frais de la machine virtuelle extérieure."
Cette couche d'explications supplémentaires entraîne une énorme perte de performance. Les estimations indiquent que, par rapport à la preuve de programmes natifs, cette couche pourrait entraîner une diminution de performance de 50 à 800 fois. Après avoir optimisé d'autres goulets d'étranglement (par exemple 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, faisant de l'EVM le dernier et le plus difficile obstacle à l'extension de L1. En supprimant cette couche, Vitalik s'attend à ce que l'efficacité d'exécution puisse être améliorée par 100 fois.
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 aujourd'hui provoqué ce que Vitalik Buterin appelle une "mauvaise" situation :
"La précompilation est catastrophique pour nous... elle a considérablement gonflé la bibliothèque de code fiable d'Ethereum... et elle a presque causé de graves problèmes de consensus à plusieurs reprises."
Cette complexité est choquante. Vitalik illustre que le code d'emballage d'un seul contrat précompilé (comme modexp) est plus complexe que l'ensemble de l'interpréteur RISC-V, et la logique des précompilés est en réalité encore plus compliquée. Ajouter de nouveaux contrats précompilés nécessite un processus de hard fork lent et politiquement controversé, ce qui entrave gravement l'innovation des applications nécessitant de nouveaux primitives cryptographiques. À ce sujet, Vitalik a tiré des conclusions claires :
« 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 fondamentale de l'EVM reflète les priorités d'une époque passée, mais elle n'est plus adaptée aux exigences de calcul modernes. L'EVM a choisi une architecture de 256 bits pour traiter des valeurs cryptographiques, mais cette architecture est extrêmement inefficace pour les entiers de 32 bits ou 64 bits couramment 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 processeurs modernes. Elle nécessite plus d'instructions pour accomplir les mêmes opérations, rendant également l'optimisation du compilateur plus complexe.
Ces problèmes — y compris les goulets d'étranglement de performance des preuves ZK, la complexité des précompilations et les choix d'architecture obsolètes — constituent ensemble une raison convaincante et urgente : Ethereum doit dépasser l'EVM et adopter une architecture technologique mieux adaptée à l'avenir.
Plan RISC-V : redéfinir l'avenir d'Ethereum sur des bases plus solides
Les avantages de RISC-V ne résident pas seulement dans les insuffisances de l'EVM, mais aussi 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 les normes ouvertes sont-elles supérieures aux conceptions sur mesure ?
Contrairement aux architectures de jeux d'instructions (ISA) personnalisées qui nécessitent de construire un écosystème logiciel complet depuis zéro, RISC-V est une norme ouverte mature, dotée des trois principaux avantages suivants :
un écosystème mature
En adoptant RISC-V, Ethereum peut bénéficier de décennies de progrès collectif 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 en l'un des nombreux objectifs backend. L'un des backends pris en charge est RISC-V. Donc, si vous prenez en charge 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 familiarisés avec des langages tels que Rust, C++ et Go de commencer facilement.
La philosophie de conception minimaliste Le minimalisme de RISC-V est une caractéristique délibérée, et non une limitation. Son ensemble d'instructions de base ne contient qu'environ 47 instructions, ce qui permet de maintenir le cœur de la machine virtuelle extrêmement simple. Cette simplicité présente un avantage significatif 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 de fait dans le domaine des preuves à divulgation nulle de connaissance. Plus important encore, l'écosystème zkVM a 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 d'instruction (ISA) de premier plan pour le backend zkVM."
Parmi 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, en adoptant RISC-V, ne fait pas une tentative spéculative, mais s'aligne sur une norme reconnue par un projet déjà validé par des faits et construit pour son avenir en zéro connaissance.
Né pour la confiance, pas seulement pour exécuter
En plus d'un écosystème vaste, l'architecture interne de RISC-V est également particulièrement adaptée à la construction de systèmes sûrs et vérifiables. Tout d'abord, RISC-V dispose d'une spécification formalisée et lisible par machine - SAIL. Cela représente un énorme progrès par rapport à la spécification de l'EVM (qui existe principalement sous forme textuelle 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, ce qui est crucial pour la protection de 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 "vérifier directement contre la spécification officielle de RISC-V". Ensuite, RISC-V comprend 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, 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 contre l'influence d'autres codes. Il doit isoler 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 exécutés en mode utilisateur ne peuvent pas accéder directement à l'état de la blockchain. Au contraire, ils doivent émettre une demande via une instruction ECALL (appel d'environnement) spéciale au noyau de confiance fonctionnant en mode superviseur. Ce mécanisme établit une frontière de sécurité imposée par le matériel, qui est plus robuste et facile à vérifier que le modèle de bac à sable purement basé sur le logiciel de l'EVM.
La vision de Vitalik
Cette transformation est envisagée comme un processus progressif et par étapes, visant à garantir la stabilité du système et la compatibilité ascendante. 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" complète.
Étape 1 : Précompiler l'alternative
À ses débuts, la méthode la plus conservatrice sera adoptée, en introduisant des fonctionnalités limitées de 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, au profit de la mise en œuvre des fonctionnalités requises via des programmes RISC-V approuvés par une liste blanche. Cette approche permet à la nouvelle VM de subir des tests en conditions réelles dans un environnement à faible risque sur le réseau principal, tout en agissant comme un 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 une balise si leur bytecode est EVM ou RISC-V. La caractéristique clé est d'assurer une interopérabilité sans faille : "les deux types de contrats peuvent s'appeler mutuellement." Cette fonctionnalité sera réalisée via 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 simplifier le protocole. À ce stade, "nous considérons l'EVM comme une implémentation dans le nouveau VM." L'EVM normalisé deviendra un contrat intelligent vérifié formellement s'exécutant sur un RISC-V L1 natif. Cela garantit non seulement un support 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 le 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 redéfinira non seulement l'expérience des développeurs, mais changera également 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 d'une couche d'exécution RISC-V au niveau L1 aura un impact radicalement différent sur deux types principaux de Rollup.
Les Optimistic Rollups (comme Arbitrum, Optimism) font face à des défis architecturaux. Leur modèle de sécurité repose sur la réexécution de transactions contestées via l'EVM de L1 pour résoudre les preuves de fraude. Si l'EVM de L1 est remplacé, ce modèle s'effondrera totalement. Ces projets seront confrontés à un choix difficile : soit procéder à une refonte massive, concevoir un système de preuves de fraude pour le nouveau VM de L1, soit se détacher complètement du modèle de sécurité d'Ethereum.
En comparaison, le ZK Rollup bénéficiera d'un énorme avantage stratégique. La grande majorité des ZK Rollup ont déjà adopté RISC-V comme leur architecture de jeu d'instructions interne (ISA). Un L1 "parlant la même langue" permettra une intégration plus étroite et plus efficace. Justin Drake a proposé une vision d'avenir pour le "Rollup natif": L2 devenant 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 réaliser un règlement sans faille. Cette alignement entraînera les changements suivants :
Simplification de la pile technologique : l'équipe L2 n'aura plus besoin de construire des mécanismes de pont complexes entre l'environnement d'exécution 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 peuvent être utilisés directement par L2, réduisant ainsi 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 validation ZK basée sur RISC-V, créant 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 destructrice.
Pour les développeurs, ils auront accès à 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, tout en permettant à ces options de coexister". En attendant, il prédit que "Solidity et Vyper resteront populaires à long terme en raison de leur conception élégante de la logique des contrats intelligents". L'utilisation de langages de programmation courants et de leurs vastes ressources de bibliothèque via la chaîne d'outils LLVM rendra cette transition révolutionnaire. Vitalik l'a comparé à une expérience "de type NodeJS", où les développeurs peuvent écrire du code sur la chaîne et hors de la chaîne 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 accrue. On s'attend à ce que les coûts de preuve diminuent 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 ouvrira la voie à la vision de "Gigagas L1", visant à atteindre des performances d'environ 10 000 TPS, préparant le terrain pour des applications on-chain plus complexes et de plus grande valeur à l'avenir.
Succinct Labs et SP1 : construire la preuve de l'avenir aujourd'hui
Ethereum est en pleine préparation. "Étendre L1, étendre les blocs" est une tâche stratégique urgente au sein du groupe de protocoles EF. Une amélioration significative des performances est prévue dans les 6 à 12 prochains mois.
Des équipes comme Succinct Labs ont déjà démontré dans la pratique les avantages théoriques de RISC-V, et leur travail constitue un puissant exemple pour valider cette proposition.
SP1, développé par Succinct Labs, est un zkVM open-source à haute performance basé sur RISC-V, qui valide la faisabilité d'une nouvelle approche architecturale. SP1 adopte la philosophie « centrée sur la précompilation », résolvant parfaitement le problème des goulets 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, 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 approche combine les performances du matériel sur mesure avec la flexibilité du logiciel, offrant aux développeurs des solutions plus efficaces et évolutives.
L'impact réel de Succinct Labs est déjà visible. Leur produit OP Succinct utilise SP1 pour doter les Optimistic Rollups de la capacité de preuves à divulgation nulle (ZK-ify). Comme l'a expliqué Uma Roy, cofondatrice de Succinct :
"Avec les Rollups utilisant OP Stack, il n'est plus nécessaire d'attendre sept jours pour finaliser la confirmation et les retraits... Maintenant, il suffit d'une heure pour finaliser la confirmation. Cette augmentation de vitesse est vraiment géniale."
Cette percée résout les points de douleur clés de l'ensemble de l'écosystème OP Stack. De plus, l'infrastructure de Succinct - Succinct Prover Network - a été conçue comme un marché décentralisé de génération de preuves, montrant un modèle économique viable pour le calcul vérifiable de l'avenir. Leur travail n'est pas seulement une preuve de concept, mais un véritable plan pour l'avenir, comme décrit dans cet article.
Comment Ethereum réduit les risques
Un des grands avantages de RISC-V est qu'il rend réalisable le Saint Graal de la vérification formelle - prouver mathématiquement la correctitude d'un système. La spécification de l'EVM est écrite en langage naturel dans le Yellow Paper, ce qui la rend difficile à formaliser. En revanche, RISC-V possède une spécification SAIL officielle et lisible par machine, qui fournit un "référence en or" claire pour son comportement.
Cela pave la voie à une sécurité renforcée. Comme l'a souligné Alex Hicks de la Fondation Ethereum, des travaux sont actuellement en cours pour « extraire les circuits zkVM RISC-V de la spécification officielle RISC-V afin de les valider formellement dans Lean ». C'est un progrès marquant qui déplace la confiance de l'implémentation humaine sujette à erreurs vers des preuves mathématiques vérifiables, ouvrant de nouveaux sommets pour la sécurité de la blockchain.
Les principaux risques de transformation
Bien que l'architecture RISC-V L1 présente de nombreux avantages, elle pose également de nouveaux défis complexes.
Problème de mesure du gaz
Créer un modèle de Gas déterministe et équitable pour une architecture d'instruction universelle (ISA) est un problème non résolu. La méthode simple 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 à plusieurs reprises des échecs de cache, entraînant une consommation élevée de ressources pour un coût en Gas très faible. Ce 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 de la dépendance aux machines virtuelles de la chaîne à la dépendance aux compilateurs en dehors de la chaîne (comme LLVM), qui sont extrêmement complexes et connus pour contenir des vulnérabilités. Les attaquants pourraient exploiter les failles des compilateurs pour transformer un code source apparemment inoffensif en bytecode malveillant. De plus, il est également très difficile de garantir que les fichiers binaires compilés sur la chaîne correspondent exactement au code source public, ce qu'on appelle le problème de "construction reproductible". 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 un défi sérieux à la sécurité des développeurs et des utilisateurs.
stratégie d'atténuation
La route vers l'avant nécessite des stratégies de défense multicouches.
Promotion par étapes
Adopter un plan de transition progressif et par étapes est la stratégie clé pour faire face aux risques. En introduisant d'abord RISC-V comme solution précompilée, puis en le faisant fonctionner dans un environnement de double machine virtuelle, la communauté peut acquérir de l'expérience opérationnelle et établir la confiance dans un environnement à faible risque, évitant ainsi toute modification irréversible. Cette approche progressive offre 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 à haute intensité. Comme l'a montré Valentine de Diligence Security lors de la conférence téléphonique Ethproofs, leur outil de test 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 indique que même les systèmes les mieux conçus peuvent présenter des vulnérabilités qui ne peuvent être détectées que par des tests d'adversité rigoureux. La combinaison des tests de fuzzing et de la vérification formelle offre une meilleure garantie de sécurité des systèmes.
normalisation
Pour éviter la fragmentation de l'écosystème, la communauté doit adopter une configuration RISC-V unique et standardisée. Cela pourrait être une combinaison de RV64GC et d'un ABI compatible avec Linux, car cette combinaison bénéficie du plus large soutien dans les langages de programmation et les outils mainstream, 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 seulement une mise à niveau progressive, mais une refonte fondamentale de la couche d'exécution d'Ethereum. Cette vision ambitieuse vise à résoudre les goulets d'étranglement de l'évolutivité en profondeur, à simplifier la complexité du protocole et à aligner la plateforme avec un écosystème plus large dans le domaine de l'informatique générale. Bien que cette transformation fasse face à d'énormes défis techniques et sociaux, les bénéfices stratégiques à long terme justifient cet effort audacieux.
Cette transformation se concentre sur une série de compromis clés :
L'équilibre entre l'énorme amélioration de performance apportée par l'architecture ZK native et le besoin urgent de compatibilité descendante ;
Le compromis entre les avantages de sécurité offerts par les protocoles simplifiés et l'inertie des effets de réseau massifs de l'EVM.
Le choix entre la puissance des écosystèmes universels 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 réaliser l'engagement de "Lean Execution" et constituera une partie essentielle de la vision de "Lean Ethereum". Elle transformera la couche 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'univers vaste 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, grâce à l'application pratique de son SP1 zkVM, propose une feuille de route exploitable pour cet avenir. En adoptant RISC-V, Ethereum ne résout pas seulement son propre goulet 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 SNARK, le troisième grand principe cryptographique après les hachages et les signatures.
Prouver le logiciel du monde, ouvrir une nouvelle ère de la cryptographie.
En savoir plus :
Interprétation de Vitalik : cliquez pour regarder
Discussion sur ETHProofs n° 4 : Cliquez pour regarder