Ethereum subit la transformation architecturale la plus importante depuis sa création : remplacer la machine virtuelle Ethereum (EVM) par RISC-V. La raison fondamentale de ce changement est qu'à l'ère des preuves à divulgation nulle de connaissance (ZK), l'EVM est devenu le plus grand goulot d'étranglement :
L'zkEVM actuel dépend de l'exécution de l'interpréteur, ce qui entraîne une réduction de la vitesse de 50 à 800 fois ;
Les contrats précompilés (Precompiles) rendent le protocole trop complexe et augmentent les risques ;
La conception de la pile de 256 bits est extrêmement inefficace dans la preuve.
Devenu le standard zkVM de facto (90% des projets l'adoptent) ;
La spécification SAIL formalisée (par rapport au livre jaune ambigu) peut supporter une validation stricte;
Le chemin de preuve matériel (ASIC/FPGA) est en cours de test (SP1, Nervos, Cartesi).
La migration se déroule en trois phases :
RISC-V en tant qu'alternative aux contrats précompilés (tests à faible risque) ;
L'ère des doubles machines virtuelles : EVM + RISC-V ont une interopérabilité complète ;
EVM réimplémenté à l'intérieur de RISC-V (similaire à la stratégie Rosetta).
Impact de l'écosystème :
Les Optimistic Rollups ne sont pas affectés ; le réseau principal RISC-V ne supprimera pas les preuves de fraude, les programmes de preuve existants peuvent être compilés pour s'adapter à RISC-V (actuellement basé sur MIPS) ; chemin de migration : étendre l'infrastructure de tolérance aux pannes actuelle vers le RISC-V cible, plutôt que de le reconstruire complètement ;
ZK Rollup bénéficiera grandement (Polygon, zkSync, Scroll → moins cher, plus rapide, plus simple) ;
Les développeurs peuvent directement utiliser les bibliothèques Rust/Go/Python sur L1 ;
Les utilisateurs peuvent obtenir un coût de preuve environ 100 fois moins cher, les conduisant vers le niveau Gigagas (environ 10k TPS) de L1.
Finalement, Ethereum évoluera d'une « machine virtuelle de contrats intelligents » en une couche de confiance internet minimale et vérifiable, dont l'objectif ultime est : « tout devient ZK-Snark ».
Ethereum est à un carrefour.
Avec l'objectif ultime de "tout rendre ZK-Snark", Ethereum se trouve maintenant à un seuil d'évolution architecturale le plus important depuis sa création. Cette discussion ne se limite plus à des mises à niveau progressives, mais constitue une reconstruction fondamentale de son noyau de calcul - c'est-à-dire le remplacement de la machine virtuelle Ethereum (EVM). Cette initiative est la pierre angulaire d'une vision plus large de "Lean Ethereum", qui vise à simplifier systématiquement l'ensemble du protocole en le décomposant en trois composants clés : consensus allégé (Lean Consensus), données allégées (Lean Data) et exécution allégée (Lean Execution). La question centrale de l'exécution simplifiée est la suivante : l'EVM, en tant que moteur de la révolution des contrats intelligents, est-il désormais 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", un puissant outil capable d'améliorer les différents niveaux du protocole. Mais pendant longtemps, cet objectif ressemblait plus à un "château en Espagne", car sa réalisation nécessitait une preuve en temps réel de ce concept. Et aujourd'hui, alors que la preuve en temps réel devient progressivement une réalité, l'inefficacité théorique de l'EVM s'est transformée en un problème pratique urgent à résoudre.
Cette analyse examinera les arguments techniques et stratégiques liés à la migration de l'Ethereum L1 vers l'architecture d'ensemble d'instructions RISC-V (ISA), une initiative qui devrait libérer une évolutivité sans précédent, simplifier la structure du protocole et aligner Ethereum avec l'avenir du calcul vérifiable.
Qu'est-ce qui a vraiment changé ?
Avant d'explorer en profondeur le « pourquoi », il est d'abord nécessaire de comprendre « quoi » est en train de changer.
L'EVM est l'environnement d'exécution des contrats intelligents d'Ethereum, agissant comme un "ordinateur mondial" qui traite les transactions et met à jour l'état de la blockchain. Au fil des ans, sa conception a été révolutionnaire, créant une plateforme sans autorisation et donnant naissance à tout un écosystème DeFi et NFT. Cependant, cette architecture sur mesure, qui date d'il y a près de dix ans, a maintenant accumulé une lourde dette technique.
En comparaison, RISC-V n'est pas un produit, mais un standard ouvert - un "alphabet" de conception de processeurs gratuit et universel. Comme l'a souligné Jeremy Bruestle lors de la conférence téléphonique Ethproofs, ses principes clés en font le choix évident pour ce rôle :
Minimalisme : l'ensemble d'instructions de base est extrêmement simple, ne contenant qu'environ 40 à 47 instructions. Jeremy le décrit comme « presque le cas d'utilisation parfait de notre machine universelle ultra-compacte dont nous avons besoin ».
Modularité : ajout de fonctionnalités plus complexes grâce à des extensions optionnelles. C'est essentiel car cela permet un noyau simple, pouvant être étendu à la demande, sans imposer de complexité inutile au protocole de base ;
Écosystème ouvert : il dispose d'une vaste et mature chaîne d'outils, y compris le compilateur LLVM, permettant aux développeurs d'utiliser des langages courants tels que Rust, C++ et Go. Comme l'a dit Justin Drake : « Il existe de nombreux outils liés aux compilateurs, et la construction d'un compilateur est extrêmement difficile... Par conséquent, avoir ces outils de compilateur a une grande valeur. » RISC-V permet à Ethereum d'hériter gratuitement de ces outils déjà disponibles.
Problème de coût de l'interpréteur
La nécessité de remplacer l'EVM ne découle pas d'un seul défaut, mais d'une série de limitations fondamentales qui, dans le contexte d'un avenir natif des preuves à divulgation nulle de connaissance (ZK), sont devenues impossibles à ignorer. Ces problèmes englobent de graves goulets d'étranglement en termes de performance dans les systèmes de preuve ZK, ainsi que les risques liés à la complexité croissante accumulée à l'intérieur 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 à divulgation nulle. À mesure qu'Ethereum se dirige progressivement vers un modèle de validation de l'état de L1 par des preuves ZK, la performance des prouveurs deviendra le goulet d'étranglement final.
Le problème réside dans le fonctionnement actuel de zkEVM. Ils ne font pas de preuves à connaissance zéro directement sur l'EVM, mais sur un interpréteur de l'EVM, qui est lui-même compilé en RISC-V. Vitalik Buterin a souligné ce problème central de manière frappante :
« 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 ouvrir directement le RISC-V sous-jacent aux développeurs de contrats intelligents ? Cela permettrait d'éliminer complètement les coûts de la machine virtuelle externe. »
Cette couche d'explication supplémentaire entraîne une perte de performance énorme. Selon les estimations, par rapport à la preuve de programmes natifs, cette couche pourrait entraîner une baisse de performance de 50 à 800 fois. Après avoir optimisé d'autres goulets d'étranglement (comme en passant à l'algorithme de hachage Poseidon), cette partie de « l'exécution de bloc » continuera à consommer 80 à 90 % du temps de preuve, faisant de l'EVM le dernier et le plus obstiné des obstacles à l'expansion de L1. Si cette couche était supprimée, Vitalik prévoit que l'efficacité d'exécution pourrait être améliorée de 100 fois.
Les pièges d'endettement des contrats précompilés
Pour résoudre le problème de performance insuffisante de l'EVM dans certaines opérations cryptographiques, Ethereum a introduit les contrats précompilés - intégrant directement des fonctions spécialisées dans le protocole. Bien que cela ait été une solution pragmatique à l'époque, cela a conduit aujourd'hui à ce que Vitalik Buterin appelle une situation "catastrophique" :
« La précompilation est catastrophique pour nous… elle a considérablement gonflé la base de code fiable d'Ethereum… et au bord d'un échec de consensus, elle nous a fait frôler le désastre à plusieurs reprises. »
Sa complexité est stupéfiante. Vitalik a souligné, en comparant le code d'emballage d'un seul contrat précompilé (modexp) avec un interpréteur complet RISC-V, que la logique précompilée est en réalité beaucoup plus complexe. L'ajout de précompilés doit passer par un processus de hard fork lent et rempli de jeux politiques, ce qui entrave gravement l'innovation des applications reposant sur de nouveaux primitifs cryptographiques.
Ainsi, Vitalik en arrive à une conclusion ferme : « Je pense en fait que nous devrions immédiatement cesser d'ajouter de nouveaux contrats précompilés. »
La dette technique de l'architecture d'Ethereum
La conception centrale de l'EVM reflète des besoins d'époque obsolètes, mais elle n'est plus adaptée à l'informatique moderne. L'EVM a choisi une architecture de 256 bits pour traiter des valeurs cryptographiques, ce qui est extrêmement inefficace par rapport aux entiers de 32 bits ou 64 bits généralement utilisés dans les contrats intelligents. Le coût de cette inefficacité est particulièrement élevé dans les systèmes de preuve à connaissance nulle.
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 2 à 4 fois. »
En outre, l'architecture de pile de l'EVM est moins efficace que l'architecture des registres du RISC-V et des processeurs modernes. Elle nécessite plus d'instructions pour exécuter les mêmes opérations, rendant également l'optimisation du compilateur plus complexe.
Ces facteurs combinés incluent les goulets d'étranglement de performance des preuves ZK, la complexité des précompilations et des choix d'architecture obsolètes, constituant ensemble une raison convaincante et urgente pour qu'Ethereum dépasse l'EVM.
RISC-V Blueprint : établir une base plus solide
Les avantages de RISC-V ne proviennent pas seulement des lacunes de l'EVM, mais résident également dans sa philosophie de conception et ses avantages intrinsèques. Son architecture offre une base robuste, simple et vérifiable, parfaitement adaptée à un environnement à haut risque comme celui d'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 qui peut offrir trois avantages clés :
un écosystème mature
En adoptant RISC-V, Ethereum tire pleinement parti des avancées collectives dans le domaine de l'informatique au cours des dernières décennies. Comme l'explique Justin Drake, cela offre à Ethereum un moyen 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 aux développeurs de compiler des langages de programmation de haut niveau vers divers backends. RISC-V est l'un des backends pris en charge. Donc, si vous soutenez RISC-V, vous pouvez automatiquement soutenir tous les langages de haut niveau pris en charge par LLVM. »
Cela a considérablement abaissé le seuil d'entrée pour des millions de développeurs familiers avec des langages tels que Rust, C et Go.
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, rendant le cœur de la machine virtuelle extrêmement simple. Cette simplicité est un énorme avantage en matière de sécurité, car une base de code de confiance plus petite est plus facile à auditer et à vérifier formellement.
Norme de fait dans le domaine des ZK
Plus important encore, l'écosystème zkVM a déjà fait un choix autonome. Comme l'a souligné Justin Drake, on peut voir une tendance claire dans les données d'Ethproofs : « RISC-V est l'ISA leader du backend zkVM. »
Parmi les 10 zkVM capables de prouver des blocs Ethereum, 9 ont choisi RISC-V comme architecture cible. Cette convergence du marché envoie un signal fort : l'adoption de RISC-V par Ethereum n'est pas une tentative spéculative, mais suit une norme validée par le marché.
Conçu pour la confiance, pas seulement pour l'exécution
En plus de l'é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 a une spécification formelle et lisible par machine, appelée SAIL. Cela représente une amélioration considérable par rapport à la spécification de la machine virtuelle Ethereum (EVM), qui existe principalement sous forme de documentation (livre jaune) et qui peut contenir des ambiguïtés. La spécification SAIL fournit la "norme d'or", capable de fournir des preuves mathématiques cruciales pour la correction du protocole, ce qui est essentiel pour protéger des protocoles de grande valeur. Comme l'a souligné Alex Hicks de la Fondation Ethereum (EF) lors de la téléconférence Ethproofs, cela permet aux circuits zkVM d'être validés directement "selon la spécification officielle RISC-V".
Deuxièmement, RISC-V comprend une architecture de privilèges, 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 les applications non fiables, comme les contrats intelligents) et le mode de supervision (pour le « noyau d'exécution » de confiance).
Dans le modèle RISC-V, les contrats intelligents exécutés en mode utilisateur ne peuvent pas accéder directement à l'état de la blockchain. Au lieu de cela, ils doivent émettre une demande à un noyau de confiance s'exécutant en mode superviseur via des instructions ECALL (appels d'environnement) spéciales. Ce mécanisme établit une frontière de sécurité imposée par le matériel, qui est beaucoup plus robuste et facile à vérifier que le modèle de bac à sable EVM basé uniquement sur le logiciel.
La vision de Vitalik
Cette transformation est envisagée comme un processus progressif et multistade, afin d'assurer la stabilité du système et sa compatibilité rétroactive. La méthode décrite par Vitalik Buterin vise à réaliser un développement progressif, plutôt qu'une révolution.
Étape 1 : Remplacement de précompilation
Dans la phase initiale, nous adopterons la méthode la plus conservatrice en introduisant des fonctionnalités limitées pour la nouvelle machine virtuelle (VM). Comme l'a suggéré Vitalik, « nous pouvons commencer à utiliser la nouvelle VM dans des scénarios limités, par exemple en remplaçant la fonctionnalité précompilée. » Cela impliquera de suspendre les nouvelles fonctionnalités précompilées de l'EVM et de les remplacer par des programmes RISC-V approuvés par whitelist pour réaliser les fonctionnalités nécessaires. Cette approche permettra à la nouvelle VM de réaliser des tests 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 : cohabitation de deux machines virtuelles
La prochaine étape sera "d'ouvrir directement la nouvelle machine virtuelle aux utilisateurs". Lors du déploiement des contrats intelligents, un indicateur pourra être ajouté pour indiquer si son code byte est EVM ou RISC-V. La caractéristique clé est d'assurer une interopérabilité transparente : "les deux types de contrats pourront s'appeler mutuellement". Cela sera réalisé par le biais d'appels système (ECALL), le client Ethereum agissant comme intermédiaire de l'environnement d'exécution.
Troisième étape : EVM en tant que contrat simulé (stratégie « Rosetta »)
L'objectif final est de réaliser la simplification ultime du protocole. À ce stade, « nous allons réaliser l'EVM comme une implémentation d'une nouvelle machine virtuelle ». L'EVM normalisé deviendra un contrat intelligent vérifié formellement fonctionnant 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é.
La réaction en chaîne de tout l'écosystème
Le plan de transition de l'EVM vers RISC-V va bien au-delà du protocole de base, il aura un impact profond sur l'ensemble de l'écosystème Ethereum, promettant de remodeler l'expérience des développeurs, de changer fondamentalement le paysage concurrentiel des solutions de Layer-2, et d'ouvrir de nouveaux modèles économiques de preuve.
Reconfiguration des Rollups : Divergence des chemins entre Optimistic et ZK
Le passage à la couche d'exécution RISC-V sur L1 aura des impacts radicalement différents sur deux types principaux de Rollups.
Les modèles de sécurité des Optimistic Rollups (comme Arbitrum et Optimism) reposent sur la réexécution des transactions contestées sur la couche 1 pour résoudre les preuves de fraude. Même si la couche 1 d'Ethereum migre vers RISC-V, ces systèmes ne subiront pas de changements fondamentaux. Comme l'a expliqué l'un des co-fondateurs d'Optimism : « Si nous migrons Ethereum vers RISC-V, la chaîne Optimistic ne sera pas interrompue. Il vous suffit de compiler la machine virtuelle RISC-V dans le programme de preuve. Il n'est pas non plus nécessaire d'utiliser Asterisc. Les systèmes de preuve basés sur MIPS existants ne seront pas interrompus non plus : il vous suffit de compiler la machine virtuelle RISC-V dans MIPS. »
Cela signifie que le modèle de lutte contre la fraude reste intact. L'ajustement est technique : compiler une nouvelle machine virtuelle RISC-V dans l'infrastructure existante, plutôt que de redessiner le système depuis le début. Les défis restants concernent les détails d'ingénierie, tels que la mesure du Gas, l'efficacité et le coût.
En comparaison, les ZK Rollups bénéficieront d'un énorme avantage stratégique. La grande majorité des ZK Rollups ont déjà adopté RISC-V comme leur ISA interne. L'utilisation du même langage natif dans le L1 permet une intégration plus étroite et plus efficace. Justin Drake a décrit la vision future des « Rollups natifs », où le L2 est essentiellement une instance spécialisée de l'environnement d'exécution du L1 lui-même, utilisant le VM L1 intégré pour réaliser un règlement sans friction. Cette intégration entraînera les changements suivants :
Simplifier la pile technologique : éliminer le pont complexe entre l'exécution RISC-V interne de L2 et l'EVM ;
Réaliser la 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, afin de réduire les coûts de développement.
Incitations économiques coordonnées : les frais de Gas de L1 refléteront plus précisément le coût réel de l'exécution de la preuve ZK 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 de l'écosystème Ethereum, ce changement sera progressif, et non disruptif.
Pour les développeurs, l'avantage clé est qu'ils peuvent entrer dans un monde de développement logiciel plus vaste et plus mature. Comme l'a souligné Vitalik Buterin, les développeurs « pourront écrire des contrats en Rust, et ces deux langages commenceront à coexister ». En même temps, il prédit que « Solidity et Vyper resteront populaires pendant longtemps », car ils possèdent une logique de contrat intelligent élégante. La possibilité d'utiliser des langages mainstream et leurs riches bibliothèques via la chaîne d'outils LLVM, ce changement sera révolutionnaire. Vitalik le décrit comme une « expérience similaire à Node.JS », dans laquelle les développeurs peuvent essentiellement utiliser le même langage pour écrire du code on-chain et off-chain.
Pour les utilisateurs, le rendement final est un réseau plus économique et plus puissant. Les coûts de preuve devraient diminuer d'environ 100 fois, passant de quelques dollars par transaction à quelques centimes, ce qui se traduira directement par des frais de règlement de niveau 1 et de niveau 2 plus bas. Cette viabilité économique ouvrira la voie à la vision « Gigagas L1 », qui vise à atteindre environ 10 000 TPS de performance sur L1, soutenant ainsi des applications en chaîne plus complexes et de plus grande valeur à l'avenir.
Succinct Labs et SP1 : prouver que l'avenir est ici et maintenant
Les avantages théoriques de RISC-V ont été mis en pratique par des équipes comme Succinct Labs, dont les résultats de travail fournissent une étude de cas solide pour l'ensemble de la proposition.
Le SP1 développé par Succinct Labs est un zkVM open source haute performance basé sur RISC-V, qui valide la faisabilité de la nouvelle approche architecturale. Il adopte le concept de conception « pré-compilé et centralisé », résolvant parfaitement le problème des goulets d'étranglement cryptographiques de l'EVM. Contrairement aux méthodes pré-compilées traditionnelles qui dépendent de méthodes lentes et codées en dur, le SP1 décharge des opérations intensives comme le hachage Keccak via des appels d'instructions ECALL standard, dans des circuits ZK spécialement conçus et optimisés manuellement. Cela permet d'offrir la performance d'un matériel sur mesure tout en conservant la flexibilité du logiciel.
L'impact pratique de l'équipe est clairement visible, leur produit OP Succinct utilise SP1 pour réaliser la « ZK-ification » (ZK-ify) de l'Optimistic Rollup. Comme l'explique Uma Roy, co-fondatrice de Succinct :
« Votre OP Stack Rollup ne nécessite plus d'attendre 7 jours pour finaliser la confirmation et le retrait... Maintenant, cela ne prend qu'une heure. Cela améliore considérablement la vitesse de confirmation finale, c'est vraiment génial. »
Cela 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 », est conçue comme un marché de génération de preuves décentralisé, présentant un modèle économique viable pour l'avenir du calcul vérifiable. Leur travail n'est pas seulement une preuve de concept, mais plutôt une feuille de route viable pour l'avenir décrite dans cet article.
Comment Ethereum réduit-il les risques
Un avantage clé de RISC-V est qu'il rend l'objectif ultime de la vérification formelle - prouver la correction d'un système par des preuves mathématiques - un objectif réalisable. La spécification de l'EVM est écrite en langage naturel dans le Yellow Paper, ce qui rend la formalisation extrêmement difficile. En revanche, RISC-V dispose d'une spécification SAIL officielle et lisible par machine, fournissant un "référentiel d'or" clair pour son comportement.
Cela ouvre 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 le circuit zkVM RISC-V et la spécification RISC-V officielle dans Lean pour une vérification formelle". C'est un progrès marquant qui transfère la confiance des implémentations humaines sujettes à erreur vers des preuves mathématiques vérifiables, permettant ainsi une avancée en matière de sécurité.
Les principaux risques de la transformation
Bien que l'architecture RISC-V L1 présente de nombreux avantages, elle sera également confrontée à de nouveaux défis complexes.
Problème de mesure du Gas : Créer un modèle de Gas déterministe et équitable pour l'ISA général est l'un des problèmes les plus difficiles à résoudre. Une méthode simple de comptage des instructions est facilement vulnérable aux attaques par déni de service. Par exemple, un attaquant peut concevoir un programme qui déclenche à plusieurs reprises un programme mis en cache, entraînant une occupation élevée des ressources avec un coût en Gas très faible.
Sécurité de la chaîne d'outils et problème de « construction reproductible » : cela pourrait être le risque le plus important et sous-estimé dans le processus de transformation. Le modèle de sécurité passe de la machine virtuelle de la chaîne de confiance à la confiance dans les compilateurs hors chaîne utilisés par chaque développeur (comme LLVM), qui 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, s'assurer que les fichiers binaires compilés sur la chaîne correspondent exactement à un code source public spécifique, c'est-à-dire le problème de « construction reproductible », est également très difficile à réaliser, car de légères différences dans l'environnement de construction peuvent produire des fichiers binaires différents.
Stratégie d'atténuation
La route à suivre nécessite des stratégies de défense multicouches.
Lancement par étapes : Un plan de transition progressif et par phases est la principale stratégie d'atténuation des risques. En introduisant d'abord RISC-V comme solution précompilée, puis en déployant 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 avant que des changements irréversibles ne se produisent.
Audit complet : tests de fuzzing et vérification formelle. Bien que la vérification formelle soit l'objectif final, elle doit être accompagnée de tests continus et intensifs. Comme l'a montré Valentine de Diligence Security lors de la conférence téléphonique d'Ethproofs, leur testeur de fuzzing Argus a déjà découvert 11 vulnérabilités critiques de solidité et d'intégrité dans les zkVM de pointe. Cela prouve que même les systèmes les mieux conçus présentent des failles, qui ne peuvent être découvertes que par des tests d'adversité rigoureux.
Standardisation : Pour éviter la fragmentation de l'écosystème, la communauté doit adopter un seul profil RISC-V standardisé. Il s'agit très probablement d'une combinaison d'ABI compatible avec RV64 GC et Linux, car cette combinaison peut offrir le soutien le plus large provenant de langages et d'outils mainstream, maximisant ainsi les avantages du nouvel écosystème.
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.
Accumulation de la dette technique, comment Ethereum reconstruit l'architecture technique avec RISC-V pour trouver une solution ?
Rédigé par : jaehaerys.eth
Compilation : Glendon, Techub News
TL;DR
Ethereum subit la transformation architecturale la plus importante depuis sa création : remplacer la machine virtuelle Ethereum (EVM) par RISC-V. La raison fondamentale de ce changement est qu'à l'ère des preuves à divulgation nulle de connaissance (ZK), l'EVM est devenu le plus grand goulot d'étranglement :
L'zkEVM actuel dépend de l'exécution de l'interpréteur, ce qui entraîne une réduction de la vitesse de 50 à 800 fois ;
Les contrats précompilés (Precompiles) rendent le protocole trop complexe et augmentent les risques ;
La conception de la pile de 256 bits est extrêmement inefficace dans la preuve.
RISC-V peut résoudre ces problèmes :
Minimalisme (environ 47 instructions de base) + écosystème LLVM mature (supporte Rust, C++, Go) ;
Devenu le standard zkVM de facto (90% des projets l'adoptent) ;
La spécification SAIL formalisée (par rapport au livre jaune ambigu) peut supporter une validation stricte;
Le chemin de preuve matériel (ASIC/FPGA) est en cours de test (SP1, Nervos, Cartesi).
La migration se déroule en trois phases :
RISC-V en tant qu'alternative aux contrats précompilés (tests à faible risque) ;
L'ère des doubles machines virtuelles : EVM + RISC-V ont une interopérabilité complète ;
EVM réimplémenté à l'intérieur de RISC-V (similaire à la stratégie Rosetta).
Impact de l'écosystème :
Les Optimistic Rollups ne sont pas affectés ; le réseau principal RISC-V ne supprimera pas les preuves de fraude, les programmes de preuve existants peuvent être compilés pour s'adapter à RISC-V (actuellement basé sur MIPS) ; chemin de migration : étendre l'infrastructure de tolérance aux pannes actuelle vers le RISC-V cible, plutôt que de le reconstruire complètement ;
ZK Rollup bénéficiera grandement (Polygon, zkSync, Scroll → moins cher, plus rapide, plus simple) ;
Les développeurs peuvent directement utiliser les bibliothèques Rust/Go/Python sur L1 ;
Les utilisateurs peuvent obtenir un coût de preuve environ 100 fois moins cher, les conduisant vers le niveau Gigagas (environ 10k TPS) de L1.
Finalement, Ethereum évoluera d'une « machine virtuelle de contrats intelligents » en une couche de confiance internet minimale et vérifiable, dont l'objectif ultime est : « tout devient ZK-Snark ».
Ethereum est à un carrefour.
Avec l'objectif ultime de "tout rendre ZK-Snark", Ethereum se trouve maintenant à un seuil d'évolution architecturale le plus important depuis sa création. Cette discussion ne se limite plus à des mises à niveau progressives, mais constitue une reconstruction fondamentale de son noyau de calcul - c'est-à-dire le remplacement de la machine virtuelle Ethereum (EVM). Cette initiative est la pierre angulaire d'une vision plus large de "Lean Ethereum", qui vise à simplifier systématiquement l'ensemble du protocole en le décomposant en trois composants clés : consensus allégé (Lean Consensus), données allégées (Lean Data) et exécution allégée (Lean Execution). La question centrale de l'exécution simplifiée est la suivante : l'EVM, en tant que moteur de la révolution des contrats intelligents, est-il désormais 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", un puissant outil capable d'améliorer les différents niveaux du protocole. Mais pendant longtemps, cet objectif ressemblait plus à un "château en Espagne", car sa réalisation nécessitait une preuve en temps réel de ce concept. Et aujourd'hui, alors que la preuve en temps réel devient progressivement une réalité, l'inefficacité théorique de l'EVM s'est transformée en un problème pratique urgent à résoudre.
Cette analyse examinera les arguments techniques et stratégiques liés à la migration de l'Ethereum L1 vers l'architecture d'ensemble d'instructions RISC-V (ISA), une initiative qui devrait libérer une évolutivité sans précédent, simplifier la structure du protocole et aligner Ethereum avec l'avenir du calcul vérifiable.
Qu'est-ce qui a vraiment changé ?
Avant d'explorer en profondeur le « pourquoi », il est d'abord nécessaire de comprendre « quoi » est en train de changer.
L'EVM est l'environnement d'exécution des contrats intelligents d'Ethereum, agissant comme un "ordinateur mondial" qui traite les transactions et met à jour l'état de la blockchain. Au fil des ans, sa conception a été révolutionnaire, créant une plateforme sans autorisation et donnant naissance à tout un écosystème DeFi et NFT. Cependant, cette architecture sur mesure, qui date d'il y a près de dix ans, a maintenant accumulé une lourde dette technique.
En comparaison, RISC-V n'est pas un produit, mais un standard ouvert - un "alphabet" de conception de processeurs gratuit et universel. Comme l'a souligné Jeremy Bruestle lors de la conférence téléphonique Ethproofs, ses principes clés en font le choix évident pour ce rôle :
Minimalisme : l'ensemble d'instructions de base est extrêmement simple, ne contenant qu'environ 40 à 47 instructions. Jeremy le décrit comme « presque le cas d'utilisation parfait de notre machine universelle ultra-compacte dont nous avons besoin ».
Modularité : ajout de fonctionnalités plus complexes grâce à des extensions optionnelles. C'est essentiel car cela permet un noyau simple, pouvant être étendu à la demande, sans imposer de complexité inutile au protocole de base ;
Écosystème ouvert : il dispose d'une vaste et mature chaîne d'outils, y compris le compilateur LLVM, permettant aux développeurs d'utiliser des langages courants tels que Rust, C++ et Go. Comme l'a dit Justin Drake : « Il existe de nombreux outils liés aux compilateurs, et la construction d'un compilateur est extrêmement difficile... Par conséquent, avoir ces outils de compilateur a une grande valeur. » RISC-V permet à Ethereum d'hériter gratuitement de ces outils déjà disponibles.
Problème de coût de l'interpréteur
La nécessité de remplacer l'EVM ne découle pas d'un seul défaut, mais d'une série de limitations fondamentales qui, dans le contexte d'un avenir natif des preuves à divulgation nulle de connaissance (ZK), sont devenues impossibles à ignorer. Ces problèmes englobent de graves goulets d'étranglement en termes de performance dans les systèmes de preuve ZK, ainsi que les risques liés à la complexité croissante accumulée à l'intérieur 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 à divulgation nulle. À mesure qu'Ethereum se dirige progressivement vers un modèle de validation de l'état de L1 par des preuves ZK, la performance des prouveurs deviendra le goulet d'étranglement final.
Le problème réside dans le fonctionnement actuel de zkEVM. Ils ne font pas de preuves à connaissance zéro directement sur l'EVM, mais sur un interpréteur de l'EVM, qui est lui-même compilé en RISC-V. Vitalik Buterin a souligné ce problème central de manière frappante :
« 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 ouvrir directement le RISC-V sous-jacent aux développeurs de contrats intelligents ? Cela permettrait d'éliminer complètement les coûts de la machine virtuelle externe. »
Cette couche d'explication supplémentaire entraîne une perte de performance énorme. Selon les estimations, par rapport à la preuve de programmes natifs, cette couche pourrait entraîner une baisse de performance de 50 à 800 fois. Après avoir optimisé d'autres goulets d'étranglement (comme en passant à l'algorithme de hachage Poseidon), cette partie de « l'exécution de bloc » continuera à consommer 80 à 90 % du temps de preuve, faisant de l'EVM le dernier et le plus obstiné des obstacles à l'expansion de L1. Si cette couche était supprimée, Vitalik prévoit que l'efficacité d'exécution pourrait être améliorée de 100 fois.
Les pièges d'endettement des contrats précompilés
Pour résoudre le problème de performance insuffisante de l'EVM dans certaines opérations cryptographiques, Ethereum a introduit les contrats précompilés - intégrant directement des fonctions spécialisées dans le protocole. Bien que cela ait été une solution pragmatique à l'époque, cela a conduit aujourd'hui à ce que Vitalik Buterin appelle une situation "catastrophique" :
« La précompilation est catastrophique pour nous… elle a considérablement gonflé la base de code fiable d'Ethereum… et au bord d'un échec de consensus, elle nous a fait frôler le désastre à plusieurs reprises. »
Sa complexité est stupéfiante. Vitalik a souligné, en comparant le code d'emballage d'un seul contrat précompilé (modexp) avec un interpréteur complet RISC-V, que la logique précompilée est en réalité beaucoup plus complexe. L'ajout de précompilés doit passer par un processus de hard fork lent et rempli de jeux politiques, ce qui entrave gravement l'innovation des applications reposant sur de nouveaux primitifs cryptographiques.
Ainsi, Vitalik en arrive à une conclusion ferme : « Je pense en fait que nous devrions immédiatement cesser d'ajouter de nouveaux contrats précompilés. »
La dette technique de l'architecture d'Ethereum
La conception centrale de l'EVM reflète des besoins d'époque obsolètes, mais elle n'est plus adaptée à l'informatique moderne. L'EVM a choisi une architecture de 256 bits pour traiter des valeurs cryptographiques, ce qui est extrêmement inefficace par rapport aux entiers de 32 bits ou 64 bits généralement utilisés dans les contrats intelligents. Le coût de cette inefficacité est particulièrement élevé dans les systèmes de preuve à connaissance nulle.
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 2 à 4 fois. »
En outre, l'architecture de pile de l'EVM est moins efficace que l'architecture des registres du RISC-V et des processeurs modernes. Elle nécessite plus d'instructions pour exécuter les mêmes opérations, rendant également l'optimisation du compilateur plus complexe.
Ces facteurs combinés incluent les goulets d'étranglement de performance des preuves ZK, la complexité des précompilations et des choix d'architecture obsolètes, constituant ensemble une raison convaincante et urgente pour qu'Ethereum dépasse l'EVM.
RISC-V Blueprint : établir une base plus solide
Les avantages de RISC-V ne proviennent pas seulement des lacunes de l'EVM, mais résident également dans sa philosophie de conception et ses avantages intrinsèques. Son architecture offre une base robuste, simple et vérifiable, parfaitement adaptée à un environnement à haut risque comme celui d'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 qui peut offrir trois avantages clés :
un écosystème mature
En adoptant RISC-V, Ethereum tire pleinement parti des avancées collectives dans le domaine de l'informatique au cours des dernières décennies. Comme l'explique Justin Drake, cela offre à Ethereum un moyen 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 aux développeurs de compiler des langages de programmation de haut niveau vers divers backends. RISC-V est l'un des backends pris en charge. Donc, si vous soutenez RISC-V, vous pouvez automatiquement soutenir tous les langages de haut niveau pris en charge par LLVM. »
Cela a considérablement abaissé le seuil d'entrée pour des millions de développeurs familiers avec des langages tels que Rust, C et Go.
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, rendant le cœur de la machine virtuelle extrêmement simple. Cette simplicité est un énorme avantage en matière de sécurité, car une base de code de confiance plus petite est plus facile à auditer et à vérifier formellement.
Norme de fait dans le domaine des ZK
Plus important encore, l'écosystème zkVM a déjà fait un choix autonome. Comme l'a souligné Justin Drake, on peut voir une tendance claire dans les données d'Ethproofs : « RISC-V est l'ISA leader du backend zkVM. »
Parmi les 10 zkVM capables de prouver des blocs Ethereum, 9 ont choisi RISC-V comme architecture cible. Cette convergence du marché envoie un signal fort : l'adoption de RISC-V par Ethereum n'est pas une tentative spéculative, mais suit une norme validée par le marché.
Conçu pour la confiance, pas seulement pour l'exécution
En plus de l'é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 a une spécification formelle et lisible par machine, appelée SAIL. Cela représente une amélioration considérable par rapport à la spécification de la machine virtuelle Ethereum (EVM), qui existe principalement sous forme de documentation (livre jaune) et qui peut contenir des ambiguïtés. La spécification SAIL fournit la "norme d'or", capable de fournir des preuves mathématiques cruciales pour la correction du protocole, ce qui est essentiel pour protéger des protocoles de grande valeur. Comme l'a souligné Alex Hicks de la Fondation Ethereum (EF) lors de la téléconférence Ethproofs, cela permet aux circuits zkVM d'être validés directement "selon la spécification officielle RISC-V".
Deuxièmement, RISC-V comprend une architecture de privilèges, 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 les applications non fiables, comme les contrats intelligents) et le mode de supervision (pour le « noyau d'exécution » de confiance).
Dans le modèle RISC-V, les contrats intelligents exécutés en mode utilisateur ne peuvent pas accéder directement à l'état de la blockchain. Au lieu de cela, ils doivent émettre une demande à un noyau de confiance s'exécutant en mode superviseur via des instructions ECALL (appels d'environnement) spéciales. Ce mécanisme établit une frontière de sécurité imposée par le matériel, qui est beaucoup plus robuste et facile à vérifier que le modèle de bac à sable EVM basé uniquement sur le logiciel.
La vision de Vitalik
Cette transformation est envisagée comme un processus progressif et multistade, afin d'assurer la stabilité du système et sa compatibilité rétroactive. La méthode décrite par Vitalik Buterin vise à réaliser un développement progressif, plutôt qu'une révolution.
Étape 1 : Remplacement de précompilation
Dans la phase initiale, nous adopterons la méthode la plus conservatrice en introduisant des fonctionnalités limitées pour la nouvelle machine virtuelle (VM). Comme l'a suggéré Vitalik, « nous pouvons commencer à utiliser la nouvelle VM dans des scénarios limités, par exemple en remplaçant la fonctionnalité précompilée. » Cela impliquera de suspendre les nouvelles fonctionnalités précompilées de l'EVM et de les remplacer par des programmes RISC-V approuvés par whitelist pour réaliser les fonctionnalités nécessaires. Cette approche permettra à la nouvelle VM de réaliser des tests 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 : cohabitation de deux machines virtuelles
La prochaine étape sera "d'ouvrir directement la nouvelle machine virtuelle aux utilisateurs". Lors du déploiement des contrats intelligents, un indicateur pourra être ajouté pour indiquer si son code byte est EVM ou RISC-V. La caractéristique clé est d'assurer une interopérabilité transparente : "les deux types de contrats pourront s'appeler mutuellement". Cela sera réalisé par le biais d'appels système (ECALL), le client Ethereum agissant comme intermédiaire de l'environnement d'exécution.
Troisième étape : EVM en tant que contrat simulé (stratégie « Rosetta »)
L'objectif final est de réaliser la simplification ultime du protocole. À ce stade, « nous allons réaliser l'EVM comme une implémentation d'une nouvelle machine virtuelle ». L'EVM normalisé deviendra un contrat intelligent vérifié formellement fonctionnant 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é.
La réaction en chaîne de tout l'écosystème
Le plan de transition de l'EVM vers RISC-V va bien au-delà du protocole de base, il aura un impact profond sur l'ensemble de l'écosystème Ethereum, promettant de remodeler l'expérience des développeurs, de changer fondamentalement le paysage concurrentiel des solutions de Layer-2, et d'ouvrir de nouveaux modèles économiques de preuve.
Reconfiguration des Rollups : Divergence des chemins entre Optimistic et ZK
Le passage à la couche d'exécution RISC-V sur L1 aura des impacts radicalement différents sur deux types principaux de Rollups.
Les modèles de sécurité des Optimistic Rollups (comme Arbitrum et Optimism) reposent sur la réexécution des transactions contestées sur la couche 1 pour résoudre les preuves de fraude. Même si la couche 1 d'Ethereum migre vers RISC-V, ces systèmes ne subiront pas de changements fondamentaux. Comme l'a expliqué l'un des co-fondateurs d'Optimism : « Si nous migrons Ethereum vers RISC-V, la chaîne Optimistic ne sera pas interrompue. Il vous suffit de compiler la machine virtuelle RISC-V dans le programme de preuve. Il n'est pas non plus nécessaire d'utiliser Asterisc. Les systèmes de preuve basés sur MIPS existants ne seront pas interrompus non plus : il vous suffit de compiler la machine virtuelle RISC-V dans MIPS. »
Cela signifie que le modèle de lutte contre la fraude reste intact. L'ajustement est technique : compiler une nouvelle machine virtuelle RISC-V dans l'infrastructure existante, plutôt que de redessiner le système depuis le début. Les défis restants concernent les détails d'ingénierie, tels que la mesure du Gas, l'efficacité et le coût.
En comparaison, les ZK Rollups bénéficieront d'un énorme avantage stratégique. La grande majorité des ZK Rollups ont déjà adopté RISC-V comme leur ISA interne. L'utilisation du même langage natif dans le L1 permet une intégration plus étroite et plus efficace. Justin Drake a décrit la vision future des « Rollups natifs », où le L2 est essentiellement une instance spécialisée de l'environnement d'exécution du L1 lui-même, utilisant le VM L1 intégré pour réaliser un règlement sans friction. Cette intégration entraînera les changements suivants :
Simplifier la pile technologique : éliminer le pont complexe entre l'exécution RISC-V interne de L2 et l'EVM ;
Réaliser la 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, afin de réduire les coûts de développement.
Incitations économiques coordonnées : les frais de Gas de L1 refléteront plus précisément le coût réel de l'exécution de la preuve ZK 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 de l'écosystème Ethereum, ce changement sera progressif, et non disruptif.
Pour les développeurs, l'avantage clé est qu'ils peuvent entrer dans un monde de développement logiciel plus vaste et plus mature. Comme l'a souligné Vitalik Buterin, les développeurs « pourront écrire des contrats en Rust, et ces deux langages commenceront à coexister ». En même temps, il prédit que « Solidity et Vyper resteront populaires pendant longtemps », car ils possèdent une logique de contrat intelligent élégante. La possibilité d'utiliser des langages mainstream et leurs riches bibliothèques via la chaîne d'outils LLVM, ce changement sera révolutionnaire. Vitalik le décrit comme une « expérience similaire à Node.JS », dans laquelle les développeurs peuvent essentiellement utiliser le même langage pour écrire du code on-chain et off-chain.
Pour les utilisateurs, le rendement final est un réseau plus économique et plus puissant. Les coûts de preuve devraient diminuer d'environ 100 fois, passant de quelques dollars par transaction à quelques centimes, ce qui se traduira directement par des frais de règlement de niveau 1 et de niveau 2 plus bas. Cette viabilité économique ouvrira la voie à la vision « Gigagas L1 », qui vise à atteindre environ 10 000 TPS de performance sur L1, soutenant ainsi des applications en chaîne plus complexes et de plus grande valeur à l'avenir.
Succinct Labs et SP1 : prouver que l'avenir est ici et maintenant
Les avantages théoriques de RISC-V ont été mis en pratique par des équipes comme Succinct Labs, dont les résultats de travail fournissent une étude de cas solide pour l'ensemble de la proposition.
Le SP1 développé par Succinct Labs est un zkVM open source haute performance basé sur RISC-V, qui valide la faisabilité de la nouvelle approche architecturale. Il adopte le concept de conception « pré-compilé et centralisé », résolvant parfaitement le problème des goulets d'étranglement cryptographiques de l'EVM. Contrairement aux méthodes pré-compilées traditionnelles qui dépendent de méthodes lentes et codées en dur, le SP1 décharge des opérations intensives comme le hachage Keccak via des appels d'instructions ECALL standard, dans des circuits ZK spécialement conçus et optimisés manuellement. Cela permet d'offrir la performance d'un matériel sur mesure tout en conservant la flexibilité du logiciel.
L'impact pratique de l'équipe est clairement visible, leur produit OP Succinct utilise SP1 pour réaliser la « ZK-ification » (ZK-ify) de l'Optimistic Rollup. Comme l'explique Uma Roy, co-fondatrice de Succinct :
« Votre OP Stack Rollup ne nécessite plus d'attendre 7 jours pour finaliser la confirmation et le retrait... Maintenant, cela ne prend qu'une heure. Cela améliore considérablement la vitesse de confirmation finale, c'est vraiment génial. »
Cela 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 », est conçue comme un marché de génération de preuves décentralisé, présentant un modèle économique viable pour l'avenir du calcul vérifiable. Leur travail n'est pas seulement une preuve de concept, mais plutôt une feuille de route viable pour l'avenir décrite dans cet article.
Comment Ethereum réduit-il les risques
Un avantage clé de RISC-V est qu'il rend l'objectif ultime de la vérification formelle - prouver la correction d'un système par des preuves mathématiques - un objectif réalisable. La spécification de l'EVM est écrite en langage naturel dans le Yellow Paper, ce qui rend la formalisation extrêmement difficile. En revanche, RISC-V dispose d'une spécification SAIL officielle et lisible par machine, fournissant un "référentiel d'or" clair pour son comportement.
Cela ouvre 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 le circuit zkVM RISC-V et la spécification RISC-V officielle dans Lean pour une vérification formelle". C'est un progrès marquant qui transfère la confiance des implémentations humaines sujettes à erreur vers des preuves mathématiques vérifiables, permettant ainsi une avancée en matière de sécurité.
Les principaux risques de la transformation
Bien que l'architecture RISC-V L1 présente de nombreux avantages, elle sera également confrontée à de nouveaux défis complexes.
Problème de mesure du Gas : Créer un modèle de Gas déterministe et équitable pour l'ISA général est l'un des problèmes les plus difficiles à résoudre. Une méthode simple de comptage des instructions est facilement vulnérable aux attaques par déni de service. Par exemple, un attaquant peut concevoir un programme qui déclenche à plusieurs reprises un programme mis en cache, entraînant une occupation élevée des ressources avec un coût en Gas très faible.
Sécurité de la chaîne d'outils et problème de « construction reproductible » : cela pourrait être le risque le plus important et sous-estimé dans le processus de transformation. Le modèle de sécurité passe de la machine virtuelle de la chaîne de confiance à la confiance dans les compilateurs hors chaîne utilisés par chaque développeur (comme LLVM), qui 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, s'assurer que les fichiers binaires compilés sur la chaîne correspondent exactement à un code source public spécifique, c'est-à-dire le problème de « construction reproductible », est également très difficile à réaliser, car de légères différences dans l'environnement de construction peuvent produire des fichiers binaires différents.
Stratégie d'atténuation
La route à suivre nécessite des stratégies de défense multicouches.
Lancement par étapes : Un plan de transition progressif et par phases est la principale stratégie d'atténuation des risques. En introduisant d'abord RISC-V comme solution précompilée, puis en déployant 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 avant que des changements irréversibles ne se produisent.
Audit complet : tests de fuzzing et vérification formelle. Bien que la vérification formelle soit l'objectif final, elle doit être accompagnée de tests continus et intensifs. Comme l'a montré Valentine de Diligence Security lors de la conférence téléphonique d'Ethproofs, leur testeur de fuzzing Argus a déjà découvert 11 vulnérabilités critiques de solidité et d'intégrité dans les zkVM de pointe. Cela prouve que même les systèmes les mieux conçus présentent des failles, qui ne peuvent être découvertes que par des tests d'adversité rigoureux.
Standardisation : Pour éviter la fragmentation de l'écosystème, la communauté doit adopter un seul profil RISC-V standardisé. Il s'agit très probablement d'une combinaison d'ABI compatible avec RV64 GC et Linux, car cette combinaison peut offrir le soutien le plus large provenant de langages et d'outils mainstream, maximisant ainsi les avantages du nouvel écosystème.