Ethereum va changer de moteur
TechFlow SélectionTechFlow Sélection
Ethereum va changer de moteur
Cette fois, il s’agit de toucher à des éléments encore plus fondamentaux : pas simplement d’ajouter de nouvelles fonctionnalités, mais de démolir les anciennes fondations pour les reconstruire entièrement.
Dédié à des analyses Web3 approfondiesRédaction : Homard Gris, TechFlow
Les développeurs d’Ethereum partagent une habitude tacite : éviter autant que possible de toucher à la Machine Virtuelle Ethereum (EVM).
Ces 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 directement dans l’EVM, mais plutôt de demander l’ajout d’un « contrat précompilé » — un raccourci codé en dur au niveau du protocole, contournant entièrement la machine virtuelle.
Le 1er mars, Vitalik Buterin a publié sur X un long fil qui a définitivement mis à nu cette réalité. Il y déclare notamment : « L’essence même d’Ethereum réside dans sa généralité ; si l’EVM n’est pas suffisamment performante, alors nous devons résoudre ce problème frontalement, en concevant une meilleure machine virtuelle. »
Il propose deux leviers concrets d’intervention.
Premier levier : remplacer la « structure de données »
La première modification concerne l’arbre d’état d’Ethereum, que l’on peut assimiler à son « système d’indexation comptable » : chaque consultation de solde ou vérification de transaction implique de parcourir cet arbre.
Le problème ? Cet arbre est actuellement trop « volumineux ». Ethereum utilise une structure appelée « arbre de Merkle-Patricia à six branches basé sur Keccak » — un nom aussi intimidant qu’un sortilège. La proposition EIP-7864, avancée par Vitalik, vise à le remplacer par un arbre binaire plus simple.
Prenons une analogie : auparavant, pour retrouver une donnée, vous deviez constamment choisir une direction parmi six possibilités à chaque carrefour ; désormais, vous n’avez plus que deux choix possibles : gauche ou droite. Résultat ? La longueur des branches de Merkle est réduite à un quart de sa valeur initiale. Pour les clients légers, la bande passante nécessaire à la vérification des données diminue fortement.
Mais Vitalik ne se contente pas de changer la forme de l’arbre : il souhaite également modifier la « police inscrite sur les feuilles », c’est-à-dire la fonction de hachage. Deux candidats sont envisagés : Blake3 et Poseidon. Blake3 permettrait un gain de performance stable ; Poseidon est plus radical, offrant théoriquement un accroissement de plusieurs dizaines de fois de l’efficacité des preuves, mais nécessite encore davantage d’audits en matière de sécurité.
À noter que cette proposition remplace en fait les arbres Verkle, longuement discutés par la communauté ces dernières années. Ces derniers figuraient initialement comme solution privilégiée pour le hard fork prévu en 2026, mais ont progressivement perdu de leur attrait depuis le milieu de l’année 2024, en raison des menaces potentielles posées par l’informatique quantique sur la cryptographie elliptique sous-jacente. Le scénario de l’arbre binaire a ainsi pris le relais.
Deuxième levier : remplacer la « machine virtuelle », transformant l’EVM en un simple contrat intelligent
La deuxième modification est encore plus audacieuse — et plus controversée : remplacer progressivement l’EVM par une architecture RISC-V.
RISC-V est un jeu d’instructions open source, initialement sans lien avec la blockchain, mais désormais utilisé par pratiquement tous les systèmes de preuve ZK. Le raisonnement de Vitalik est limpide : puisque les générateurs de preuves utilisent déjà le langage RISC-V, pourquoi la machine virtuelle devrait-elle parler un autre langage, nécessitant ensuite une couche de traduction intermédiaire ? En supprimant cette couche, l’efficacité s’améliore naturellement.
Un interpréteur RISC-V ne nécessite que quelques centaines de lignes de code. Selon Vitalik, c’est là précisément ce à quoi devrait ressembler une machine virtuelle blockchain.
Il propose une stratégie en trois étapes : premièrement, exécuter les contrats précompilés sur la nouvelle machine virtuelle, en réécrivant sous ce nouveau format environ 80 % des précompilés existants ; deuxièmement, autoriser les développeurs à déployer directement des contrats compatibles avec la nouvelle machine virtuelle, en parallèle avec l’EVM ; troisièmement, retirer progressivement l’EVM — non pas en la supprimant, mais en la réécrivant comme un contrat intelligent s’exécutant sur la nouvelle machine virtuelle, garantissant ainsi une compatibilité descendante complète.
L’ancien propriétaire n’a pas besoin de changer de voiture. Seul le moteur est silencieusement remplacé, tandis que le volant reste exactement le même.
L’importance combinée de ces deux changements est considérable. Vitalik fournit un chiffre clé : l’arbre d’état et la machine virtuelle représentent collectivement plus de 80 % du goulot d’étranglement des preuves sur Ethereum. Autrement dit, sans toucher à ces deux composants, toute tentative de mise à l’échelle d’Ethereum à l’ère ZK resterait purement statique.
Arbitrum désapprouve : « Vous ne pouvez pas imposer aux livreurs de conduire des chariots élévateurs simplement parce que votre entrepôt en utilise »
Mais cette initiative ne fait pas l’unanimité.
En novembre dernier, l’équipe de développement principale d’Arbitrum, Offchain Labs, a publié une réfutation technique détaillée. Les quatre chercheurs soulignent que, bien que RISC-V convienne effectivement aux preuves ZK, il n’est pas adapté au rôle de « format de livraison » des contrats intelligents.
Ils établissent une distinction fondamentale : le « jeu d’instructions de livraison » (dISA) et le « jeu d’instructions de preuve » (pISA) n’ont pas besoin d’être identiques. Si les chariots élévateurs sont les plus efficaces pour déplacer des marchandises dans un entrepôt, cela ne signifie pas que les livreurs doivent conduire des chariots élévateurs jusqu’à votre porte.
Offchain Labs plaide pour l’adoption de WebAssembly (WASM) au niveau des contrats, pour des motifs solides : WASM offre une excellente efficacité d’exécution sur le matériel standard, or la plupart des nœuds Ethereum ne tournent pas sur des puces RISC-V — un passage forcé vers RISC-V impliquerait donc l’usage d’un émulateur ; WASM bénéficie d’un mécanisme éprouvé de vérification de sécurité typée ; enfin, son écosystème d’outils a été testé dans des milliards d’environnements d’exécution réels.
Plus important encore, ils ne se contentent pas de théorie : Offchain Labs a déjà déployé avec succès un prototype sur Arbitrum, utilisant WASM comme format de livraison des contrats, puis les compilant en RISC-V pour les preuves ZK. Chaque couche assume pleinement ses responsabilités, sans interférence.
Ils soulèvent également un risque méritant réflexion : le domaine des preuves ZK évolue extrêmement vite — récemment, les implémentations RISC-V sont ainsi passées du 32 bits au 64 bits. Si RISC-V était aujourd’hui verrouillé au niveau de la couche 1 d’Ethereum, que se passerait-il si une architecture de preuve supérieure apparaissait dans deux ans ? Parier sur une cible en mouvement rapide n’est pas dans l’esprit d’Ethereum.
Un contexte plus large : les L2 commencent à « se sevrer »
Pour bien comprendre cette proposition, il faut aussi prendre en compte un cadre macroéconomique plus large.
Il y a tout juste un mois, Vitalik a publiquement remis en question la nécessité, pour Ethereum, d’avoir une « feuille de route spécifique aux L2 », déclenchant une réponse collective de l’écosystème L2. Ben Fisch, PDG d’Espresso Systems, a résumé la pensée de Vitalik auprès de CoinDesk : « Ce que Vitalik veut dire, c’est que l’objectif initial des L2 était d’aider Ethereum à s’élargir — or, si Ethereum lui-même devient plus rapide, la place occupée par les L2 doit nécessairement évoluer. »
Fait intéressant, loin de paniquer, les L2 commencent activement à « se déconnecter d’Ethereum ». Jing Wang, cofondateur d’OP Labs, compare les L2 à des sites web indépendants, Ethereum constituant alors la norme ouverte de règlement sous-jacente. Marc Boiron, PDG de Polygon, va encore plus loin : « Le véritable défi n’est pas la mise à l’échelle, mais la création d’un espace de blocs sur mesure pour des cas d’usage réels tels que les paiements. »
Autrement dit, cette refonte majeure de la couche d’exécution proposée par Vitalik constitue une note technique illustrant une tendance plus vaste : Ethereum reprend progressivement le contrôle de ses capacités fondamentales, tandis que les L2 trouvent — de façon forcée ou finalement libérée — leur propre justification d’existence indépendante.
Cette initiative aboutira-t-elle ?
Vitalik reconnaît lui-même que le remplacement de la machine virtuelle ne bénéficie pas encore d’un large consensus au sein de la communauté des développeurs. En revanche, la réforme de l’arbre d’état est plus avancée : l’EIP-7864 dispose déjà d’un projet détaillé et d’une équipe chargée de sa mise en œuvre. Quant au remplacement de l’EVM par RISC-V ? Celui-ci demeure à ce stade une simple « ligne directrice stratégique », loin d’être intégré au code.
Cela dit, Vitalik a récemment formulé une déclaration remarquable : Ethereum a déjà changé un moteur à réaction en plein vol (c’est-à-dire The Merge), et pourrait encore en remplacer environ quatre autres : l’arbre d’état, la simplification du consensus, la vérification ZK-EVM, et le remplacement de la machine virtuelle.
L’activation de la mise à niveau « Glamsterdam » est prévue pour le premier semestre 2026, suivie de près par « Hegota ». Les contenus précis de ces deux hard forks ne sont pas encore définitivement arrêtés, mais la réforme de l’arbre d’état et l’optimisation de la couche d’exécution figurent incontestablement parmi les axes centraux.
L’histoire d’Ethereum n’a jamais été celle d’un « peut-on ou non ? ». Du passage du PoW au PoS, de la stratégie « tout sur la couche 1 » à celle centrée sur les Rollups, Ethereum a prouvé qu’il possède à la fois la capacité et le courage de démonter ses moteurs à dix mille mètres d’altitude.
Cette fois, il s’agit d’opérer plus profondément encore — non pas d’ajouter de nouvelles fonctionnalités, mais de creuser les fondations anciennes pour les refaire entièrement. S’agit-il d’une rénovation soigneusement planifiée, ou d’un gouffre sans fond rendu de plus en plus complexe à mesure qu’on y travaille ? La réponse ne viendra probablement qu’en 2027.
Mais une chose est certaine : Ethereum ne compte pas jouer, à l’ère ZK, le rôle d’un « vieux système bourré de correctifs ». Quant à savoir comment démonter ces correctifs, ou quel modèle de moteur adopter, le débat lui-même pourrait bien avoir plus de valeur que sa conclusion finale.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
深潮TechFlow
