Le changement du moteur d'Ethereum est sur le point de commencer. La proposition récemment annoncée par Vitalik Buterin ne se limite pas à une simple mise à niveau, mais implique une refonte fondamentale de la machine virtuelle Ethereum (EVM).

Depuis l'année dernière, la communauté des développeurs suivait une règle tacite. Chaque fois qu'une nouvelle opération cryptographique était nécessaire, au lieu de modifier directement l'EVM, ils utilisaient une « échappatoire » appelée contrat de précompilation. En d'autres termes, ils ne touchaient pas à la base, mais effectuaient des modifications superficielles. Vitalik a contesté cette tendance. Son argument est simple — la valeur d'Ethereum réside dans sa flexibilité, et si l'EVM est insuffisante, il faut construire une machine virtuelle meilleure.

Deux changements majeurs sont proposés concrètement. Tout d'abord, la réforme de l'arbre d'état. Actuellement, Ethereum utilise une structure complexe appelée « arbre de Merkle Patricia à six branches Keccak », mais l'idée est de la remplacer par un arbre binaire simple. Cela réduirait considérablement la bande passante nécessaire pour la vérification des données, améliorant drastiquement l'efficacité des clients légers. Il y a aussi des discussions pour changer la fonction de hachage en Blake3 ou Poseidon.

L'autre changement, plus audacieux, consiste à remplacer à long terme l'EVM par une architecture RISC-V. Dans le domaine des preuves à divulgation zéro (ZK), RISC-V est déjà utilisé comme langage standard. La logique de Vitalik est claire : si le prouveur fonctionne sur RISC-V, pourquoi le machine virtuelle parle-t-il un autre langage, nécessitant une couche de traduction ? En supprimant cette couche, l'efficacité s'améliorerait naturellement.

En combinant ces deux changements, ils représenteraient plus de 80 % du goulot d'étranglement des preuves d'Ethereum. Autrement dit, sans leur réalisation, la scalabilité dans l'ère ZK ne progressera pas.

Cependant, tout le monde n'est pas d'accord. Offchain Labs, l'équipe de développement principale d'Arbitrum, a publié une réfutation technique détaillée. Leur point est aigu — la forme de distribution et la forme de preuve n'ont pas besoin d'être identiques. Tout comme un chariot élévateur efficace dans un entrepôt n'oblige pas un livreur à l'utiliser pour transporter des colis. Offchain Labs propose une approche à deux couches : utiliser WebAssembly dans la couche de contrats intelligents, puis le compiler en RISC-V pour générer des preuves. En pratique, ils ont déjà testé un prototype sur Arbitrum.

Une préoccupation encore plus importante est soulevée. Dans le domaine des preuves ZK, la technologie évolue extrêmement rapidement, et l'implémentation de RISC-V est passée de 32 bits à 64 bits. Si, à ce stade, Ethereum fixe RISC-V comme architecture principale, que faire si une architecture de preuve supérieure apparaît dans deux ans ? Miser sur une cible en rapide évolution n'est pas dans le style d'Ethereum.

Ce qui est intéressant, c'est le timing. Il y a un mois, Vitalik a publiquement douté de la nécessité d'une « feuille de route spécifique pour le Layer 2 » d'Ethereum. En réponse, la communauté L2 a commencé à promouvoir activement « l'indépendance d'Ethereum ». Des co-fondateurs de OP Labs et le PDG de Polygon ont déclaré que le rôle du Layer 2 n'était pas seulement la scalabilité, mais aussi la construction d'espaces de blocs spécialisés pour des cas d'usage spécifiques.

En somme, cette grande modification de la couche d'exécution proposée par Vitalik n'est qu'une annotation technique d'une tendance plus large. Ethereum reprend le contrôle de ses fonctionnalités principales, et les solutions Layer 2 trouvent leur raison d'être en étant indépendantes.

La réforme de l'arbre d'état est déjà bien avancée, avec un brouillon concret et une équipe de promotion pour l'EIP-7864. En revanche, le remplacement de l'EVM est encore au stade de la « feuille de route », avec un certain éloignement de la mise en œuvre. Cependant, Vitalik lui-même affirme qu'Ethereum a déjà effectué une seule fois le changement de moteur lors de The Merge, et qu'il est possible d'en faire environ quatre autres à l'avenir.

L'upgrade Glamsterdam est prévu pour la première moitié de 2026, suivi par Hegota. La réforme de l'arbre d'état et l'optimisation de la couche d'exécution constituent des orientations majeures clairement identifiées.

L'histoire d'Ethereum n'a jamais été une question de « pouvoir ou ne pas pouvoir ». Passant du PoW au PoS, se concentrant sur la couche principale plutôt que sur la scalabilité via Rollup, Ethereum a déjà montré sa capacité et son courage à démonter ses moteurs à des altitudes extrêmes. Ce qui se prépare maintenant, c'est une modification plus profonde — non pas l'ajout de nouvelles fonctionnalités cryptographiques, mais la déterrer et reconstruire ses bases anciennes.

S'agit-il d'une rénovation soigneusement planifiée ou d'un gouffre de plus en plus complexe ? La réponse ne sera probablement claire qu'en 2027. La seule certitude, c'est qu'Ethereum ne souhaite pas rester un « vieux système patché » à l'ère ZK. La discussion sur la façon de retirer ces patchs et de remplacer le moteur par un autre modèle pourrait même avoir plus de valeur que la conclusion elle-même.