Il y a quelques mois, Vitalik a lancé une idée très intéressante : Ethereum a en réalité des problèmes plus profonds qu'il n'y paraît au premier abord. Au lieu de constamment réparer l'EVM avec de nouveaux contrats précompilés, peut-être est-il temps de repenser toute l'architecture ?

Et il a proposé deux changements sérieux. Le premier concerne l'arbre d'état - c'est le même arbre de Merkle, que Ethereum utilise comme système d'indexation pour tous les soldes et vérifications. Le problème est que la structure actuelle, appelée arbre de Merkle Patricia Keccak à six branches, est tout simplement trop encombrante. Chaque requête doit traverser une multitude de branches.

Vitalik propose l'EIP-7864 - le remplacer par un arbre binaire. Cela semble simple, mais l'effet est impressionnant : la longueur de l'arbre de Merkle est réduite d'un quart. Pour les clients légers, cela signifie beaucoup moins de données à vérifier. Mais il ne s'est pas arrêté là - il veut aussi changer la fonction de hachage elle-même. Blake3 ou Poseidon ? Poseidon est plus ambitieux, il peut théoriquement augmenter l'efficacité des preuves par dizaines de fois, mais sa sécurité doit encore être vérifiée.

La deuxième proposition est bien plus audacieuse - remplacer à long terme l'EVM par RISC-V. La logique est simple : si les systèmes de preuves ZK comprennent déjà RISC-V, pourquoi la machine virtuelle devrait-elle utiliser un autre langage ? Cela ajoute simplement une traduction supplémentaire. L'interpréteur RISC-V ne nécessite que quelques centaines de lignes de code - c'est précisément ce que devrait être l'interface blockchain.

Trois étapes sont prévues : d'abord lancer des contrats précompilés sur la nouvelle VM, puis permettre aux développeurs de déployer des contrats sur la nouvelle machine parallèlement à l'EVM, et enfin retirer l'EVM de la production, mais sans la supprimer - simplement la réécrire comme un contrat intelligent sur la nouvelle plateforme. Les anciens contrats continueront de fonctionner sans modification.

Vitalik a donné un chiffre : l'arbre d'état et la machine virtuelle représentent ensemble plus de 80 % des limitations de la preuve d'Ethereum. Sans ces changements, la scalabilité à l'ère des ZK restera simplement bloquée sur place.

Mais tout le monde n'est pas d'accord. L'équipe d'Arbitrum Offchain Labs a publié une objection sérieuse. Ils disent : oui, RISC-V est excellent pour les preuves ZK, mais cela ne signifie pas que les contrats doivent être écrits en RISC-V. Ils proposent de diviser cela - WebAssembly pour les contrats, puis compilation en RISC-V pour les preuves. Leur argument : la majorité des nœuds Ethereum ne fonctionnent pas sur des puces RISC-V, WASM dispose de mécanismes de sécurité éprouvés, et l'écosystème d'outils WASM a été testé sur des milliards d'exécutions.

C'est intéressant, car cela indique une tendance plus large. Les solutions L2 commencent à comprendre que leur rôle évolue. Ethereum devient plus rapide en soi, donc les L2 cherchent leur objectif unique - pas seulement la scalabilité, mais des espaces spécialisés pour des scénarios réels.

Quant à la faisabilité de ces changements, il n'y a pas de consensus. La réforme de l'arbre de Merkle est plus concrète, l'EIP-7864 a déjà une équipe. Mais le remplacement de l'EVM ? Cela en est encore au stade de la feuille de route. Les hard forks Glamsterdam et Hegota sont attendus dans la première moitié de 2026, mais les détails ne sont pas encore approuvés.

Mais Vitalik sait probablement ce qu'il fait. Ethereum a déjà changé un moteur réactif en plein vol - The Merge. Il était prêt à changer encore une dizaine d'autres. Ce n'est pas simplement l'ajout de fonctionnalités, mais une refonte même du fondement. Que ce soit une réparation soigneusement planifiée ou un gouffre sans fin de complexité, la réponse ne sera probablement connue qu'en 2027.