Imaginez un futur où générer une preuve cryptographique pour une transaction Ethereum ne coûte presque plus rien comparé à aujourd’hui. C’est précisément la vision que défend depuis longtemps l’un des cerveaux les plus influents de l’écosystème blockchain. Récemment, une nouvelle proposition technique majeure a été détaillée, promettant de s’attaquer directement à l’un des plus gros goulets d’étranglement actuels : le coût exorbitant des preuves zéro connaissance.
La grande refonte de l’état Ethereum est en marche
Depuis plusieurs années, la communauté Ethereum cherche désespérément à rendre les preuves ZK (zero-knowledge) beaucoup moins coûteuses en calcul et en bande passante. Les différentes couches 2 qui utilisent cette technologie se heurtent toutes au même mur : prouver l’état du réseau principal reste extrêmement onéreux. Une proposition fraîchement publiée vise à résoudre ce problème de front en modifiant deux éléments fondamentaux du protocole : la structure de l’arbre d’état et, à plus long terme, la machine virtuelle elle-même.
Adieu l’arbre hexadécimal keccak, bonjour l’arbre binaire moderne
L’actuel arbre Merkle-Patricia hexadécimal utilisant keccak256 date des débuts d’Ethereum. À l’époque, les priorités étaient différentes : rapidité de vérification native, compacité pour les nœuds légers, résistance aux attaques. Mais dans un monde où les preuves ZK deviennent centrales, ces choix techniques montrent leurs limites.
La proposition EIP-7864 suggère de passer à un arbre binaire unifié. Fini les branches hexadécimales de 64 niveaux en moyenne ; place à des branches binaires beaucoup plus courtes. Le gain est immédiat : la taille des preuves Merkle chute drastiquement, environ 75 % de réduction selon les calculs présentés.
Mais ce n’est pas tout. En changeant simultanément la fonction de hachage pour une plus moderne et plus rapide dans les contextes ZK, les gains s’accumulent. Trois options sont sérieusement envisagées :
- BLAKE3, déjà très rapide et sécurisé
- Une version optimisée Poseidon2, spécialement conçue pour les preuves SNARK/STARK
- À plus long terme, potentiellement d’autres candidats issus de la recherche actuelle
En combinant arbre binaire + BLAKE3, on parle déjà d’un gain de 3 à 5× sur les coûts de preuve. Avec Poseidon2 correctement audité, certains estiment que le multiplicateur pourrait atteindre 30× à 100× sur la partie hachage seule. Impressionnant.
Le stockage paginé : une optimisation pragmatique pour les contrats actuels
Autre innovation maligne intégrée à cette refonte : le regroupement des slots de stockage en pages de 64 à 256 emplacements contigus (soit 2 à 8 Ko). Pourquoi ? Parce que la très grande majorité des contrats lisent ou écrivent dans les premiers slots de leur stockage.
Aujourd’hui, chaque accès individuel coûte cher. Demain, les 1 à 4 premiers kilo-octets de code + stockage pourraient être regroupés dans une même page, partagée avec l’en-tête de bloc. Résultat annoncé : plus de 10 000 gas économisés par transaction pour de nombreux dApps existants. Pas négligeable quand on sait que le gas reste un facteur limitant pour l’adoption de masse.
« Les contrats qui chargent leurs données depuis les premiers slots bénéficieront d’une économie substantielle, sans aucun changement de code nécessaire. »
Cette approche pragmatique permet de capturer rapidement une grande partie des gains sans attendre une migration complète des smart contracts.
Pourquoi l’arbre binaire est aussi plus simple à auditer
Les arbres hexadécimaux introduisent une variabilité importante selon la taille du contrat. Un petit contrat aura une profondeur différente d’un gros contrat. Cela complique les audits et rend les pires cas plus difficiles à anticiper.
Avec un arbre binaire, la profondeur devient beaucoup plus prévisible. Les variations diminuent fortement. Cela ouvre également la porte à des extensions futures comme l’expiration d’état (state expiry) : il devient plus simple d’attacher des métadonnées de péremption à chaque branche ou page.
Moins de complexité = moins de bugs cachés. Un argument qui pèse lourd quand on parle d’un changement aussi fondamental.
Le grand saut : remplacer l’EVM par RISC-V
Si la refonte de l’arbre d’état constitue la proposition à court/moyen terme, la vision à plus long terme est encore plus radicale : abandonner progressivement l’Ethereum Virtual Machine au profit d’une architecture RISC-V.
Pourquoi RISC-V ? Plusieurs arguments très convaincants sont avancés :
- Efficacité brute d’exécution : RISC-V est une ISA moderne, bien plus performante que l’EVM pour la plupart des calculs. Beaucoup de précompilés actuels deviendraient inutiles.
- Alignement parfait avec les provers ZK : la majorité des implémentations de SNARK/STARK les plus performantes utilisent déjà RISC-V comme cible. Pas besoin de traduire l’EVM en RISC-V à chaque preuve.
- Preuves locales côté client : les utilisateurs pourraient générer des preuves ZK directement depuis leur téléphone ou navigateur pour prouver des propriétés sur leurs propres transactions, ouvrant des cas d’usage de confidentialité inédits.
- Simplicité d’implémentation : un interpréteur RISC-V complet tient en quelques centaines de lignes de code, contre des dizaines de milliers pour l’EVM actuelle.
Le plan de migration est pensé en trois phases progressives :
- Phase 1 : nouveau VM ne gère que les précompilés (anciens et nouveaux deviennent des blobs de code RISC-V)
- Phase 2 : déploiement direct de contrats en RISC-V possible
- Phase 3 : l’EVM est réimplémentée comme un smart contract en RISC-V → compatibilité arrière totale, mais gas costs ajustés
Cette approche en douceur vise à éviter un hard fork brutal et à permettre à l’écosystème de migrer progressivement.
80 % des coûts de preuve viennent de ces deux composants
L’argument central de toute la proposition peut se résumer en une phrase choc : arbre d’état + machine virtuelle représentent ensemble plus de 80 % du coût total de génération d’une preuve efficace sur Ethereum aujourd’hui.
Changer l’un sans toucher l’autre revient à réparer la moitié d’un moteur. Changer les deux simultanément (même en plusieurs années) permettrait de construire un protocole nativement compatible avec un avenir dominé par les preuves ZK, plutôt que de continuer à bricoler des rustines sur une base conçue en 2014 pour des exigences radicalement différentes.
Les défis qui restent à relever
Bien entendu, rien n’est encore acté. Plusieurs obstacles majeurs se dressent encore :
- Changer la fonction de hachage nécessite des années d’analyse cryptographique
- Remplacer l’EVM demande un consensus communautaire très large
- La migration des milliards de lignes de code Solidity existant doit rester indolore
- Les outils de développement (compilateurs, debuggers, frameworks de test) devront suivre
- Les layer 2 actuels devront s’adapter à la nouvelle structure d’état
Malgré ces défis, l’élan semble plus fort que jamais. Les progrès fulgurants des provers ZK ces 24 derniers mois rendent cette vision de plus en plus réaliste.
Vers un Ethereum conçu pour le monde ZK-first
Si ces deux changements aboutissent dans les prochaines années, Ethereum pourrait devenir la première grande blockchain à être véritablement repensée de fond en comble autour des preuves à divulgation nulle de connaissance.
Exit les compromis hérités de 2015. Exit les précompilés qui s’accumulent comme des pansements. Exit les coûts de preuve qui freinent l’adoption massive des rollups et des applications privées.
Nous pourrions assister à la naissance d’une nouvelle ère : celle d’un protocole blockchain où la confidentialité, l’efficacité et la scalabilité ne sont plus des compromis, mais des propriétés de base.
Le chemin sera long. Les débats seront intenses. Mais une chose est sûre : la proposition actuelle marque un tournant stratégique majeur. Ethereum ne cherche plus seulement à scaler. Il cherche à se réinventer complètement pour l’avenir qui arrive.
Et vous, que pensez-vous de cette direction ? Êtes-vous prêt à voir l’EVM rejoindre les livres d’histoire dans quelques années ?
À suivre de très près dans les prochains mois.
