Adieu EVM ? Vitalik veut réaliser une « opération du cœur » pour Ethereum

Auteur : Gris Crustacé, Deep Tide TechFlow

Les développeurs d’Ethereum ont une habitude tacite : si possible, ils évitent de toucher à l’EVM.

Ces dernières années, chaque fois qu’une nouvelle opération cryptographique était nécessaire sur la chaîne, leur première réaction n’était pas de l’implémenter dans l’EVM, mais de demander l’ajout d’un “contrat précompilé”, une solution de contournement qui évite la machine virtuelle en codant directement dans le protocole.

Le 1er mars, Vitalik Buterin a publié un long message sur X, brisant cette barrière. Son propos principal : la véritable valeur d’Ethereum réside dans sa flexibilité. Si l’EVM n’est pas suffisant, il faut le remplacer par une machine virtuelle meilleure.

Il a proposé deux axes concrets d’amélioration.

Premier axe : changer la “structure de données”

Ce premier changement concerne l’état d’Ethereum. On peut le voir comme le “système d’indexation du registre” d’Ethereum, qui doit parcourir un arbre pour vérifier les soldes ou valider une transaction.

Le problème, c’est que cet arbre est aujourd’hui trop “gros”. Ethereum utilise une structure appelée “Merkle Patricia Tree à six branches” (un nom qui ressemble à une formule magique). Vitalik propose dans l’EIP-7864 de le remplacer par un arbre binaire plus simple.

Pour faire une analogie : auparavant, pour vérifier une donnée, il fallait suivre un chemin dans un arbre à six branches, maintenant ce chemin ne comporte plus que deux options (gauche ou droite). Résultat : la longueur des branches Merkle est réduite d’un quart. Pour les clients légers, cela signifie une réduction significative de la bande passante nécessaire pour la vérification.

Mais Vitalik ne veut pas s’arrêter à la simple modification de la forme de l’arbre. Il veut aussi changer “l’écriture sur les feuilles”, c’est-à-dire la fonction de hachage. Deux options sont envisagées : Blake3 et Poseidon.

• Blake3 offre une vitesse stable ;
• Poseidon, plus radicale, pourrait théoriquement multiplier par dizaines l’efficacité des preuves, mais sa sécurité nécessite encore plus d’audits.

Il est à noter que cette proposition remplace en fait les Verkle Trees, qui étaient la solution privilégiée pour la hard fork de 2026. Ces arbres, dépendant de la cryptographie elliptique, ont perdu leur attrait depuis le milieu de 2024 face à la menace des ordinateurs quantiques, laissant la place à la solution binaire.

Deuxième axe : changer la “machine virtuelle”, faire de l’EVM un contrat intelligent

Ce second changement est plus audacieux et controversé : remplacer à long terme l’EVM par une architecture RISC-V.

RISC-V est un ensemble d’instructions open source, initialement sans lien avec la blockchain, mais aujourd’hui utilisé dans presque tous les systèmes de preuves ZK. La logique de Vitalik est simple : puisque les générateurs de preuves utilisent déjà RISC-V comme langage, pourquoi continuer à faire une traduction via une machine virtuelle ? En supprimant cette couche intermédiaire, l’efficacité augmenterait.

Un interpréteur RISC-V ne nécessite que quelques centaines de lignes de code. Vitalik affirme que c’est ainsi que devrait fonctionner une machine virtuelle blockchain.

Il prévoit trois étapes : d’abord, faire tourner les contrats précompilés sur cette nouvelle VM, en réécrivant 80 % d’entre eux ; ensuite, permettre aux développeurs de déployer directement des contrats sur cette VM, en parallèle avec l’EVM ; enfin, déprécier l’EVM, mais sans la supprimer : elle sera réécrite en contrat intelligent tournant sur la nouvelle VM, garantissant une compatibilité totale.

Les utilisateurs n’auront pas besoin de changer d’outil. Seul le moteur change discrètement, le reste reste identique.

Combiner ces deux changements est crucial, selon Vitalik : l’état de l’arbre et la machine virtuelle représentent plus de 80 % du goulot d’étranglement pour la preuve sur Ethereum. Sans les faire évoluer, la scalabilité dans l’ère ZK stagnera.

Arbitrum n’est pas d’accord : on ne peut pas faire conduire un livreur en chariot élévateur parce que l’entrepôt l’utilise

Mais cette vision n’est pas unanimement acceptée.

