Vitalik Proclame la Transformation Radicale de l'EVM et de l'Arborescence d'État d'Ethereum à Venir

Les semaines précédentes ont suscité de profondes discussions au sein de la communauté Ethereum sur la partie la plus critique de l’architecture blockchain. Au premier trimestre 2025, Vitalik Buterin a publié une analyse approfondie sur la manière dont Ethereum doit être fondamentalement modifié. Sa thèse est claire : l’EVM et la structure de l’arbre d’état ne suffisent pas pour l’avenir d’Ethereum à l’ère des preuves à zéro connaissance. La communauté de développeurs professionnels a réagi à divers niveaux — allant du soutien à un rejet direct des propositions principales.

Pourquoi faut-il changer l’EVM ? La grande goulot d’étranglement des performances

Pour comprendre l’urgence de ces changements, il faut d’abord identifier où se situe le problème. Depuis plus de dix ans, l’EVM (Machine Virtuelle Ethereum) est le centre névralgique de l’écosystème Ethereum. Mais à mesure que le réseau grandit et que des technologies avancées comme les ZK proofs émergent, ses limitations deviennent plus évidentes.

Vitalik a fourni un diagnostic concret : l’arbre d’état et l’architecture de la machine virtuelle représentent plus de 80 % du goulot d’étranglement computationnel pour les preuves de la blockchain. En d’autres termes, même si d’autres parties du système sont performantes, si ces deux éléments ne sont pas améliorés, Ethereum ne pourra pas évoluer efficacement dans le futur. C’est comme essayer d’accélérer une voiture dont le moteur reste lourd et obsolète.

Deux étapes principales : refonte structurelle de l’arbre d’état et remplacement complet de l’EVM

Vitalik propose deux solutions interconnectées, qui ne doivent pas être considérées séparément. Chacune cible un aspect différent du problème de performance.

La première étape : remplacement de l’arbre d’état par une structure binaire

Actuellement, Ethereum utilise une structure complexe appelée « arbre de Merkle Patricia hexary Keccak » — un nom qui reflète sa complexité. La proposition EIP-7864 vise à la simplifier en utilisant une structure d’arbre binaire.

L’impact pratique est significatif. Dans le système actuel, pour identifier une transaction ou un solde précis, il faut faire plusieurs choix à chaque niveau de l’arbre — six directions possibles à chaque nœud. Avec une approche binaire, il n’y a que deux options : gauche ou droite. Résultat : la longueur de la branche Merkle diminue jusqu’à quatre fois.

Pour les clients légers et systèmes de vérification distribuée, c’est révolutionnaire. La bande passante nécessaire pour vérifier les données diminue considérablement. Pour l’utilisateur final, cela signifie une vérification plus rapide des transactions et un coût computationnel réduit.

Mais Vitalik ne s’arrête pas là. La proposition inclut aussi un changement de fonction de hachage — le « style » de la computation, si l’on veut. Deux candidats : Blake3 et Poseidon. Blake3 offre des améliorations de performance constantes. Poseidon adopte une approche plus agressive, pouvant théoriquement augmenter l’efficacité des preuves d’une dizaine de fois — mais nécessite encore plus d’audits de sécurité avant adoption.

Ce choix indique indirectement que Ethereum a abandonné l’approche des arbres Verkle, longtemps discutée par la communauté. En 2024, la menace de l’informatique quantique sur la cryptographie à courbe elliptique a réduit l’appétit pour la solution Verkle, rendant la structure d’arbre binaire plus populaire.

La deuxième étape : migration de l’EVM vers l’architecture RISC-V

La seconde proposition est plus ambitieuse et controversée : remplacer à long terme l’EVM par une architecture d’instructions RISC-V.

RISC-V est un ensemble d’instructions open-source, écoénergétique, issu de la recherche académique, qui est devenu la norme dans tous les systèmes de preuves à zéro connaissance. La logique de Vitalik est élégante : si les générateurs de preuves ZK parlent RISC-V, pourquoi la machine virtuelle blockchain ne pourrait-elle pas aussi ? En supprimant cette couche de traduction, l’efficacité augmenterait immédiatement.

L’implémentation technique n’est pas aussi compliquée qu’on pourrait le penser. Un interpréteur RISC-V peut être codé en quelques centaines de lignes. Pour Vitalik, c’est la philosophie de conception adaptée à la blockchain : simplicité orientée performance.

Le plan de transition se décompose en trois phases :

1. Utiliser la machine virtuelle RISC-V pour exécuter les contrats précompilés. 80 % des contrats précompilés existants peuvent être réécrits en code RISC-V.

2. Permettre aux développeurs de déployer directement des contrats avec cette nouvelle VM. Le nouveau système et l’EVM fonctionneront en parallèle, permettant une migration progressive.

3. Finalement, supprimer l’EVM — mais sans la supprimer complètement. Elle sera convertie en un contrat intelligent s’exécutant sur la VM RISC-V, garantissant une compatibilité rétroactive totale. La vision de Vitalik est poétique : le volant reste le même pour le conducteur, mais le moteur en dessous a été silencieusement remplacé.

Le goulot d’étranglement de production : sans changement de l’EVM, pas de scalabilité

L’argument central repose sur un chiffre : 80 %. C’est la part du goulot d’étranglement des preuves d’Ethereum directement liée à l’arbre d’état et à l’architecture de la machine virtuelle. En pratique, cela signifie que toutes les autres optimisations ont un effet limité si ces deux éléments ne sont pas améliorés.

