La Fondation Ethereum a publié un plan étape par étape pour permettre à la chaîne principale d’Ethereum de valider les blocs à l’aide de preuves zkEVM, réduisant ainsi la nécessité pour les validateurs de réexécuter eux-mêmes chaque calcul. La proposition, partagée via X le 15 janvier par Tomasz K. Stańczak, co-directeur exécutif de la Fondation Ethereum, présente le travail d’ingénierie nécessaire pour l’exécution et le consensus des clients d’Ethereum, ainsi que de nouvelles infrastructures de preuve et de nouveaux processus de sécurité.
zkEVM sur L1 – le planhttps://t.co/KLz7PoH6q9
– Tomasz K. Stańczak (@tkstanczak) 15 janvier 2026
Ethereum L1 s’oriente vers une validation basée sur des preuves zk
En juillet de l’année dernière déjà, la Fondation Ethereum a annoncé son approche « zk-first ». Aujourd’hui, les validateurs d’Ethereum vérifient généralement un bloc en réexécutant les transactions et en comparant les résultats. Le plan propose une alternative : les validateurs pourraient vérifier une preuve cryptographique que l’exécution du bloc a été correcte.
Le document résume le pipeline prévu en termes simples : un client d’exécution produit un package « témoin » compact pour un bloc, un programme zkEVM standardisé utilise ce package pour générer une preuve d’exécution correcte, et les clients de consensus vérifient cette preuve lors de la validation du bloc.
La première étape consiste à créer un « ExecutionWitness », une structure de données par bloc contenant les informations nécessaires pour valider l’exécution sans la réexécuter. Le plan nécessite un format de témoin formel dans les spécifications d’exécution d’Ethereum, des tests de conformité et un point de terminaison RPC standardisé. Il note que le point de terminaison actuel debug_executionWitness est déjà « utilisé en production par Kona d’Optimism », tout en suggérant qu’un point de terminaison plus convivial pour zk pourrait être nécessaire.
Une dépendance clé consiste à ajouter un meilleur suivi des parties de l’état touchées par un bloc, via des listes d’accès au niveau des blocs (BAL). Le document indique qu’en novembre 2025, ce travail n’était pas traité comme suffisamment urgent pour être rétroporté sur des forks précédents.
L’étape suivante est un « programme invité zkEVM », décrit comme une logique de validation sans état qui vérifie si un bloc produit une transition d’état valide lorsqu’il est combiné avec son témoin. Le plan met l’accent sur des constructions reproductibles et sur la compilation selon des objectifs standardisés afin que les hypothèses soient explicites et vérifiables.
Au-delà du code spécifique à Ethereum, le plan vise à standardiser l’interface entre les zkVM et le programme invité : des cibles communes, des moyens communs d’accéder aux précompilations et aux E/S, et des hypothèses convenues sur la manière dont les programmes sont chargés et exécutés.
Du côté du consensus, la feuille de route appelle à des changements afin que les clients consensuels puissent accepter les preuves zk dans le cadre de la validation des blocs balises, avec les spécifications qui les accompagnent, les vecteurs de test et un plan de déploiement interne. Le document signale également que la disponibilité de la charge utile d’exécution est importante, y compris une approche qui pourrait impliquer de « placer le bloc dans des blobs ».
La proposition traite la génération de preuves comme un problème opérationnel autant que protocolaire. Il comprend des étapes pour intégrer les zkVM dans les outils EF tels que Ethproofs et Ere, tester les configurations GPU (y compris « zkboost ») et suivre la fiabilité et les goulots d’étranglement.
L’analyse comparative est conçue comme un travail continu, avec des objectifs explicites tels que la mesure du temps de génération des témoins, du temps de création et de vérification des preuves, ainsi que de l’impact sur le réseau de la propagation des preuves. Ces mesures pourraient alimenter les futures propositions de retarification du gaz pour les charges de travail lourdes en zk.
La sécurité est également considérée comme perpétuelle, avec des plans pour les spécifications formelles, la surveillance, les contrôles de la chaîne d’approvisionnement tels que les versions reproductibles et la signature d’artefacts, ainsi qu’un modèle de confiance et de menace documenté. Le document propose un cadre « go/no-go » pour décider quand les systèmes de preuve sont suffisamment matures pour une utilisation plus large.
Une dépendance externe se démarque : l’ePBS, que le document décrit comme nécessaire pour donner plus de temps aux prouveurs. Sans cela, le plan indique que le prouveur dispose de « 1 à 2 secondes » pour créer une preuve ; avec lui, “6 à 9 secondes”. Le document ajoute un cadre en deux phrases qui traduit l’urgence : “Ce n’est pas un projet sur lequel nous travaillons. Cependant, c’est une optimisation dont nous avons besoin.” Il s’attend à ce que l’ePBS soit déployé à « Glamsterdam », prévu pour la mi-2026.
Si ces jalons se réalisent, Ethereum évoluerait vers une validation basée sur des preuves en tant qu’option pratique sur L1, tandis que le calendrier et la complexité opérationnelle de la preuve restent les facteurs déterminants.
Au moment de mettre sous presse, l’ETH s’échangeait à 3 300 $.
Image en vedette créée avec DALL.E, graphique de TradingView.com