En novembre dernier, l’équipe principale d’Arbitrum, Offchain Labs, a publié une réfutation technique détaillée. Quatre chercheurs y expliquent que : RISC-V est adapté pour la preuve ZK, mais pas pour la “format de livraison” des contrats.

Ils proposent une distinction essentielle : “Instruction Set de livraison” (dISA) et “Instruction Set de preuve” (pISA) n’ont pas besoin d’être identiques. Utiliser un chariot dans l’entrepôt ne signifie pas que le livreur doit aussi en conduire un jusqu’à votre porte.

Offchain Labs recommande d’utiliser WebAssembly (WASM) pour la couche de contrats, avec des arguments solides : WASM est efficace sur du matériel standard, alors que la majorité des nœuds Ethereum ne disposent pas de processeurs RISC-V, ce qui nécessiterait un émulateur ; WASM possède une vérification de sécurité intégrée ; son écosystème d’outils est éprouvé dans des milliards d’environnements.

Plus important encore, ils ne se contentent pas de paroles : ils ont déjà testé un prototype sur Arbitrum, utilisant WASM comme format de livraison, puis le compilant en RISC-V pour la preuve ZK. Les deux couches fonctionnent indépendamment.

Ils soulèvent aussi un risque : la technologie ZK évolue rapidement, et récemment, la mise en œuvre de RISC-V est passée de 32 bits à 64 bits. Si on “fixe” RISC-V dans Ethereum aujourd’hui, que se passera-t-il si une architecture meilleure apparaît dans deux ans ? Miser sur une cible aussi mouvante n’est pas dans l’esprit d’Ethereum.

Un contexte plus large : les L2 commencent à “se détacher”

Pour comprendre cette proposition, il faut prendre du recul.

Il y a un mois, Vitalik a remis en question la nécessité d’un “plan de route dédié aux L2”, ce qui a suscité une réponse collective de la communauté L2. Ben Fisch, CEO d’Espresso Systems, a résumé : l’objectif initial des L2 était d’étendre Ethereum, mais maintenant qu Ethereum devient plus rapide, leur rôle doit évoluer.

Fait intéressant, les L2 ne paniquent pas, mais cherchent à “se dé-ethereumiser”. Jing Wang, co-fondateur d’OP Labs, compare les L2 à des sites indépendants, Ethereum étant la norme de règlement sous-jacente. Marc Boiron, CEO de Polygon, va plus loin : le vrai défi n’est pas la scalabilité, mais la création d’un espace de bloc dédié pour des paiements et autres cas d’usage réels.

En résumé, cette grande réforme de l’exécution par Vitalik s’inscrit dans une tendance plus large : Ethereum reprend le contrôle de ses capacités fondamentales, tandis que les L2 cherchent ou trouvent leur propre raison d’être.

Est-ce que cela peut fonctionner ?

Vitalik lui-même admet que : le remplacement de la machine virtuelle n’a pas encore obtenu un large consensus dans la communauté. La réforme de l’état est plus avancée, avec un projet d’EIP-7864 et une équipe dédiée. Mais le remplacement de l’EVM par RISC-V ? Cela reste au stade de la “feuille de route”, loin d’être codé.

Cependant, Vitalik a récemment exprimé une position impressionnante : Ethereum a déjà changé de moteur à réaction une fois (avec The Merge), et peut en changer encore environ quatre fois — l’état de l’arbre, la simplification du consensus, la vérification ZK-EVM, et le remplacement de la VM.

La mise à jour Glamsterdam est prévue pour le premier semestre 2026, suivie de Hegota. Les détails précis de ces hard forks ne sont pas encore finalisés, mais la réforme de l’état et l’optimisation de l’exécution restent les axes principaux.

L’histoire d’Ethereum n’a jamais été une question de “peut-on” ou “doit-on”. Du PoW au PoS, de l’optimisation L1 à la montée en puissance des Rollups, il a toujours montré sa capacité à démonter et remonter ses moteurs à haute altitude.

Ce qui se prépare, c’est une modification plus profonde — pas l’ajout de nouvelles fonctionnalités, mais la réouverture et la refonte de ses fondations. S’agit-il d’une rénovation stratégique ou d’un gouffre sans fin ? La réponse ne sera claire qu’en 2027.

Mais une chose est sûre : Ethereum ne compte pas rester un " vieux système patché " à l’ère ZK. Quant à savoir comment déployer les patchs ou quel moteur remplacer, cette discussion, peut-être plus que la conclusion, en vaut la peine.