Je viens de remarquer que Vitalik a lancé une série de propositions assez audacieuses concernant la structure fondamentale d'Ethereum. La particularité ici est qu'il ne s'agit pas simplement de petites améliorations, mais d'une "démontage" alors que l'avion vole à 10 000 mètres d'altitude.

Le problème que Vitalik soulève est assez intéressant : depuis longtemps, les développeurs d'Ethereum ont l'habitude d'éviter d'utiliser l'EVM si possible. Chaque fois qu'ils ont besoin d'ajouter une nouvelle opération cryptographique, au lieu de l'implémenter dans l'EVM, ils demandent à ajouter un "contrat pré-compilé" pour contourner complètement la machine virtuelle. Cela montre que l'EVM devient réellement un goulot d'étranglement.

Vitalik propose deux changements majeurs. Le premier est la réforme de l'arbre d'état d'Ethereum — ce "système d'indexation" qui doit être parcouru à chaque vérification de solde ou validation de transaction. Actuellement, il utilise une structure complexe appelée Merkle Patricia Tree Keccak. Vitalik souhaite la remplacer par un arbre binaire plus simple, réduisant la longueur des branches Merkle d'environ un quart. Par ailleurs, il propose de changer la fonction de hachage, en utilisant peut-être Blake3 ou Poseidon. Ce changement réduirait considérablement la bande passante nécessaire pour les clients légers.

Mais le second changement, qui est vraiment "l'événement majeur" : remplacer l'EVM par une architecture RISC-V à long terme. La logique est très simple — si les systèmes de preuve ZK utilisent déjà RISC-V, pourquoi la machine virtuelle doit-elle utiliser un autre langage et ajouter une couche de traduction entre eux ? En éliminant cette couche, la performance augmenterait automatiquement. Vitalik prévoit trois étapes : d’abord exécuter le contrat pré-compilé sur la nouvelle VM, ensuite permettre un déploiement direct, et enfin "prendre sa retraite" l’EVM mais la réécrire en un contrat intelligent fonctionnant sur la nouvelle VM pour assurer une compatibilité totale.

Ce qui est intéressant, c’est que Vitalik donne un chiffre : l’arbre d’état et la machine virtuelle représentent plus de 80 % du goulot d’étranglement de la preuve d’Ethereum. En d’autres termes, si l’on ne touche pas à ces deux parties, l’expansion d’Ethereum à l’ère ZK restera limitée.

Mais tout le monde n’est pas d’accord. Offchain Labs, l’équipe derrière Arbitrum, a répliqué en détail. Ils disent que RISC-V est effectivement adapté pour créer des preuves ZK, mais pas pour faire "le format de livraison" des contrats. Ils distinguent entre "l’ensemble d’instructions de livraison" et "l’ensemble d’instructions de preuve" — deux choses qui n’ont pas besoin d’être identiques. Offchain Labs propose d’utiliser WebAssembly (WASM) pour la couche des contrats, car WASM fonctionne efficacement sur le matériel standard, dispose d’un mécanisme d’authentification sécurisé basé sur le typage, et son écosystème d’outils a été testé des milliards de fois dans la pratique. Ils ont même déployé un prototype sur Arbitrum : utiliser WASM comme format de transaction, puis le compiler en RISC-V pour générer la preuve ZK. Les deux couches fonctionnent indépendamment.

Offchain Labs soulève aussi un risque important : la technologie de preuve ZK évolue très rapidement, récemment RISC-V est passé de 32 bits à 64 bits. Si l’on intègre RISC-V dans Ethereum L1 maintenant, que se passe-t-il si, dans deux ans, une architecture meilleure apparaît ?

Le contexte plus large est que les L2 commencent à "se désintoxiquer" d’Ethereum. Il y a un mois, Vitalik a posé la question de savoir si Ethereum avait encore besoin d’un "chemin L2 dédié". Plutôt que de paniquer, les L2 cherchent à "se libérer d’Ethereum", en trouvant leur propre raison d’exister indépendamment.

Vitalik admet aussi que le remplacement de l’EVM n’a pas encore une large approbation communautaire. La réforme de l’arbre d’état est plus mûre, avec un brouillon concret, mais remplacer l’EVM par RISC-V n’en est qu’à la phase de "feuille de route". Cependant, Vitalik a récemment déclaré qu’Ethereum a déjà changé de moteur à réaction une fois (The Merge), et qu’il pourrait en changer environ quatre autres — incluant l’arbre d’état, la simplification du consensus, la validation ZK-EVM, et la substitution de la machine virtuelle.

La mise à niveau Glamsterdam devrait être déployée au premier semestre 2026, suivie par Hegota. La réforme de l’arbre d’état et l’optimisation de la couche d’exécution sont les principales directions déjà définies. La vraie question n’est pas "si c’est possible", mais comment décomposer les pièces. Ethereum a déjà prouvé cette capacité en passant du PoW au PoS, du L1 tout en un à la centralisation autour des Rollups. Cette fois, il s’agit de démanteler l’ancien socle pour le refondre, et non simplement d’ajouter de nouvelles fonctionnalités. C’est une rénovation à long terme, et la réponse sera probablement claire d’ici 2027. Mais une chose est sûre : Ethereum ne veut pas devenir un "système obsolète à réparer" à l’ère ZK.