Ethereum va changer de moteur

Rédaction : Dragon Gris, Deep Tide TechFlow

Les développeurs Ethereum ont une habitude tacite : s’ils peuvent éviter d’utiliser l’EVM, ils l’éviteront.

Au cours des 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 rapide pour contourner la machine virtuelle en la codant directement au niveau du protocole.

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

Il a proposé deux interventions concrètes.

Première intervention : changer la “structure de données”

Ce premier changement concerne l’arbre d’état d’Ethereum. On peut le voir comme le “système d’indexation du registre” d’Ethereum, où chaque vérification de solde ou transaction nécessite de parcourir cet arbre.

Le problème, c’est que cet arbre est devenu trop “gros”. Ethereum utilise une structure appelée “Merkle Patricia Tree à six branches” (un nom qui ressemble à un sortilège). La proposition d’Vitalik, l’EIP-7864, consiste à le remplacer par un arbre binaire plus simple.

Pour illustrer : auparavant, vérifier une donnée nécessitait de choisir une direction à chaque bifurcation dans un carrefour à six branches. Maintenant, il n’y a plus qu’à aller à gauche ou à droite. Résultat : la longueur des branches Merkle est réduite à un quart de l’original. Pour les clients légers, cela réduit considérablement la bande passante nécessaire pour la vérification.

Mais Vitalik ne se contente pas de changer 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 augmenter l’efficacité des preuves de dizaines de fois, mais sa sécurité nécessite encore plus d’audits.

Il est à noter que cette solution remplace en fait les Verkle Trees, qui étaient la principale option de bifurcation prévue pour 2026. Ces arbres ont perdu de leur popularité depuis que leur cryptographie elliptique sous-jacente est menacée par l’avènement de l’ordinateur quantique, à partir de mi-2024, laissant la place à la solution binaire.

Deuxième intervention : changer la “machine virtuelle”, transformer l’EVM en un contrat intelligent

Ce second changement est plus audacieux et plus 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 preuve ZK. La logique de Vitalik est simple : puisque le générateur de preuve parle déjà le langage RISC-V, pourquoi continuer à utiliser une autre machine virtuelle, puis faire une traduction ? En supprimant cette couche de traduction, l’efficacité augmenterait naturellement.

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

Il prévoit trois étapes : d’abord, faire fonctionner les contrats précompilés avec la nouvelle VM, en réécrivant 80 % des contrats existants ; ensuite, permettre aux développeurs de déployer directement des contrats sur la nouvelle VM, en parallèle avec l’EVM ; enfin, retirer l’EVM, mais sans la faire disparaître — elle sera réécrite en un contrat intelligent fonctionnant sur la nouvelle VM, assurant une compatibilité totale.

Les utilisateurs n’ont pas besoin de changer de “voiture”. Seul le moteur change discrètement, le volant reste le même.

Quelle importance ont ces deux changements ? Vitalik donne un chiffre : la structure d’état et la machine virtuelle représentent ensemble plus de 80 % du goulot d’étranglement des preuves d’Ethereum. En d’autres termes, si ces deux aspects ne sont pas modifiés, la scalabilité d’Ethereum à l’ère ZK stagnera.

Arbitrum n’est pas d’accord : ce n’est pas parce qu’un entrepôt utilise un chariot élévateur que le livreur doit aussi en utiliser un.

Mais ce n’est pas un récit unanimement accepté.

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

Ils proposent une distinction clé : “ensemble d’instructions de livraison” (dISA) et “ensemble d’instructions de preuve” (pISA) n’ont pas besoin d’être identiques. Utiliser un chariot pour transporter efficacement, ne signifie pas que le livreur doit aussi conduire.

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 des mécanismes de vérification de sécurité éprouvés ; son écosystème d’outils a été testé dans des milliards d’environnements.

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

Ils soulèvent aussi un risque important : le domaine des preuves ZK évolue très rapidement. Récemment, la mise en œuvre de RISC-V est passée de 32 bits à 64 bits. Si l’on “fixe” RISC-V sur Ethereum L1 maintenant, que se passera-t-il dans deux ans si une architecture de preuve meilleure apparaît ? Miser sur une cible en mouvement rapide n’est pas dans l’esprit d’Ethereum.

Un contexte plus large : les L2 commencent à “se sevrer”

Pour comprendre cette proposition, il faut aussi prendre du recul.

Il y a un mois, Vitalik a publiquement remis en question la nécessité d’une “feuille de route spécifique pour les L2”, ce qui a suscité une réponse collective de la part de la communauté L2. Ben Fisch, CEO d’Espresso Systems, a déclaré à CoinDesk : en fait, Vitalik veut dire que l’objectif initial des L2 était d’augmenter la scalabilité d’Ethereum. Maintenant qu Ethereum devient plus rapide, leur rôle doit évoluer.

Fait intéressant, les L2 ne paniquent pas, mais commencent à “se dé-ethereumiser”. Jing Wang, co-fondateur d’OP Labs, compare les L2 à des sites indépendants, Ethereum étant la norme d’ensemble pour le règlement. Marc Boiron, CEO de Polygon, explique plus franchement : le vrai défi n’est pas la scalabilité, mais de créer un espace de bloc dédié pour des cas réels comme le paiement.

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, par nécessité ou par choix, trouvent leur propre raison d’exister.

Cela peut-il réussir ?

Vitalik lui-même admet que le remplacement de la machine virtuelle n’a pas encore reçu un consensus large dans la communauté des développeurs. La réforme de la structure d’état est plus avancée, avec un brouillon 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 une fois lors du “The Merge” (fusion), et pourra en changer encore environ quatre fois — la structure d’état, la simplification du consensus, la vérification ZK-EVM, et le remplacement de la VM.

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

L’histoire d’Ethereum n’a jamais été une question de “peut-on” ou “pas”. Du PoW au PoS, du tout en L1 au rôle central des Rollups, il a toujours prouvé sa capacité et son audace à démonter ses moteurs en altitude.

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

Mais une chose est sûre : Ethereum ne compte pas rester un " vieux système patché" à l’ère ZK. Quant à la façon de faire les réparations ou de changer de moteur, cette discussion, peut-être plus que la conclusion, en vaut la peine.