Je remarque qu’au fil des années, une tradition intéressante s’est instaurée sur Ethereum : au lieu d’améliorer la machine virtuelle elle-même, les développeurs contournent simplement celle-ci via des contrats précompilés. Mais Vitalik ne s’arrête pas là. Récemment, il a publié un plan détaillé pour tout repenser de zéro.

La première partie du plan concerne l’arbre d’état d’Ethereum. Pour simplifier, c’est comme un système d’indexation, par lequel le système recherche constamment des données. Le problème, c’est que la structure actuelle — le même arbre de Merkle Keccak à six branches — est trop encombrante. L’EIP-7864, proposé par Vitalik, le remplace par un arbre binaire. Au lieu de choisir parmi six directions, vous choisissez simplement gauche ou droite. Résultat ? La longueur de l’arbre de Merkle est réduite de quatre fois. Pour les clients légers, cela signifie une réduction significative des exigences en bande passante.

Mais ce n’est pas tout. Vitalik veut aussi changer la fonction de hachage elle-même. Deux candidats sont à l’étude : Blake3, qui offre une accélération stable, et Poseidon, qui pourrait théoriquement augmenter l’efficacité des preuves par dizaines de fois, bien que la sécurité soit encore en cours de vérification. Ce plan remplace en fait les arbres Verkle, dont la communauté discutait depuis des années, mais qui ont perdu en popularité face à la menace des calculs quantiques.

La deuxième étape est encore plus ambitieuse : remplacer l’architecture de la machine virtuelle par RISC-V. La logique est simple — si les systèmes de preuves à connaissance zéro comprennent déjà RISC-V, pourquoi la machine devrait utiliser un autre langage ? En supprimant la couche de traduction, tout s’accélère automatiquement. Vitalik prévoit trois phases : d’abord, réécrire 80 % des contrats précompilés sur la nouvelle VM, ensuite permettre aux développeurs de déployer directement des contrats, et enfin retirer l’ancien EVM de l’exploitation — mais sans le supprimer, en le réécrivant comme un contrat intelligent sur la nouvelle machine. Les anciens contrats continueront de fonctionner, comme un moteur avec un moteur remplaçable.

Vitalik a déclaré que l’arbre d’état et la machine virtuelle représentent ensemble plus de 80 % des limitations d’Ethereum. Sans ces changements, la scalabilité à l’ère des ZK ne progressera tout simplement pas.

Mais tout le monde n’est pas d’accord. L’équipe d’Arbitrum Offchain Labs a publié une contestation technique détaillée. Leur position : RISC-V est bien pour les preuves à connaissance zéro, mais pas nécessairement idéal comme format pour les contrats. Ils ont différencié entre le jeu d’instructions pour la livraison de (dISA) et celui pour la preuve (pISA). Selon eux, ce ne devrait pas être la même chose. Ils proposent WebAssembly pour le niveau des contrats, puis compilation en RISC-V pour les preuves. Ils ont déjà lancé un prototype sur Arbitrum, et cela fonctionne. De plus, ils soulignent un risque : la technologie ZK évolue rapidement, et si on fixe RISC-V sur la couche L1 maintenant, que se passera-t-il dans deux ans ?

Ce débat s’inscrit dans un contexte de changement plus large. Vitalik a récemment remis en question la nécessité d’une feuille de route L2 distincte pour Ethereum. Curieusement, les L2 n’ont pas paniqué, mais ont commencé à repenser activement leur rôle. Si Ethereum devient plus rapide, alors les L2 doivent trouver leurs espaces propres — pas seulement pour la scalabilité, mais pour de véritables cas d’usage.

Vitalik lui-même a reconnu qu’il n’y a pas encore de consensus sur le remplacement de l’EVM. La réforme de l’arbre d’état a avancé — l’EIP-7864 a déjà un projet concret. Mais le passage à RISC-V ? C’est encore au stade de la feuille de route. Le hard fork Glamsterdam était prévu pour la première moitié de 2026, suivi par Hegota. Les détails précis ne sont pas encore approuvés, mais la réforme de l’arbre d’état et l’optimisation du niveau d’exécution sont des directions clairement tracées.

L’histoire d’Ethereum a toujours été celle de ce qui est possible. Du passage du PoW au PoS, du L1 aux Rollups — le système a déjà prouvé qu’il était prêt à démonter ses moteurs à 10 000 mètres d’altitude. Cette fois, il s’agit de choses plus profondes : non pas ajouter des fonctionnalités, mais refondre le fondement même. S’agit-il d’une rénovation soigneusement planifiée ou d’un trou de plus en plus difficile à combler ? La réponse ne viendra pas avant 2027. Mais une chose est claire : Ethereum ne veut pas devenir un vieux système avec des patchs. Cette controverse sur la façon de défaire les patchs et le moteur à installer — peut-être même plus précieuse que n’importe quelle conclusion.