J'ai récemment remarqué que Vitalik Buterin a commencé à parler franchement d'un problème que les développeurs d'Ethereum ont longtemps ignoré : la dépendance excessive aux solutions de contournement plutôt qu'à la correction des fondations. En réalité, les développeurs évitaient d'améliorer la machine virtuelle EVM, préférant ajouter des "contrats préfabriqués" chaque fois qu'une nouvelle opération cryptographique était nécessaire. Mais Vitalik a finalement décidé d'aborder ce problème directement.

Le plan comprend deux modifications radicales. La première concerne l'arbre d'état d'Ethereum - considérez-le comme le système d'indexation du réseau. Le problème est qu'il est devenu "gourmand" en raison de sa structure actuelle. Vitalik propose de le remplacer par un arbre binaire plus simple selon l'EIP-7864. Le résultat ? La longueur d'une branche de Merkle sera réduite à un quart de sa taille originale, ce qui signifie une réduction significative des exigences en bande passante pour les clients légers.

Mais la partie la plus audacieuse est la deuxième : remplacer l'EVM par RISC-V à long terme. RISC-V est un ensemble d'instructions open source déjà utilisé dans la majorité des systèmes de preuve ZK. La logique est simple : pourquoi utiliser une machine virtuelle avec un langage différent et ajouter une couche de traduction entre elles ? Supprimer cette couche améliorera automatiquement l'efficacité.

Le plan avance en trois étapes : d'abord, exécuter les contrats préfabriqués sur une nouvelle machine et en réécrire 80 % ; deuxièmement, permettre aux développeurs de déployer de nouveaux contrats directement, avec une exécution parallèle à l'ancien EVM ; troisièmement, mettre fin à l'EVM mais en le réécrivant comme un contrat intelligent - pas besoin de changer les anciens nœuds, seul le moteur change.

Vitalik a donné un chiffre important : l'arbre d'état et la machine virtuelle représentent ensemble plus de 80 % de l'obstacle à la preuve. Sans ces changements, l'expansion à l'ère ZK ne serait qu'une rotation sur place.

Mais tout le monde n'est pas d'accord. L'équipe d'Offchain Labs (Arbitrum) a publié une réponse technique détaillée s'opposant à l'idée de faire de RISC-V une norme unifiée. Leur avis : RISC-V est bon pour les preuves, mais pas adapté comme "format de livraison" pour les contrats. Ils proposent WebAssembly (WASM) à la place - efficace sur du matériel standard, avec des mécanismes matures pour vérifier la sécurité. Plus important encore, ils ont construit un modèle expérimental sur Arbitrum prouvant que WASM comme couche de livraison avec RISC-V pour les preuves peut fonctionner indépendamment sans interférence.

Ce qui est intéressant, c'est que cela reflète un changement plus large dans l'écosystème : les L2 commencent à rechercher leur identité indépendante plutôt que de simplement aider Ethereum. Certains voient que le vrai défi n'est pas l'expansion, mais la création d'espaces de blocs uniques pour des scénarios réels.

Vitalik a reconnu que le remplacement de l'EVM manque encore de compatibilité généralisée. La correction de l'arbre d'état est plus mature, mais RISC-V est encore en phase de "feuille de route". Cependant, il a publié une position étonnante : Ethereum a déjà remplacé son moteur une fois en plein vol (The Merge), et peut le faire environ quatre fois de plus.

Il prévoit de déployer la mise à niveau Glamsterdam dans la première moitié de 2026, suivie directement par Hegota. La correction de l'arbre d'état et l'amélioration de la couche d'exécution sont les deux axes prioritaires.

La vraie question : s'agit-il d'une révision réfléchie ou d'un piège sans fin qui devient de plus en plus complexe à chaque correction ? Peut-être ne le saurons-nous qu'en 2027. Mais une chose est sûre : Ethereum ne prévoit pas d'être un système ancien à réparer à l'ère ZK et de la crypto moderne. La discussion elle-même pourrait être plus précieuse que le résultat final.