Ethereum est actuellement sur le point de subir une opération majeure, le cœur du problème étant la manière dont il va gérer l'EVM.

Récemment, Vitalik a lancé une question intéressante. Jusqu'à présent, les développeurs d'Ethereum ont préféré ne pas toucher directement à l'EVM chaque fois qu'une nouvelle opération cryptographique était nécessaire, mais plutôt coder en dur des contrats précompilés dans la couche protocolaire. C'était une sorte de stratégie de contournement. Mais Vitalik pense que ce n'est pas une solution fondamentale.

Ce qu'il propose, ce sont deux approches. La première consiste à simplifier l'arbre d'état, en passant de la structure hexagonale actuelle à un arbre binaire plus simple (EIP-7864). Cela réduit la longueur des branches Merkle d'un quart, ce qui diminue considérablement la bande passante nécessaire pour la vérification des données par les clients légers. La deuxième approche est plus audacieuse : remplacer l'EVM par une architecture RISC-V. La logique est simple — les systèmes de preuve ZK utilisent déjà RISC-V, alors pourquoi ne pas utiliser un autre langage pour la machine virtuelle ? En éliminant la couche de traduction, l'efficacité augmenterait naturellement.

Fait intéressant, Arbitrum n'est pas d'accord. L'équipe off-chain Labs a présenté une réfutation précise : RISC-V est bon pour la preuve, mais pas adapté pour le format de livraison des contrats. Ils proposent plutôt d'utiliser WASM pour la couche de contrat, et RISC-V uniquement pour la preuve. Ils ont déjà testé cette approche dans un prototype sur Arbitrum.

En regardant la vue d'ensemble, cela se relie aussi à une redéfinition du rôle de l'Ethereum et des solutions L2. Après que Vitalik ait remis en question la nécessité d'une feuille de route dédiée aux L2, ces derniers cherchent plutôt à devenir indépendants d'Ethereum. Le CEO de Polygon a déclaré que le vrai défi n'était pas la scalabilité, mais la création d'espaces de blocs uniques pour chaque L2.

Alors, cela va-t-il vraiment se produire ? Vitalik lui-même admet qu'il n'y a pas encore de consensus large sur le remplacement de l'EVM. La réforme de l'arbre d'état est à un stade plus avancé (avec des brouillons concrets et une équipe dédiée), mais la transition vers RISC-V en est encore au stade de la feuille de route. Cependant, il a fait une déclaration intéressante : Ethereum a déjà changé une fois de moteur avec la fusion (The Merge), et il pourrait en faire encore environ quatre autres, notamment avec la réforme de l'arbre d'état, l'optimisation de la couche d'exécution, la vérification ZK-EVM, et le remplacement de la machine virtuelle.

L'upgrade Glimmer est prévu pour le premier semestre de cette année, suivi probablement par l'upgrade Hegatha. Les détails ne sont pas encore finalisés, mais la refonte de l'arbre d'état et l'optimisation de la couche d'exécution seront probablement au cœur des discussions.

En fin de compte, il ne s'agit pas simplement d'ajouter un patch, mais de déchirer complètement la structure existante pour la reconstruire. La volonté de ne pas rester avec un système obsolète dans l'ère ZK est claire. Les résultats devraient se voir d'ici 2027.