Auteur : Grey Lobster, Shenchao TechFlow
Les développeurs d’Ethereum ont une habitude tacite : éviter l’EVM autant que possible.
Au cours des dernières années, chaque fois qu'une nouvelle opération cryptographique était nécessaire sur la chaîne, la première réaction des développeurs n'était pas de l'implémenter dans l'EVM, mais de demander l'ajout d'un « contrat précompilé », une méthode rapide qui contourne la machine virtuelle en étant directement codée en dur au niveau du protocole.
Le 1er mars, Vitalik Buterin a publié un long message sur X, dévoilant ouvertement la question. Il a essentiellement déclaré : la valeur même d'Ethereum réside dans sa polyvalence ; si l'EVM n'est pas suffisamment bon, nous devons aborder directement ce problème en créant une meilleure machine virtuelle.
Il a présenté deux scalpelles spécifiques.
First cut: Replace "data structure"
La première modification concerne l'arbre d'état d'Ethereum. Vous pouvez le comprendre comme le « système d'indexation du registre » d'Ethereum, que l'on parcourt à chaque fois qu'on consulte un solde ou qu'on valide une transaction.
Le problème, c’est que cet arbre est trop « gros ». Ethereum utilise une structure appelée « hexa-Keccak Merkle Patricia tree » (un nom qui ressemble à un sortilège). L’EIP-7864 proposé par Vitalik vise à le remplacer par un arbre binaire plus simple.
Par exemple : auparavant, pour rechercher une donnée, vous deviez choisir continuellement votre direction à un carrefour à six branches ; maintenant, vous n'avez plus qu'à choisir entre gauche et droite. Quel est le résultat ? La longueur de la branche Merkle est directement réduite à un quart de son ancienne taille. Pour les clients légers, la bande passante nécessaire pour valider les données diminue considérablement.
Mais Vitalik ne se contente pas de changer la forme de l'arbre ; il veut également changer la police des feuilles, c'est-à-dire la fonction de hachage. Les candidats sont Blake3 et Poseidon.
- Blake3 permet d'obtenir une accélération stable ;
- Poseidon est plus agressif et pourrait théoriquement augmenter l'efficacité de la preuve de plusieurs dizaines de fois, mais sa sécurité nécessite encore davantage d'audits.
Il convient de souligner que cette solution remplace en réalité les Verkle Trees, qui avaient été débattues par la communauté pendant des années. Les Verkle Trees étaient initialement le choix privilégié pour le hard fork de 2026, mais en raison des menaces posées par l'informatique quantique sur la cryptographie courbe elliptique sur laquelle elles reposent, elles ont perdu en popularité à partir du milieu de l'année 2024, permettant aux solutions basées sur des arbres binaires de prendre le dessus.
Deuxième coup : remplacez la « machine virtuelle » en faisant de l'EVM un contrat intelligent
Le deuxième changement est plus audacieux et plus controversé : remplacer l'EVM par l'architecture RISC-V à long terme.
RISC-V est un jeu d'instructions open source, initialement sans lien avec la blockchain, mais il est désormais utilisé dans presque tous les systèmes de preuve ZK. La logique de Vitalik est simple : puisque les proveurs parlent déjà le langage RISC-V, pourquoi la machine virtuelle utiliserait-elle un autre langage avec une couche de traduction intermédiaire ? En supprimant cette couche de traduction, l'efficacité augmente naturellement.
Un interpréteur RISC-V ne nécessite que quelques centaines de lignes de code. Vitalik dit que c'est ainsi que devrait être une machine virtuelle blockchain.
Il a planifié une approche en trois étapes : premièrement, exécuter les contrats précompilés sur une nouvelle machine virtuelle et réécrire 80 % des contrats précompilés existants avec le code de la nouvelle VM ; deuxièmement, permettre aux développeurs de déployer directement des contrats sur la nouvelle machine virtuelle, en parallèle avec l’EVM ; troisièmement, mettre hors service l’EVM, mais pas la supprimer — elle sera réécrite comme un contrat intelligent s’exécutant sur la nouvelle machine virtuelle, assurant une compatibilité totale vers l’arrière.
Les anciens propriétaires n’ont pas besoin de changer de voiture. Seul le moteur a été remplacé discrètement, le volant reste le même.
Combien ces deux éléments sont-ils importants ? Vitalik a fourni un chiffre : l'arbre d'état et la machine virtuelle représentent ensemble plus de 80 % du goulot d'étranglement de la preuve d'Ethereum. Autrement dit, sans modifier ces deux composants, l'évolutivité d'Ethereum à l'ère ZK ne sera qu'une marche sur place.
Arbitrum n'est pas d'accord : tu ne peux pas exiger que le livreur conduise un chariot élévateur juste parce que l'entrepôt en utilise un.
Mais ce n'est pas une histoire que tout le monde approuve.
En novembre de l'année dernière, l'équipe de développement principale d'Arbitrum, Offchain Labs, a publié une réfutation technique détaillée. Le point central des quatre chercheurs était que RISC-V est effectivement adapté aux preuves ZK, mais qu'il ne convient pas comme « format de livraison » pour les contrats.
Ils ont souligné une distinction essentielle : l'ensemble d'instructions de livraison (dISA) et l'ensemble d'instructions de preuve (pISA) n'ont pas besoin d'être identiques. Votre entrepôt peut être le plus efficace avec un chariot élévateur, mais cela ne signifie pas que le livreur doit aussi utiliser un chariot élévateur pour vous livrer à votre porte.
Offchain Labs défend l'utilisation de WebAssembly (WASM) pour la couche de contrat, avec des arguments solides : WASM offre une exécution efficace sur le matériel standard, tandis que la plupart des nœuds Ethereum ne fonctionnent pas sur des puces RISC-V, ce qui rend un changement forcé nécessairement dépendant d'un émulateur ; WASM dispose de mécanismes matures de vérification de sécurité des types ; l'écosystème d'outils WASM a été éprouvé en conditions réelles sur des milliards d'environnements d'exécution.
Plus important encore, ils ne se contentent pas de parler. Offchain Labs a déjà mis en œuvre un prototype sur Arbitrum : utiliser WASM comme format de livraison des contrats, puis le compiler en RISC-V pour la preuve ZK. Les deux couches accomplissent leurs tâches respectives sans interférer.
Ils ont également soulevé un risque méritant une réflexion approfondie : les technologies dans le domaine des preuves ZK évoluent extrêmement rapidement, et la mise en œuvre récente de RISC-V a déjà passé de 32 à 64 bits. Si l’on fixe maintenant RISC-V sur Ethereum L1, que se passera-t-il si, dans deux ans, une architecture de preuve supérieure émerge ? Parier sur une cible en mouvement rapide n’est pas dans l’esprit d’Ethereum.
Un contexte plus large : les L2 commencent à se sevrer
Comprendre cette proposition nécessite un contexte plus global.
Il y a juste un mois, Vitalik a publiquement remis en question la nécessité pour Ethereum d'avoir une « feuille de route L2 dédiée », suscitant une réponse collective de la communauté L2. Ben Fisch, PDG d'Espresso Systems, a déclaré à CoinDesk une phrase particulièrement pertinente : ce que Vitalik entendait en réalité, c'est que le but initial des L2 était d'aider Ethereum à évoluer ; maintenant qu'Ethereum devient lui-même plus rapide, la position des L2 doit naturellement évoluer.
Il est intéressant de noter que les L2, loin de paniquer, commencent activement à « se dés-éthérifier ». Jing Wang, cofondateur d'OP Labs, compare les L2 à des sites web indépendants, avec Ethereum servant de standard de règlement ouvert sous-jacent. Marc Boiron, PDG de Polygon, exprime cela plus directement : le véritable défi n'est pas l'extensibilité, mais la création d'espace bloc dédié pour des cas d'utilisation réels comme les paiements.
En d'autres termes, cette révision majeure de Vitalik au niveau d'exécution est une note technique d'une tendance plus vaste : Ethereum reprend le contrôle de ses capacités fondamentales, tandis que les L2 sont contraints — ou enfin — à trouver leur propre raison d'exister.
Will this work?
Vitalik a lui-même reconnu qu'il n'existe pas encore de large consensus au sein de la communauté des développeurs sur le remplacement de la machine virtuelle. La réforme de l'arbre d'état est plus avancée, et l'EIP-7864 possède déjà un projet concret et une équipe de promotion. Mais remplacer l'EVM par RISC-V ? Cela reste encore au stade du « plan stratégique » et est encore loin d'être intégré dans le code.
Cependant, Vitalik a fait une déclaration impressionnante la semaine dernière : Ethereum a déjà changé un moteur à réaction en plein vol (reférant à The Merge), et il pourra en changer encore environ quatre fois — l'arbre d'état, la consensus simplifié, la vérification ZK-EVM, le remplacement de la machine virtuelle.
La mise à jour Glamsterdam d'Ethereum est prévue pour le premier semestre 2026, suivie de près par Hegota. Les détails précis de ces deux hard forks ne sont pas encore finalisés, mais la réforme de l'arbre d'état et les optimisations de la couche d'exécution constituent les axes principaux confirmés.
L'histoire d'Ethereum n'a jamais été une question de « pouvoir ou non ». Passant du PoW au PoS, passant d'une approche L1 tout-en-un à une architecture centrée sur les Rollups, il a démontré sa capacité et son audace à démonter des moteurs à dix mille mètres d'altitude.
Ce que l'on va modifier cette fois, c'est quelque chose de plus profond — pas ajouter de nouvelles fonctionnalités, mais démolir les fondations anciennes pour les refondre. S'agit-il d'une rénovation réfléchie ou d'un trou sans fond qui ne cesse de s'aggraver ? La réponse ne sera probablement pas claire avant 2027.
Mais au moins une chose est certaine : Ethereum n'a pas l'intention de devenir un « système ancien réparé » à l'ère ZK. Quant à la manière de démonter les réparations et de remplacer le moteur par quel modèle, ce débat lui-même pourrait être plus précieux que la conclusion.