La Fondation Ethereum trace la voie vers les preuves zkEVM sur le L1 Mainnet

La Fondation Ethereum a publié un plan détaillé permettant à 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, détaille le travail d'ingénierie nécessaire pour les clients d'exécution et de consensus d'Ethereum, ainsi que la nouvelle infrastructure de preuve et les processus de sécurité.

Ethereum L1 évolue vers une validation basée sur les preuves zk

Dès juillet de l'année dernière, 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 attestant que l'exécution du bloc était correcte.

Le document résume le pipeline prévu en termes simples : un client d'exécution produit un paquet « witness » compact pour un bloc, un programme zkEVM standardisé utilise ce paquet 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 prévoit un format de witness 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 adapté au zk pourrait être nécessaire.

Une dépendance clé consiste à améliorer le suivi des parties de l'état qu'un bloc touche, via les listes d'accès au niveau des blocs (BALs). Le document indique qu'en novembre 2025, ce travail n'était pas considéré comme suffisamment urgent pour être rétrospectivement intégré aux forks antérieurs.

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 witness. Le plan met l'accent sur les builds reproductibles et la 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 precompiles 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 prévoit des modifications permettant aux clients de consensus d'accepter les preuves zk dans le cadre de la validation des blocs beacon, avec des spécifications associées, 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, incluant une approche qui pourrait impliquer « la mise du bloc dans des blobs ».

La proposition traite la génération de preuves comme un problème opérationnel autant que protocolaire. Elle inclut des jalons pour intégrer les zkVMs dans les outils EF tels qu'Ethproofs et Ere, tester les configurations GPU (y compris « zkboost ») et suivre la fiabilité et les goulots d'étranglement.

L'analyse comparative est présentée comme un travail en cours, avec des objectifs explicites tels que la mesure du temps de génération du witness, du temps de création et de vérification de la preuve, et de l'impact réseau de la propagation des preuves. Ces mesures pourraient alimenter de futures propositions de révision des prix du gas 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 risques en temps réel, des contrôles de la chaîne d'approvisionnement tels que des builds reproductibles et la signature d'artefacts, ainsi qu'un modèle documenté de confiance et de menace. 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 : ePBS, que le document décrit comme nécessaire pour donner plus de temps aux provers. Sans lui, le plan indique que le prover dispose de « 1 à 2 secondes » pour créer une preuve ; avec lui, « 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 prévoit le déploiement d'ePBS dans « Glamsterdam », prévu pour mi-2026.

Si ces jalons sont atteints, Ethereum évoluera vers la validation basée sur les preuves comme option pratique sur L1, tandis que le timing et la complexité opérationnelle de la génération de preuves restent les facteurs limitants.

Au moment de la publication, l'ETH s'échangeait à 3 300 $.