Les développeurs Ethereum appliquent une règle tacite : éviter l’EVM autant que possible.
Ces dernières années, lorsque de nouvelles opérations cryptographiques sont nécessaires on-chain, les développeurs préfèrent ne pas les implémenter dans l’EVM, mais sollicitent plutôt un « contrat précompilé » — un raccourci qui contourne la machine virtuelle et intègre l’opération directement dans le protocole.
Le 1er mars, Vitalik Buterin a publié un long fil sur X, rompant ouvertement avec cette règle implicite. Son argument principal : la force d’Ethereum réside dans sa généralité. Si l’EVM montre ses limites, il faut s’attaquer au problème et concevoir une machine virtuelle plus performante.
Il propose deux solutions concrètes.
Première solution : modifier la « structure de données »
La première modification concerne l’arbre d’état d’Ethereum, qui fait office de système d’indexation du registre du réseau. À chaque consultation de solde ou vérification de transaction, cet arbre est parcouru.
Le problème réside dans le fait que l’arbre actuel est trop « volumineux ». Ethereum utilise une structure appelée « hexary Keccak Merkle Patricia tree » (un nom qui évoque une formule magique). L’EIP-7864 de Vitalik propose de la remplacer par un arbre binaire plus simple.
À titre de comparaison, auparavant, interroger une donnée impliquait de choisir parmi six directions à chaque embranchement. Désormais, il ne reste plus que le choix entre la gauche ou la droite. Résultat : la longueur des branches Merkle est réduite à un quart de la taille initiale. Pour les clients légers, la bande passante nécessaire à la vérification des données diminue sensiblement.
Vitalik ne se limite pas à la refonte de l’arbre. Il souhaite également modifier la « police sur les feuilles » — la fonction de hachage. Deux candidats sont envisagés : Blake3 et Poseidon. Blake3 offre des gains de vitesse constants ; Poseidon est plus audacieux et pourrait, en théorie, décupler l’efficacité des preuves, bien que sa sécurité doive encore être auditée.
Il est important de noter que cette proposition remplace les Verkle Trees précédemment évoqués. Verkle était le principal candidat pour le hard fork de 2026, mais la cryptographie à courbes elliptiques sur laquelle il repose est vulnérable à l’informatique quantique. Depuis la mi-2024, Verkle a progressivement perdu du terrain, au profit de la solution de l’arbre binaire.
La seconde modification est encore plus ambitieuse et controversée : à long terme, remplacer l’EVM par l’architecture RISC-V.
RISC-V est un jeu d’instructions open source, initialement sans lien avec la blockchain, mais désormais utilisé en interne par la quasi-totalité des systèmes de preuve ZK. La logique de Vitalik est limpide : puisque les prouveurs utilisent déjà RISC-V, pourquoi la machine virtuelle devrait-elle fonctionner autrement et nécessiter une couche de traduction ? Supprimer cette couche améliore naturellement l’efficacité.
Un interpréteur RISC-V ne nécessite que quelques centaines de lignes de code. Pour Vitalik, c’est ce que doit être une machine virtuelle blockchain.
Son plan se décline en trois étapes : d’abord, utiliser la nouvelle machine virtuelle pour les contrats précompilés, en réécrivant 80 % des précompilés existants avec du nouveau code VM ; ensuite, permettre aux développeurs de déployer des contrats pour la nouvelle VM, fonctionnant en parallèle de l’EVM ; enfin, retirer l’EVM — non pas en la supprimant, mais en la réécrivant sous forme de contrat intelligent exécuté sur la nouvelle VM, assurant ainsi une rétrocompatibilité totale.
Les utilisateurs n’ont pas à changer de voiture : seul le moteur est discrètement remplacé, le volant restant identique.
Quelle est la portée de ces deux changements réunis ? Vitalik avance un chiffre : l’arbre d’état et la machine virtuelle représentent ensemble plus de 80 % du goulot d’étranglement des preuves sur Ethereum. Sans agir sur ces deux points, la montée en charge d’Ethereum à l’ère ZK serait compromise.
Arbitrum n’est pas d’accord : ce n’est pas parce que l’entrepôt utilise des chariots élévateurs que les livreurs doivent en conduire
Mais tout le monde n’est pas du même avis.
En novembre dernier, l’équipe principale de développement d’Arbitrum, Offchain Labs, a publié une réfutation technique détaillée. Leurs quatre chercheurs estiment que si RISC-V est bien adapté aux preuves ZK, il n’est pas pertinent comme « format de livraison » pour les contrats.
Ils introduisent une distinction essentielle : le « jeu d’instructions de livraison » (dISA) et le « jeu d’instructions de preuve » (pISA) n’ont pas à être identiques. Utiliser des chariots élévateurs dans l’entrepôt maximise l’efficacité, mais cela ne signifie pas que les livreurs doivent utiliser ces engins pour déposer les colis à domicile.
Offchain Labs préconise l’utilisation de WebAssembly (WASM) au niveau des contrats, pour des raisons solides : WASM s’exécute efficacement sur du matériel standard, et la plupart des nœuds Ethereum ne fonctionnent pas sur des puces RISC-V — imposer ce choix nécessiterait des émulateurs ; WASM offre une vérification mature de la sécurité des types ; son écosystème d’outils a fait ses preuves sur des milliards d’environnements d’exécution.
Surtout, il ne s’agit pas que d’une théorie. Offchain Labs a déjà testé un prototype sur Arbitrum : utiliser WASM comme format de livraison des contrats, puis le compiler en RISC-V pour les preuves ZK. Les deux couches fonctionnent indépendamment.
Ils soulèvent également un risque majeur : la technologie des preuves ZK évolue très vite, et récemment les implémentations RISC-V sont passées du 32 bits au 64 bits. Si RISC-V est figé dans Ethereum L1 aujourd’hui, que se passera-t-il si une meilleure architecture de preuve apparaît dans deux ans ? Miser sur une cible mouvante n’est pas dans la culture d’Ethereum.
Un contexte plus large : les L2 commencent à « s’émanciper »
Pour comprendre cette proposition, il faut adopter une perspective plus large.
Il y a un mois, Vitalik s’interrogeait publiquement : Ethereum a-t-il encore besoin d’une « feuille de route L2 dédiée » ? Ce questionnement a suscité une réaction collective de l’écosystème L2. Ben Fisch, CEO d’Espresso Systems, a déclaré à CoinDesk : selon Vitalik, les L2 étaient initialement conçus pour aider Ethereum à monter en charge, mais, à mesure qu’Ethereum accélère, leur rôle évolue naturellement.
Fait intéressant, loin de paniquer, les L2 s’engagent activement dans une « dé-Ethereumisation ». Jing Wang, cofondateur d’OP Labs, compare les L2 à des sites web indépendants, Ethereum jouant le rôle de standard ouvert de règlement. Marc Boiron, CEO de Polygon, est plus direct : le véritable enjeu n’est pas la montée en charge, mais la création d’un espace de blocs dédié à des usages concrets comme le paiement.
En somme, la refonte de la couche d’exécution par Vitalik n’est qu’une note technique dans une tendance plus large : Ethereum reprend la main sur ses capacités fondamentales, tandis que les L2 sont contraints — ou enfin capables — de trouver leur propre raison d’être.
Est-ce possible ?
Vitalik reconnaît lui-même que le remplacement de la machine virtuelle ne fait pas consensus parmi les développeurs. La réforme de l’arbre d’état est plus avancée, l’EIP-7864 disposant déjà d’un brouillon et d’une équipe dédiée. Mais remplacer l’EVM par RISC-V ? Cela reste au stade de la feuille de route, loin d’une mise en œuvre concrète.
Toutefois, la semaine dernière, Vitalik a eu cette formule marquante : Ethereum a déjà changé un moteur d’avion en plein vol (en référence à The Merge), et pourrait le faire encore quatre fois — arbre d’état, consensus simplifié, vérification ZK-EVM et remplacement de la machine virtuelle.
La mise à jour Glamsterdam d’Ethereum est attendue pour le premier semestre 2026, suivie de près par Hegota. Le contenu exact des deux hard forks n’est pas encore arrêté, mais la réforme de l’arbre d’état et l’optimisation de la couche d’exécution sont confirmées comme thèmes majeurs.
L’histoire d’Ethereum n’a jamais été une question de « faisabilité ». Du PoW au PoS, du tout L1 au Rollup-centric, la plateforme a prouvé sa capacité et son audace à démonter les moteurs en plein vol.
Cette fois, il s’agit d’aller plus loin : non pas ajouter des fonctionnalités, mais revoir entièrement les fondations. Est-ce une rénovation mûrement réfléchie ou un gouffre de complexité sans fin ? La réponse ne sera probablement pas claire avant 2027.
Une chose est certaine : Ethereum ne compte pas rester un « vieux système rafistolé » à l’ère ZK. Quant à la manière de retirer les rustines et au choix du moteur, le débat lui-même sera peut-être plus précieux que la conclusion.
Avertissement :
-
Cet article est republié de TechFlow, le droit d’auteur appartenant à l’auteur original [Gray Lobster]. Si vous avez la moindre objection à cette republication, veuillez contacter l’équipe Gate Learn, qui traitera la demande dans les meilleurs délais conformément aux procédures en vigueur.
-
Avertissement : Les opinions et points de vue exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas des conseils en investissement.
-
Les autres versions linguistiques de cet article sont traduites par l’équipe Gate Learn. Sans mention explicite de Gate, il est interdit de copier, distribuer ou plagier les articles traduits.
