Vitalik propose de grands changements à la machine virtuelle et à l'arbre d'état d'ethereum

Article rédigé par 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 contournant la machine virtuelle en codant directement cette fonctionnalité au niveau du protocole.

Le 1er mars, Vitalik Buterin a publié un long message sur X, dévoilant complètement la vérité. Il a essentiellement déclaré : la raison d’être d’Ethereum réside dans sa polyvalence ; si l’EVM n’est pas suffisamment bon, nous devons aborder directement ce problème et créer une meilleure machine virtuelle.

Il a présenté deux scalpel spécifiques.

La première modification concerne l'arbre d'état d'Ethereum. Vous pouvez le comprendre comme le « système d'index 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 « sextuple 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, il ne reste que deux options : gauche ou 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 aussi changer la police des feuilles, c'est-à-dire la fonction de hachage. Deux candidats sont en lice : Blake3 et Poseidon. Blake3 offre une accélération stable ; Poseidon est plus audacieux et pourrait théoriquement augmenter l'efficacité des preuves de plusieurs dizaines de fois, mais sa sécurité nécessite encore davantage d'audits.

Il convient de noter que cette solution remplace en réalité les Verkle Trees, dont la discussion communautaire durait depuis plusieurs années. Les Verkle Trees étaient initialement la solution privilégiée pour le hard fork de 2026, mais en raison des menaces posées par l'informatique quantique sur la cryptographie basée sur les courbes elliptiques dont ils dépendent, ils ont progressivement perdu en popularité à partir du milieu de l'année 2024, permettant aux solutions basées sur des arbres binaires de prendre le dessus.

La deuxième modification est plus audacieuse et plus controversée : 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 directe : 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 un machine virtuelle de 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 à la retraite l’EVM, mais pas la supprimer — elle sera réécrite comme un contrat intelligent fonctionnant 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é changé discrètement, le volant reste le même.

Combien ces deux éléments sont-ils importants ? Vitalik a donné un chiffre : l’arbre d’état et la machine virtuelle représentent ensemble plus de 80 % du goulot d’étranglement de preuve d’Ethereum. Autrement dit, sans modifier ces deux composants, l’évolutivité d’Ethereum à l’ère ZK ne sera qu’un mouvement à vide.

Mais ce n'est pas une histoire où tout le monde hoche la tête en signe d'accord.

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 l'est pas pour servir de « 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 dans des dizaines de 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 chacune leur tâche sans interférer.

Ils ont également soulevé un risque à considérer sérieusement : les technologies dans le domaine des preuves ZK évoluent extrêmement vite, et la mise en œuvre récente de RISC-V est passée de 32 à 64 bits. Si on fixe maintenant RISC-V sur Ethereum L1, que se passera-t-il si, dans deux ans, une meilleure architecture de preuve émerge ? Parier sur une cible en mouvement rapide n’est pas dans l’esprit d’Ethereum.

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 dit à CoinDesk une phrase particulièrement juste : 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 à s’« dé-ethereumiser » activement. Jing Wang, cofondateur d’OP Labs, compare les L2 à des sites web indépendants, avec Ethereum comme 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 scénarios 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.

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 vol (reférant à The Merge), et il pourra encore en changer environ quatre fois supplémentaires — l'arbre d'état, la consensus simplifié, la vérification ZK-EVM, le remplacement de la machine virtuelle.

La mise à jour Ethereum Glamsterdam 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 l'optimisation 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 intégrale à un modèle centré sur les Rollups, elle a démontré sa capacité et son audace à démonter des moteurs à 10 000 mètres d'altitude.

Ce qu'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 claire qu'en 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 patchs et de remplacer le moteur par quel modèle, ce débat lui-même pourrait être plus précieux que la conclusion.