J'ai remarqué quelque chose d'intéressant ces derniers temps. Vitalik revient avec des propositions assez radicales sur l'architecture d'Ethereum, et franchement, ça mérite qu'on en parle.

Alors voilà, depuis des années, les développeurs Ethereum ont une sorte de mauvaise habitude. Chaque fois qu'ils avaient besoin d'une nouvelle opération cryptographique sur la chaîne, au lieu de l'implémenter correctement dans l'EVM, ils contournaient simplement le problème en ajoutant des contrats précompilés au niveau du protocole. C'est comme si on bricolait en permanence au lieu de refaire les fondations. Vitalik a essentiellement dit : stop, ça suffit. Si l'EVM n'est pas assez bon, on ne va pas continuer à empiler les rustines. On va le remplacer.

Il a proposé deux changements majeurs. Le premier concerne l'arbre d'état d'Ethereum, tu peux le voir comme le système d'indexation du registre. Actuellement, c'est une structure compliquée appelée sextuple Keccak Merkle Patricia tree (oui, le nom est un peu fou). L'idée c'est de la remplacer par un simple arbre binaire. Concrètement, au lieu de choisir ta direction à un carrefour à six branches, tu n'aurais que deux options : gauche ou droite. Résultat ? La longueur des branches Merkle diminue d'environ 75%. Pour les clients légers, c'est énorme en termes de bande passante.

Mais Vitalik ne s'arrête pas là. Il veut aussi changer la fonction de hachage. Deux candidats : Blake3 ou Poseidon. Blake3 c'est sûr mais classique. Poseidon c'est plus ambitieux, ça pourrait théoriquement multiplier l'efficacité des preuves par plusieurs dizaines de fois, mais il faut plus d'audits de sécurité.

Le deuxième changement est plus controversé : remplacer l'EVM par RISC-V à long terme. RISC-V c'est un jeu d'instructions open source, initialement créé pour autre chose, mais maintenant utilisé partout dans les systèmes de preuve ZK. La logique est simple : puisque tous les proveurs parlent déjà RISC-V, pourquoi la machine virtuelle utiliserait-elle un autre langage avec une couche de traduction intermédiaire ? C'est inefficace. Un interpréteur RISC-V ne demande que quelques centaines de lignes de code.

Vitalik a présenté un plan en trois étapes : d'abord exécuter les contrats précompilés sur la nouvelle machine virtuelle, ensuite permettre aux développeurs de déployer directement sur cette nouvelle architecture en parallèle avec l'EVM existant, et finalement retirer l'EVM mais le réécrire comme contrat intelligent sur la nouvelle machine virtuelle. Zéro rupture de compatibilité. C'est élégant.

Les chiffres qu'il a donnés sont frappants : l'arbre d'état et la machine virtuelle représentent ensemble plus de 80% du goulot d'étranglement de preuve d'Ethereum. Autrement dit, sans toucher à ces deux composants, tu peux oublier l'évolutivité réelle à l'ère ZK.

Mais bien sûr, ce n'est pas unanime. Offchain Labs, l'équipe derrière Arbitrum, a publié une réfutation technique détaillée. Leur argument : RISC-V c'est bien pour les preuves ZK, mais pas pour servir de format de livraison des contrats. Ils font une distinction importante : tu n'as pas besoin que le livreur conduise un chariot élévateur juste parce que ton entrepôt en utilise un. Ils défendent WebAssembly (WASM) pour la couche contrat, et franchement leurs arguments sont solides. WASM s'exécute efficacement sur du matériel standard, alors que la plupart des nœuds Ethereum ne tournent pas sur des puces RISC-V. Offchain Labs a même déjà implémenté un prototype : WASM pour les contrats, compilé en RISC-V pour la preuve ZK. Deux couches, chacune fait son travail.

Ce qui est intéressant c'est le contexte plus large. Il y a quelques mois, Vitalik remettait en question la nécessité pour Ethereum d'avoir une feuille de route L2 dédiée. Et les L2 ne paniquent pas, ils commencent activement à se "dé-ethereumiser". Polygon et OP Labs parlent maintenant d'Ethereum comme d'un standard de règlement sous-jacent, pas comme leur infrastructure principale. C'est un vrai changement d'orientation.

Vitalik lui-même reconnaît 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 plus avancée avec l'EIP-7864 qui a déjà un projet concret. Mais remplacer l'EVM par RISC-V ? C'est encore au stade du plan stratégique, loin d'être intégré dans le code.

Ce qui m'a frappé c'est ce qu'il a déclaré récemment : Ethereum a déjà changé un moteur à réaction en vol avec The Merge, et il peut encore le faire environ quatre fois de plus. L'arbre d'état, le consensus simplifié, la vérification ZK-EVM, le remplacement de la machine virtuelle. C'est ambitieux.

La vraie question c'est : est-ce une rénovation réfléchie ou un trou sans fond qui s'agrandit ? Impossible à dire pour l'instant. Mais une chose est certaine : Ethereum n'a pas l'intention de devenir un système ancien rafistolé à l'ère ZK. Comment démonter les rustines et quel modèle mettre en place, ce débat lui-même pourrait être plus précieux que la réponse finale.