La Fondation Ethereum a publié un plan étape par étape pour permettre à la chaîne principale d'Ethereum de valider les blocs en utilisant des preuves zkEVM, réduisant ainsi le besoin pour les validateurs de réexécuter chaque calcul eux-mêmes. La proposition, partagée via X le 15 janvier par Tomasz K. Stańczak, Co-Directeur Exécutif de la Fondation Ethereum, expose le travail d'ingénierie nécessaire à travers les clients d'exécution et de consensus d'Ethereum, ainsi que de nouvelles infrastructures de preuve et processus de sécurité.
zkEVM sur L1 – le planhttps://t.co/KLz7PoH6q9
— Tomasz K. Stańczak (@tkstanczak) 15 janvier 2026
Ethereum L1 Se Dirige vers une Validation Basée sur les Preuves zk
Dès juillet dernier, la Fondation Ethereum avait 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 est 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.
Le premier jalon est la création d'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 demande 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 debug_executionWitness actuel est déjà « utilisé en production par Kona d'Optimism », tout en suggérant qu'un point de terminaison plus adapté au zk pourrait être nécessaire.
Une dépendance clé est l'ajout d'un meilleur suivi des parties de l'état qu'un bloc touche, via les Block Level Access Lists (BALs). Le document indique qu'en novembre 2025, ces travaux n'étaient pas considérés comme suffisamment urgents pour être rétroportés vers les forks antérieurs.
Le prochain jalon 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 builds reproductibles et une compilation vers des cibles standardisées 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 zkVMs 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 façon dont les programmes sont chargés et exécutés.
Du côté du consensus, la feuille de route demande des modifications pour que les clients de consensus puissent accepter les preuves zk dans le cadre de la validation des blocs de beacon, avec des spécifications accompagnatrices, des vecteurs de test et un plan de déploiement interne. Le document souligne également l'importance de la disponibilité de la charge utile d'exécution, y compris une approche qui pourrait impliquer de « mettre le bloc dans des blobs ».
La proposition traite la génération de preuves autant comme un problème opérationnel que protocolaire. Elle inclut des jalons pour intégrer les zkVMs dans les outils de l'EF tels qu'Ethproofs et Ere, tester des configurations GPU (y compris « zkboost »), et suivre la fiabilité et les goulots d'étranglement.
Le benchmarking est présenté comme un travail continu, avec des objectifs explicites comme mesurer le temps de génération des témoins, le temps de création et de vérification des preuves, et l'impact réseau de la propagation des preuves. Ces mesures pourraient alimenter de futures propositions de reprix du gaz pour les charges de travail intensives en zk.
La sécurité est également marquée comme perpétuelle, avec des plans pour des spécifications formelles, une surveillance, des contrôles de la chaîne d'approvisionnement comme des builds reproductibles et la signature d'artefacts, et 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 distingue : l'ePBS, que le document décrit comme nécessaire pour donner aux prouveurs plus de temps. Sans cela, le plan indique que le prouveur a « 1 à 2 secondes » pour créer une preuve ; avec, « 6 à 9 secondes ». Le document ajoute une formulation en deux phrases qui capture 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é dans « Glamsterdam », ciblé pour mi-2026.
Si ces jalons sont atteints, Ethereum se dirigerait vers une validation basée sur des preuves comme une option pratique sur L1, tandis que le timing et la complexité opérationnelle de la preuve restent les facteurs limitants.
Au moment de la rédaction, l'ETH s'échangeait à 3 300 $.