À l’ère de la scalabilité ZK, cette limitation architecturale deviendra un frein majeur. Ethereum voit sa nécessité d’évoluer au-delà d’améliorations ponctuelles.

La contre-proposition : le défi d’Arbitrum face à la stratégie RISC-V

Mais l’histoire n’est pas simplement une question de consensus. En novembre dernier, l’équipe Offchain Labs — principaux développeurs d’Arbitrum — a publié une réfutation technique détaillée.

Leur observation principale est nuancée et importante : oui, RISC-V est idéal pour les preuves ZK, mais il ne doit pas devenir le « format d’exécution » pour les contrats intelligents. Ils établissent une distinction critique : « instruction set de livraison » (dISA) et « instruction set de preuve » (pISA) ne doivent pas nécessairement être identiques.

L’analogie est pratique : un entrepôt fonctionne à haute efficacité avec un chariot élévateur, mais cela ne signifie pas que le livreur doit aussi utiliser ce même chariot pour livrer le colis à votre porte. Chaque outil a son contexte approprié.

Pour l’exécution des contrats, Offchain Labs recommande WebAssembly (WASM) comme meilleure solution. Leur raisonnement technique est solide :

• WASM a une efficacité prouvée sur le matériel standard. La majorité des nœuds Ethereum ne tournent pas sur des puces RISC-V spécialisées, et l’émulation représenterait une surcharge importante.

• WASM dispose d’un mécanisme de vérification typée mature, prouvé dans des millions d’environnements d’exécution à travers le monde.

• L’écosystème d’outils WASM est établi, avec un support développeur étendu.

Plus important encore, ils ne se contentent pas de théoriser. Offchain Labs a déjà développé une implémentation prototype sur Arbitrum : utiliser WASM comme format de livraison de contrat, puis le compiler en RISC-V pour les preuves ZK. Chaque couche effectue sa tâche spécialisée sans conflit.

Ils soulignent aussi un risque critique : la technologie ZK évolue rapidement. La mise en œuvre RISC-V a évolué de 32 bits à 64 bits ces dernières années. Si l’on verrouille RISC-V maintenant au niveau Ethereum L1, que faire si une architecture de preuve supérieure apparaît dans deux ans ? Miser sur une cible mouvante n’est pas la philosophie d’Ethereum.

La grande mutation industrielle : Ethereum et Layer 2 s’éloignent

Pour bien comprendre le contexte de ce débat technique, il faut analyser la dynamique industrielle plus large.

Il y a peu, Vitalik a exprimé du scepticisme quant à la nécessité d’une « feuille de route L2 dédiée pour Ethereum ». Cela a suscité une réponse réflexive profonde de la part des opérateurs Layer 2.

Ben Fisch, CEO d’Espresso Systems, a expliqué aux médias : l’objectif initial des Layer 2 était d’aider Ethereum à scaler. Mais maintenant qu Ethereum poursuit ses propres améliorations de scalabilité, le positionnement des Layer 2 doit évoluer. Ce n’est plus seulement une couche auxiliaire, mais un écosystème plus indépendant.

Les opérateurs Layer 2 ne paniquent pas. Au contraire, ils se repositionnent activement. Le co-fondateur d’OP Labs décrit les Layer 2 comme des « sites web indépendants », tandis qu’Ethereum reste la norme de règlement périodique. Le CEO de Polygon est plus direct : le vrai défi n’est pas seulement le scaling, mais la création d’un espace de bloc spécifique pour des cas d’usage réels — comme l’infrastructure de paiement.

En d’autres termes, cette grande mutation technique dans la couche d’exécution d’Ethereum reflète une tendance structurelle plus large : Ethereum revient sous le contrôle de ses compétences clés, tandis que Layer 2 s’oriente vers une autonomie accrue ou découvre sa propre raison d’être.

La réalité : le chemin à suivre et les défis

Vitalik lui-même admet qu’il n’y a pas encore de consensus large parmi les développeurs sur le remplacement de l’EVM. La réforme de l’arbre d’état est plus avancée — l’EIP-7864 dispose d’un brouillon concret et d’équipes de développement actives.

Mais le remplacement RISC-V de l’EVM ? Il en est encore au stade de la « roadmap », loin d’un code opérationnel.

Cependant, Vitalik a rassuré la communauté la semaine dernière : Ethereum a déjà effectué un changement de moteur lors du « Merge ». Il peut encore réaliser quatre autres changements majeurs — optimisation de l’arbre d’état, consensus simplifié, vérification ZK-EVM, et remplacement de la machine virtuelle.

Le calendrier commence à se dessiner. Ethereum vise la mise à jour Glamsterdam pour la première moitié de 2026, suivie de Hegota. Les détails techniques sont encore en finalisation, mais la réforme de l’arbre d’état et l’amélioration de la couche d’exécution sont confirmées comme directions principales.

La question n’est pas « possible ou non ». Ethereum a maintes fois prouvé sa capacité — du PoW au PoS, de l’écosystème tout-en-L1 à l’écosystème axé sur les Rollups. Le vrai défi est architectural, pas cosmétique. Il s’agit de reconstruire la fondation tout en maintenant la plateforme opérationnelle — pas seulement ajouter des fonctionnalités, mais remplacer fondamentalement l’ancienne architecture.

Le débat technique — si ces changements sont vraiment bénéfiques ou s’ils mènent à une complexité sans fin — pourrait être plus précieux que la résolution finale. Ethereum a décidé consciemment de ne pas devenir un « système hérité patché » à l’ère ZK. La façon de casser les pièces du moteur et le nouveau modèle qui en découlera ne seront visibles qu’en 2027.