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 termes de performance :
L'interpréteur zkEVM actuel entraîne une réduction des performances de 50 à 800 fois ;
Le module de précompilation rend le protocole complexe et augmente les risques ;
La conception de la pile de 256 bits est extrêmement inefficace lors de la génération de preuves.
Solution RISC-V :
Design minimaliste (environ 47 instructions de base) + écosystème LLVM mature (supporte des langages comme Rust, C++, Go, etc.) ;
Est devenu le standard zkVM de facto (90 % des projets l'adoptent) ;
Dispose d'une spécification SAIL officielle (par rapport au flou du livre jaune) → réalisation d'une vérification stricte ;
Le chemin de preuve matériel (ASICs/FPGAs) est en cours de test (SP1, Nervos, Cartesi, etc.).
Le processus de migration se divise en trois phases :
Remplacer RISC-V par un module précompilé (test à faible risque);
L'ère des doubles machines virtuelles : EVM et RISC-V coexistent et sont complètement interopérables ;
Réimplémenter 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 à connaissance nulle (comme Polygon, zkSync, Scroll) auront un énorme avantage → moins cher, plus rapide, plus simple ;
Les développeurs peuvent utiliser directement des bibliothèques de langages comme 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 minimale et vérifiable sur Internet, dont l'objectif ultime est de "rendre tout ZK-Snarkisé".
Le carrefour de l'Ethereum
Vitalik Buterin a dit : "La destination inclut... rendre tout 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, sur la base de la preuve à divulgation nulle de connaissance. Cela marque le point final technique du protocole - atteignant sa forme ultime grâce à la reconstruction de L1, soutenue par des équipes de développement centrales (comme Succinct) avec un zkVM haute performance.
Avec cette vision comme objectif final, Ethereum est à un tournant architectural le plus important depuis sa création. Cette discussion ne porte plus sur des mises à jour progressives, mais sur une refonte complète de son cœur 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 décomposant en trois modules clés : Lean Consensus, Lean Data et Lean Execution. Parmi les problématiques centrales de Lean Execution, l'un des points les plus critiques 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 les différentes couches du protocole. Cependant, pendant longtemps, cet objectif ressemblait plus à un "plan 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 concernant la migration d'Ethereum L1 vers l'architecture de jeu d'instructions RISC-V (ISA). Cette initiative devrait non seulement libérer une évolutivité sans précédent, mais également simplifier la structure du protocole et aligner Ethereum avec l'avenir du calcul vérifiable.
Qu'est-ce qui a réellement changé ?
Avant de discuter du "pourquoi", il est d'abord nécessaire de clarifier "qu'est-ce qui" est en train de changer.
EVM (Machine Virtuelle Ethereum) est l'environnement d'exécution des contrats intelligents Ethereum, souvent décrit comme l'"ordinateur mondial" qui traite les transactions et met à jour l'état de la blockchain. Au fil des ans, son design 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 accumulé une grande quantité de dettes techniques aujourd'hui.
En revanche, RISC-V n'est pas un produit, mais une norme ouverte - un "alphabet" de conception de processeur gratuit et universel. Comme Jeremy Bruestle l'a souligné 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 "quasi parfait pour les 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 cruciale car elle permet de garder le noyau simple tout en étendant les fonctionnalités selon les besoins, sans imposer de complexité inutile au protocole de base.
Écosystème ouvert : RISC-V dispose d'un large éventail de support d'outils matures, 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 autour des compilateurs sont très riches, et la construction de compilateurs est extrêmement difficile... Ainsi, la valeur de disposer 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 le remplacement de l'EVM ne sont pas dues à un seul défaut, mais à la confluence de plusieurs limitations fondamentales qui ne peuvent plus être ignorées dans le contexte futur centré sur les preuves à connaissance nulle. Ces limitations incluent les goulets d'étranglement de performance dans les systèmes de preuves à connaissance nulle, ainsi que les risques liés à la complexité croissante accumulée au sein des protocoles.
Problème de coût de l'interpréteur
Le moteur le plus urgent 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 prouvent pas directement le EVM par des preuves à connaissance nulle, mais prouvent plutôt l'interpréteur du EVM, qui lui-même est compilé en RISC-V. Vitalik Buterin a clairement souligné ce problème central :
"...... Si l'implémentation 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 permettrait d'éliminer complètement les frais de la machine virtuelle externe."
Cette couche d'explication supplémentaire entraîne une perte de performance énorme. Les estimations indiquent que cette couche pourrait entraîner une diminution de performance de 50 à 800 fois par rapport à la preuve de programmes natifs. Après l'optimisation d'autres goulets d'étranglement (comme en passant à l'algorithme de hachage Poseidon), cette partie de "l'exécution de blocs" continuera de représenter 80 à 90 % de tout le temps de preuve, faisant de 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 améliorée de 100 fois.
piège de la dette technique
Pour compenser les lacunes de performance de l'EVM dans certaines opérations cryptographiques, Ethereum a introduit des contrats précompilés - des fonctionnalités dédiées directement codées dans le protocole. Bien que cette solution ait semblé pragmatique à l'époque, elle a aujourd'hui suscité ce que Vitalik Buterin appelle une situation "mauvaise" :
"La précompilation est catastrophique pour nous... elle a considérablement gonflé la base de code de confiance d'Ethereum... et elle a presque causé de graves problèmes de consensus à plusieurs reprises."
Cette complexité est choquante. Vitalik donne l'exemple du code d'emballage d'un seul contrat précompilé (comme modexp) qui est plus complexe que l'ensemble de l'interpréteur RISC-V, tandis que la logique précompilée est en réalité encore plus compliquée. L'ajout 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é une conclusion claire :
"Je pense que nous devrions arrêter d'ajouter de nouveaux contrats précompilés à partir d'aujourd'hui."
Dette technique de l'architecture d'Ethereum
La conception fondamentale de l'EVM reflète les priorités d'une époque révolue, mais elle n'est plus adaptée aux besoins de calcul modernes. L'EVM a opté pour 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 n'économise en réalité aucune ressource, tandis que la complexité augmente de deux à quatre fois. »
En plus de cela, l'architecture de la pile EVM est moins efficace que l'architecture des registres 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 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 technique plus adaptée à l'avenir.
Plan RISC-V : Repenser 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, idéale pour un environnement à haut risque comme celui d'Ethereum.
Pourquoi les normes ouvertes sont-elles supérieures aux conceptions sur mesure ?
Contrairement aux architectures de jeu d'instructions personnalisées (ISA) qui nécessitent de construire tout un écosystème logiciel à partir de zéro, RISC-V est une norme ouverte mature qui présente trois grands avantages clés :
Écosystème mature
En adoptant RISC-V, Ethereum peut tirer parti des décennies de progrès collectif dans le domaine des sciences informatiques. Comme l'explique Justin Drake, cela donne à Ethereum l'opportunité d'utiliser directement des outils de classe mondiale :
"Il existe un composant d'infrastructure appelé LLVM, qui est une chaîne d'outils de compilation permettant de compiler des langages de programmation de haut niveau en l'un des nombreux cibles 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 se lancer facilement.
La philosophie de design minimaliste Le minimalisme de RISC-V est une caractéristique délibérée, et non une limitation. Son jeu d'instructions de base contient seulement environ 47 instructions, ce qui maintient le noyau de la machine virtuelle extrêmement simple. Cette simplicité présente des avantages significatifs en termes de sécurité, car une bibliothèque de code de confiance plus petite est plus facile à auditer et à valider formellement.
Les normes de fait dans le domaine des preuves à connaissance nulle. 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 d'ensemble d'instructions (ISA) leader du backend zkVM. »
Parmi les dix zkVM capables de prouver des blocs Ethereum, neuf ont choisi RISC-V comme architecture cible. Cette convergence sur le marché envoie un signal puissant : 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 la pratique et construit pour son avenir en zéro connaissance.
est né pour la confiance, pas seulement pour exécuter
En plus de son vaste écosystème, 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 é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 cruciales, ce qui est essentiel 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". Deuxièmement, RISC-V comprend une architecture privilégiée, qui est une caractéristique souvent négligée mais cruciale pour la sécurité. Elle définit différents niveaux d'opération, principalement le mode utilisateur (pour des applications non fiables, comme les contrats intelligents) et le mode superviseur (pour le "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 exécuter différents programmes de manière isolée 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 ne peuvent pas accéder directement à l'état de la blockchain. Au contraire, ils doivent émettre une demande à un noyau de confiance s'exécutant en mode superviseur 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 bac à sable purement logiciel de 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é 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écompilation des alternatives
Dans la phase initiale, une approche très conservatrice sera adoptée, 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 de précompilation EVM, remplacées par des programmes RISC-V approuvés par une liste blanche pour réaliser les fonctionnalités requises. Cette approche permet à la nouvelle VM de tester ses capacités en conditions réelles sur le réseau principal dans un environnement à faible risque, tout en servant d'intermédiaire entre les deux environnements d'exécution via le client Ethereum.
Deuxième étape : coexistence de deux machines virtuelles
La prochaine étape sera d'"ouvrir directement le nouveau VM aux utilisateurs". Les contrats intelligents peuvent indiquer par un marqueur 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 dans le même écosystème.
Étape 3 : 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 dans la nouvelle VM." L'EVM normalisé deviendra un contrat intelligent vérifié formellement fonctionnant sur le RISC-V L1 natif. Cela garantit non seulement un support permanent pour les applications anciennes, 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.
effet d'onde 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 redéfinira pas seulement l'expérience des développeurs, mais changera fondamentalement le paysage concurrentiel des solutions de Layer-2 et débloquera de nouveaux modèles économiques de validation.
Le repositionnement des Rollups : Duel entre Optimistic et ZK
L'adoption d'une 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 d'architecture. Leur modèle de sécurité repose sur la réexécution de transactions contestées via l'EVM L1 pour résoudre les preuves de fraude. Si l'EVM de L1 est remplacé, ce modèle sera complètement détruit. Ces projets seront confrontés à un choix difficile : soit effectuer une refonte massive, concevoir un système de preuve de fraude pour le nouveau VM L1, soit se détacher complètement du modèle de sécurité d'Ethereum.
En comparaison, le ZK Rollup va bénéficier d'un énorme avantage stratégique. La grande majorité des ZK Rollup ont déjà adopté RISC-V comme leur architecture 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" : le L2 devenant en réalité une instance spécialisée de l'environnement d'exécution du L1 lui-même, utilisant la VM intégrée du L1 pour un règlement sans faille. Cette alignement apportera 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.
Réutilisation des outils et du code : les compilateurs, débogueurs et outils de vérification formelle développés pour l'environnement L1 RISC-V peuvent être directement utilisés 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, créant ainsi un modèle économique plus raisonnable.
Une nouvelle ère pour les développeurs et les utilisateurs
Pour les développeurs d'Ethereum, cette transformation sera progressive et non destructive.
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 en matière de logique de contrat intelligent ». Cette transformation, en utilisant des langages de programmation mainstream et leurs vastes ressources de bibliothèques via la chaîne d'outils LLVM, sera révolutionnaire. Vitalik le compare à une expérience de type « NodeJS », où les développeurs peuvent écrire du code à la fois sur la chaîne et hors chaîne dans le même langage, réalisant ainsi l'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 s'attend à ce que le coût de preuve diminue 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 faibles. Cette viabilité économique débloquera la vision de "Gigagas L1", avec pour objectif d'atteindre une performance d'environ 10 000 TPS, ouvrant la voie à des applications on-chain plus complexes et de plus grande valeur à l'avenir.
Succinct Labs et SP1 : Construire des preuves pour l'avenir dans le présent
Ethereum est en train de se préparer. "Extension L1, extension des blocs" est une tâche stratégique urgente au sein du groupe de protocoles EF. Une amélioration significative des performances est attendue dans les 6 à 12 mois à venir.
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 cas de validation de cette proposition.
Le 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" (precompile-centric), 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, le SP1 décharge des opérations intensives comme le hachage Keccak dans des circuits ZK spécialement conçus et manuellement optimisés, et les appelle via des instructions ECALL standard. Cette approche combine la performance du matériel sur mesure avec la flexibilité logicielle, 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 conférer des capacités de preuve à connaissance nulle (ZK-ify) aux Optimistic Rollups. 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 finaliser la confirmation et le retrait... Maintenant, il suffit d'une heure pour finaliser la confirmation. Cette augmentation de vitesse est vraiment géniale."
Cette percée résout un point de douleur clé dans l'ensemble de l'écosystème OP Stack. De plus, l'infrastructure de Succinct — le Succinct Prover Network — a été conçue comme un marché décentralisé de génération de preuves, 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 concret, 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 correctivité 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 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é 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 et les normes RISC-V officielles dans Lean pour une vérification formelle". Il s'agit d'un progrès marquant qui transfère la confiance des implémentations humaines sujettes à des erreurs vers des preuves mathématiques vérifiables, ouvrant de nouvelles hauteurs 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 de gaz
Créer un modèle de Gas déterministe et équitable pour une architecture d'ensemble d'instructions (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 continuellement des échecs de cache, entraînant une consommation de ressources élevée pour des frais de Gas très faibles. 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èmes 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 à la machine virtuelle sur la chaîne à la dépendance au compilateur hors chaîne (comme LLVM), et ces compilateurs sont extrêmement complexes et connus pour contenir des vulnérabilités. Les attaquants peuvent exploiter les vulnérabilités du compilateur 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 un défi majeur à la sécurité des développeurs et des utilisateurs.
Stratégie d'atténuation
La route à suivre nécessite des stratégies de défense multicouches.
Promotion par étapes
L'adoption d'un plan de transition progressif et par étapes est une stratégie clé pour gérer les risques. En introduisant d'abord RISC-V comme alternative précompilée, puis en l'exécutant dans un environnement de double machine virtuelle, la communauté peut acquérir de l'expérience opérationnelle et établir une confiance dans un environnement à faible risque, évitant ainsi tout changement irréversible. Cette approche progressive fournit une base stable pour la transformation technologique.
Audit complet : tests flous et validation 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 test de fuzzing Argus a déjà découvert 11 vulnérabilités clés de solidité et d'intégrité dans les principaux zkVM. Cela indique que même les systèmes les mieux conçus peuvent comporter des vulnérabilités qui ne peuvent être détectées que par des tests adversariaux rigoureux. La combinaison du fuzzing et de la vérification formelle offre une protection plus forte pour la 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 soutien le plus large dans les langages de programmation et les outils grand public, permettant de maximiser les avantages du nouvel écosystème. La normalisation 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 plutôt une reconstruction fondamentale de la couche d'exécution d'Ethereum. Cette vision ambitieuse vise à résoudre les goulets d'étranglement profonds en matière d'évolutivité, à 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, 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 ZK natif et la nécessité urgente de compatibilité descendante ;
L'équilibre 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 du système écologique universel et les risques lié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 un élément important de la vision "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, 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, avec l'application pratique de son SP1 zkVM, offre une feuille de route actionable 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 le troisième grand principe cryptographique après les hachages et les signatures, le SNARK.
Prouver le logiciel du monde, ouvrir une nouvelle ère de la 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.
La dette technique pèse, Ethereum choisit de "repartir de zéro" avec RISC-V.
Auteur : jaehaerys.eth
Compilation : Deep Tide 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 termes de performance :
Solution RISC-V :
Le processus de migration se divise en trois phases :
Impact sur l'écosystème :
Finalement, Ethereum évoluera d'une "machine virtuelle de contrat intelligent" vers une couche de confiance minimale et vérifiable sur Internet, dont l'objectif ultime est de "rendre tout ZK-Snarkisé".
Le carrefour de l'Ethereum
Vitalik Buterin a dit : "La destination inclut... rendre tout 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, sur la base de la preuve à divulgation nulle de connaissance. Cela marque le point final technique du protocole - atteignant sa forme ultime grâce à la reconstruction de L1, soutenue par des équipes de développement centrales (comme Succinct) avec un zkVM haute performance.
Avec cette vision comme objectif final, Ethereum est à un tournant architectural le plus important depuis sa création. Cette discussion ne porte plus sur des mises à jour progressives, mais sur une refonte complète de son cœur 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 décomposant en trois modules clés : Lean Consensus, Lean Data et Lean Execution. Parmi les problématiques centrales de Lean Execution, l'un des points les plus critiques 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 les différentes couches du protocole. Cependant, pendant longtemps, cet objectif ressemblait plus à un "plan 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 concernant la migration d'Ethereum L1 vers l'architecture de jeu d'instructions RISC-V (ISA). Cette initiative devrait non seulement libérer une évolutivité sans précédent, mais également simplifier la structure du protocole et aligner Ethereum avec l'avenir du calcul vérifiable.
Qu'est-ce qui a réellement changé ?
Avant de discuter du "pourquoi", il est d'abord nécessaire de clarifier "qu'est-ce qui" est en train de changer.
EVM (Machine Virtuelle Ethereum) est l'environnement d'exécution des contrats intelligents Ethereum, souvent décrit comme l'"ordinateur mondial" qui traite les transactions et met à jour l'état de la blockchain. Au fil des ans, son design 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 accumulé une grande quantité de dettes techniques aujourd'hui.
En revanche, RISC-V n'est pas un produit, mais une norme ouverte - un "alphabet" de conception de processeur gratuit et universel. Comme Jeremy Bruestle l'a souligné lors de la conférence Ethproofs, ses principes clés en font un excellent choix pour ce rôle :
problème de coût de l'interpréteur
Les raisons de promouvoir le remplacement de l'EVM ne sont pas dues à un seul défaut, mais à la confluence de plusieurs limitations fondamentales qui ne peuvent plus être ignorées dans le contexte futur centré sur les preuves à connaissance nulle. Ces limitations incluent les goulets d'étranglement de performance dans les systèmes de preuves à connaissance nulle, ainsi que les risques liés à la complexité croissante accumulée au sein des protocoles.
Problème de coût de l'interpréteur
Le moteur le plus urgent 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 prouvent pas directement le EVM par des preuves à connaissance nulle, mais prouvent plutôt l'interpréteur du EVM, qui lui-même est compilé en RISC-V. Vitalik Buterin a clairement souligné ce problème central :
"...... Si l'implémentation 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 permettrait d'éliminer complètement les frais de la machine virtuelle externe."
Cette couche d'explication supplémentaire entraîne une perte de performance énorme. Les estimations indiquent que cette couche pourrait entraîner une diminution de performance de 50 à 800 fois par rapport à la preuve de programmes natifs. Après l'optimisation d'autres goulets d'étranglement (comme en passant à l'algorithme de hachage Poseidon), cette partie de "l'exécution de blocs" continuera de représenter 80 à 90 % de tout le temps de preuve, faisant de 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 améliorée de 100 fois.
piège de la dette technique
Pour compenser les lacunes de performance de l'EVM dans certaines opérations cryptographiques, Ethereum a introduit des contrats précompilés - des fonctionnalités dédiées directement codées dans le protocole. Bien que cette solution ait semblé pragmatique à l'époque, elle a aujourd'hui suscité ce que Vitalik Buterin appelle une situation "mauvaise" :
"La précompilation est catastrophique pour nous... elle a considérablement gonflé la base de code de confiance d'Ethereum... et elle a presque causé de graves problèmes de consensus à plusieurs reprises."
Cette complexité est choquante. Vitalik donne l'exemple du code d'emballage d'un seul contrat précompilé (comme modexp) qui est plus complexe que l'ensemble de l'interpréteur RISC-V, tandis que la logique précompilée est en réalité encore plus compliquée. L'ajout 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é une conclusion claire :
"Je pense que nous devrions arrêter d'ajouter de nouveaux contrats précompilés à partir d'aujourd'hui."
Dette technique de l'architecture d'Ethereum
La conception fondamentale de l'EVM reflète les priorités d'une époque révolue, mais elle n'est plus adaptée aux besoins de calcul modernes. L'EVM a opté pour 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 n'économise en réalité aucune ressource, tandis que la complexité augmente de deux à quatre fois. »
En plus de cela, l'architecture de la pile EVM est moins efficace que l'architecture des registres 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 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 technique plus adaptée à l'avenir.
Plan RISC-V : Repenser 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, idéale pour un environnement à haut risque comme celui d'Ethereum.
Pourquoi les normes ouvertes sont-elles supérieures aux conceptions sur mesure ?
Contrairement aux architectures de jeu d'instructions personnalisées (ISA) qui nécessitent de construire tout un écosystème logiciel à partir de zéro, RISC-V est une norme ouverte mature qui présente trois grands avantages clés :
Écosystème mature
En adoptant RISC-V, Ethereum peut tirer parti des décennies de progrès collectif dans le domaine des sciences informatiques. Comme l'explique Justin Drake, cela donne à Ethereum l'opportunité d'utiliser directement des outils de classe mondiale :
"Il existe un composant d'infrastructure appelé LLVM, qui est une chaîne d'outils de compilation permettant de compiler des langages de programmation de haut niveau en l'un des nombreux cibles 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 se lancer facilement.
La philosophie de design minimaliste Le minimalisme de RISC-V est une caractéristique délibérée, et non une limitation. Son jeu d'instructions de base contient seulement environ 47 instructions, ce qui maintient le noyau de la machine virtuelle extrêmement simple. Cette simplicité présente des avantages significatifs en termes de sécurité, car une bibliothèque de code de confiance plus petite est plus facile à auditer et à valider formellement.
Les normes de fait dans le domaine des preuves à connaissance nulle. 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 d'ensemble d'instructions (ISA) leader du backend zkVM. »
Parmi les dix zkVM capables de prouver des blocs Ethereum, neuf ont choisi RISC-V comme architecture cible. Cette convergence sur le marché envoie un signal puissant : 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 la pratique et construit pour son avenir en zéro connaissance.
est né pour la confiance, pas seulement pour exécuter
En plus de son vaste écosystème, 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 é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 cruciales, ce qui est essentiel 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". Deuxièmement, RISC-V comprend une architecture privilégiée, qui est une caractéristique souvent négligée mais cruciale pour la sécurité. Elle définit différents niveaux d'opération, principalement le mode utilisateur (pour des applications non fiables, comme les contrats intelligents) et le mode superviseur (pour le "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 exécuter différents programmes de manière isolée 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 ne peuvent pas accéder directement à l'état de la blockchain. Au contraire, ils doivent émettre une demande à un noyau de confiance s'exécutant en mode superviseur 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 bac à sable purement logiciel de 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é 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écompilation des alternatives
Dans la phase initiale, une approche très conservatrice sera adoptée, 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 de précompilation EVM, remplacées par des programmes RISC-V approuvés par une liste blanche pour réaliser les fonctionnalités requises. Cette approche permet à la nouvelle VM de tester ses capacités en conditions réelles sur le réseau principal dans un environnement à faible risque, tout en servant d'intermédiaire entre les deux environnements d'exécution via le client Ethereum.
Deuxième étape : coexistence de deux machines virtuelles
La prochaine étape sera d'"ouvrir directement le nouveau VM aux utilisateurs". Les contrats intelligents peuvent indiquer par un marqueur 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 dans le même écosystème.
Étape 3 : 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 dans la nouvelle VM." L'EVM normalisé deviendra un contrat intelligent vérifié formellement fonctionnant sur le RISC-V L1 natif. Cela garantit non seulement un support permanent pour les applications anciennes, 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.
effet d'onde 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 redéfinira pas seulement l'expérience des développeurs, mais changera fondamentalement le paysage concurrentiel des solutions de Layer-2 et débloquera de nouveaux modèles économiques de validation.
Le repositionnement des Rollups : Duel entre Optimistic et ZK
L'adoption d'une 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 d'architecture. Leur modèle de sécurité repose sur la réexécution de transactions contestées via l'EVM L1 pour résoudre les preuves de fraude. Si l'EVM de L1 est remplacé, ce modèle sera complètement détruit. Ces projets seront confrontés à un choix difficile : soit effectuer une refonte massive, concevoir un système de preuve de fraude pour le nouveau VM L1, soit se détacher complètement du modèle de sécurité d'Ethereum.
En comparaison, le ZK Rollup va bénéficier d'un énorme avantage stratégique. La grande majorité des ZK Rollup ont déjà adopté RISC-V comme leur architecture 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" : le L2 devenant en réalité une instance spécialisée de l'environnement d'exécution du L1 lui-même, utilisant la VM intégrée du L1 pour un règlement sans faille. Cette alignement apportera 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.
Réutilisation des outils et du code : les compilateurs, débogueurs et outils de vérification formelle développés pour l'environnement L1 RISC-V peuvent être directement utilisés 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, créant ainsi un modèle économique plus raisonnable.
Une nouvelle ère pour les développeurs et les utilisateurs
Pour les développeurs d'Ethereum, cette transformation sera progressive et non destructive.
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 en matière de logique de contrat intelligent ». Cette transformation, en utilisant des langages de programmation mainstream et leurs vastes ressources de bibliothèques via la chaîne d'outils LLVM, sera révolutionnaire. Vitalik le compare à une expérience de type « NodeJS », où les développeurs peuvent écrire du code à la fois sur la chaîne et hors chaîne dans le même langage, réalisant ainsi l'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 s'attend à ce que le coût de preuve diminue 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 faibles. Cette viabilité économique débloquera la vision de "Gigagas L1", avec pour objectif d'atteindre une performance d'environ 10 000 TPS, ouvrant la voie à des applications on-chain plus complexes et de plus grande valeur à l'avenir.
Succinct Labs et SP1 : Construire des preuves pour l'avenir dans le présent
Ethereum est en train de se préparer. "Extension L1, extension des blocs" est une tâche stratégique urgente au sein du groupe de protocoles EF. Une amélioration significative des performances est attendue dans les 6 à 12 mois à venir.
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 cas de validation de cette proposition.
Le 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" (precompile-centric), 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, le SP1 décharge des opérations intensives comme le hachage Keccak dans des circuits ZK spécialement conçus et manuellement optimisés, et les appelle via des instructions ECALL standard. Cette approche combine la performance du matériel sur mesure avec la flexibilité logicielle, 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 conférer des capacités de preuve à connaissance nulle (ZK-ify) aux Optimistic Rollups. 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 finaliser la confirmation et le retrait... Maintenant, il suffit d'une heure pour finaliser la confirmation. Cette augmentation de vitesse est vraiment géniale."
Cette percée résout un point de douleur clé dans l'ensemble de l'écosystème OP Stack. De plus, l'infrastructure de Succinct — le Succinct Prover Network — a été conçue comme un marché décentralisé de génération de preuves, 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 concret, 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 correctivité 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 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é 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 et les normes RISC-V officielles dans Lean pour une vérification formelle". Il s'agit d'un progrès marquant qui transfère la confiance des implémentations humaines sujettes à des erreurs vers des preuves mathématiques vérifiables, ouvrant de nouvelles hauteurs 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 de gaz
Créer un modèle de Gas déterministe et équitable pour une architecture d'ensemble d'instructions (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 continuellement des échecs de cache, entraînant une consommation de ressources élevée pour des frais de Gas très faibles. 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èmes 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 à la machine virtuelle sur la chaîne à la dépendance au compilateur hors chaîne (comme LLVM), et ces compilateurs sont extrêmement complexes et connus pour contenir des vulnérabilités. Les attaquants peuvent exploiter les vulnérabilités du compilateur 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 un défi majeur à la sécurité des développeurs et des utilisateurs.
Stratégie d'atténuation
La route à suivre nécessite des stratégies de défense multicouches.
Promotion par étapes
L'adoption d'un plan de transition progressif et par étapes est une stratégie clé pour gérer les risques. En introduisant d'abord RISC-V comme alternative précompilée, puis en l'exécutant dans un environnement de double machine virtuelle, la communauté peut acquérir de l'expérience opérationnelle et établir une confiance dans un environnement à faible risque, évitant ainsi tout changement irréversible. Cette approche progressive fournit une base stable pour la transformation technologique.
Audit complet : tests flous et validation 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 test de fuzzing Argus a déjà découvert 11 vulnérabilités clés de solidité et d'intégrité dans les principaux zkVM. Cela indique que même les systèmes les mieux conçus peuvent comporter des vulnérabilités qui ne peuvent être détectées que par des tests adversariaux rigoureux. La combinaison du fuzzing et de la vérification formelle offre une protection plus forte pour la 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 soutien le plus large dans les langages de programmation et les outils grand public, permettant de maximiser les avantages du nouvel écosystème. La normalisation 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 plutôt une reconstruction fondamentale de la couche d'exécution d'Ethereum. Cette vision ambitieuse vise à résoudre les goulets d'étranglement profonds en matière d'évolutivité, à 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, 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 :
En fin de compte, cette transformation architecturale sera la clé pour réaliser l'engagement de "Lean Execution" et constituera un élément important de la vision "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, 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, avec l'application pratique de son SP1 zkVM, offre une feuille de route actionable 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 le troisième grand principe cryptographique après les hachages et les signatures, le SNARK.
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 : cliquez pour regarder