Ladislaus.eth, chercheur sur Ethereum, a publié la semaine dernière une procédure pas à pas expliquant comment Ethereum envisage de passer de la réexécution de chaque transaction à la vérification de preuves sans connaissance.
Le message le présente comme une « transformation silencieuse mais fondamentale », et le cadrage est précis. Non pas parce que le travail est secret, mais parce que ses implications se répercutent sur l’ensemble de l’architecture d’Ethereum d’une manière qui ne sera évidente que lorsque les éléments seront connectés.
Il ne s’agit pas d’Ethereum « ajoutant ZK » en tant que fonctionnalité. Ethereum est en train de prototyper un chemin de validation alternatif dans lequel certains validateurs peuvent attester des blocs en vérifiant des preuves d’exécution compactes plutôt que de réexécuter chaque transaction.
Si cela fonctionne, le rôle de layer 1 d’Ethereum passe de « règlement et disponibilité des données pour les cumuls » à « une exécution à haut débit dont la vérification reste suffisamment bon marché pour les validateurs domestiques ».
Qu’est-ce qui est réellement construit
EIP-8025, intitulé « Preuves d’exécution facultatives », a atterri sous forme de brouillon et précise les mécanismes.
Les preuves d’exécution sont partagées sur le réseau peer-to-peer de la couche consensus via un sujet dédié. Les validateurs peuvent fonctionner selon deux nouveaux modes : génération de preuves ou validation sans état.
La proposition indique explicitement qu’elle « ne nécessite pas de hardfork » et reste rétrocompatible, tandis que les nœuds peuvent toujours être réexécutés comme ils le font aujourd’hui.
L’équipe zkEVM de la Fondation Ethereum a publié le 26 janvier une feuille de route concrète pour 2026, décrivant six sous-thèmes : la normalisation des témoins d’exécution et des programmes invités, la normalisation de l’API zkVM-invité, l’intégration de la couche de consensus, l’infrastructure des preuves, l’analyse comparative et les métriques, et la sécurité avec vérification formelle.
Le premier appel en petits groupes L1-zkEVM est prévu le 11 février à 15h00 UTC.
Le pipeline de bout en bout fonctionne comme ceci : un client de couche d’exécution produit un ExecutionWitness, un package autonome contenant toutes les données nécessaires pour valider un bloc sans conserver l’état complet.
Un programme invité standardisé consomme ce témoin et valide la transition d’état. Un zkVM exécute ce programme et un prouveur génère une preuve d’exécution correcte. Le client de la couche consensus vérifie ensuite cette preuve au lieu d’appeler le client de la couche d’exécution pour qu’il réexécute.
La dépendance clé est ePBS (Enshrined Proposer-Builder Separation), ciblée pour le prochain hardfork de Glamsterdam. Sans ePBS, la fenêtre de preuve est d’environ une à deux secondes, ce qui est trop court pour une preuve en temps réel. Avec ePBS fournissant un pipeline de blocs, la fenêtre s’étend de six à neuf secondes.
Le compromis de la décentralisation
Si les preuves facultatives et les formats de témoins arrivent à maturité, davantage de validateurs locaux peuvent participer sans maintenir l’état complet de la couche d’exécution.
Augmenter les limites de gaz devient politiquement et économiquement plus facile car le coût de validation se dissocie de la complexité d’exécution. Le travail de vérification n’évolue plus de manière linéaire avec l’activité en chaîne.
Cependant, la vérification comporte son propre risque de centralisation. Un article d’Ethereum Research du 2 février rapporte que prouver un bloc Ethereum complet nécessite actuellement environ 12 GPU et prend en moyenne 7 secondes.
L’auteur signale des inquiétudes concernant la centralisation et note que les limites restent difficiles à prévoir. Si la preuve reste lourde en GPU et se concentre sur les réseaux de constructeurs ou de prouveurs, Ethereum peut échanger « tout le monde réexécute » contre « peu de preuves, beaucoup vérifient ».
La conception vise à résoudre ce problème en introduisant la diversité des clients au niveau de la couche de preuve. L’hypothèse de travail de l’EIP-8025 est un seuil de trois sur cinq, ce qui signifie qu’un attestateur accepte l’exécution d’un bloc comme valide une fois qu’il a vérifié trois des cinq preuves indépendantes provenant de différentes implémentations client de couche d’exécution.
Cela préserve la diversité des clients au niveau du protocole mais ne résout pas le problème d’accès matériel.
Le cadre le plus honnête est qu’Ethereum change le champ de bataille de la décentralisation. La contrainte actuelle est « pouvez-vous vous permettre d’exécuter un client de couche d’exécution ? » La question de demain pourrait être « Pouvez-vous accéder à des clusters GPU ou à des réseaux de preuves ? »
Le pari est que la vérification des preuves est plus facile à banaliser que le stockage d’état et la réexécution, mais la question matérielle reste ouverte.
Déverrouillage de la mise à l’échelle L1
La feuille de route d’Ethereum, mise à jour pour la dernière fois le 5 février, répertorie « l’apatridie » comme thème majeur de mise à niveau : vérifier les blocs sans stocker un état volumineux.
Les preuves et témoins d’exécution facultatifs constituent le mécanisme concret qui rend la validation apatride pratique. Un nœud sans état ne nécessite qu’un client de consensus et vérifie les preuves pendant le traitement de la charge utile.
La synchronisation se réduit au téléchargement des preuves des blocs récents depuis le dernier point de contrôle de finalisation.
Cela est important pour les limites de gaz. Aujourd’hui, chaque augmentation de la limite de gaz rend l’exploitation d’un nœud plus difficile. Si les validateurs peuvent vérifier les preuves plutôt que de les réexécuter, le coût de la vérification ne correspond plus à la limite de gaz. La complexité d’exécution et le coût de validation se dissocient.
Le flux de travail d’analyse comparative et de retarification de la feuille de route 2026 cible explicitement les mesures qui mappent le gaz consommé aux cycles d’essai et au temps d’essai.
Si ces mesures se stabilisent, Ethereum dispose d’un levier qu’il n’avait pas auparavant : la capacité d’augmenter le débit sans augmenter proportionnellement le coût de fonctionnement d’un validateur.
Ce que cela signifie pour les blockchains de layer 2
Un article récent de Vitalik Buterin soutient que les blockchains de layer 2 devraient se différencier au-delà de la mise à l’échelle et lie explicitement la valeur d’une « précompilation de cumul natif » à la nécessité de preuves zkEVM consacrées dont Ethereum a déjà besoin pour mettre à l’échelle la layer 1.
La logique est simple : si tous les validateurs vérifient les preuves d’exécution, les mêmes preuves peuvent également être utilisées par une précompilation EXECUTE pour les cumuls natifs. L’infrastructure de preuve de layer 1 devient une infrastructure partagée.
Cela déplace la proposition de valeur de la layer 2. Si la layer 1 peut évoluer vers un débit élevé tout en maintenant les coûts de vérification à un faible niveau, les cumuls ne peuvent pas se justifier sur la base du « Ethereum ne peut pas gérer la charge ».
Les nouveaux axes de différenciation sont les machines virtuelles spécialisées, la latence ultra-faible, les préconfirmations et les modèles de composabilité tels que les rollups qui s’appuient sur des conceptions éprouvées rapidement.
Le scénario dans lequel les couches 2 restent pertinentes est celui dans lequel les rôles sont partagés entre spécialisation et interopérabilité.
La layer 1 devient la couche d’exécution et de règlement à haut débit et à faible coût de vérification. Les couches 2 deviennent des laboratoires de fonctionnalités, des optimiseurs de latence et des ponts de composabilité.
Cependant, cela nécessite que les équipes de layer 2 articulent de nouvelles propositions de valeur et qu’Ethereum respecte la feuille de route de vérification des preuves.
Trois voies à suivre
Il existe trois scénarios potentiels pour l’avenir.
Le premier scénario consiste à ce que la validation par preuve d’abord devienne courante. Si les formats de preuves et de témoins facultatifs arrivent à maturité et que les implémentations client se stabilisent autour d’interfaces standardisées, davantage de validateurs domestiques pourront participer sans exécuter l’état complet de la couche d’exécution.
Les limites de gaz augmentent car le coût de validation ne correspond plus à la complexité d’exécution. Ce chemin dépend du flux de travail de normalisation d’ExecutionWitness et des programmes invités convergeant vers des formats portables.
Le deuxième scénario est celui où la centralisation des prouveurs devient le nouveau point d’étranglement. Si la preuve reste lourde en GPU et concentrée dans les réseaux de constructeurs ou de prouveurs, alors Ethereum déplace le champ de bataille de la décentralisation du matériel des validateurs vers la structure du marché des preuves.
Le protocole fonctionne toujours, car un prouveur honnête, où qu’il soit, maintient la chaîne en vie, mais le modèle de sécurité change.
Le troisième scénario est que la vérification de preuve de layer 1 devienne une infrastructure partagée. Si l’intégration de la couche de consensus se renforce et qu’ePBS offre une fenêtre de preuve étendue, alors la proposition de valeur de la layer 2 s’oriente vers des machines virtuelles spécialisées, une latence ultra-faible et de nouveaux modèles de composabilité plutôt que de « faire évoluer Ethereum » seul.
Ce chemin nécessite qu’ePBS soit expédié dans les délais pour Glamsterdam.
La situation dans son ensemble
La maturité de l’intégration des spécifications consensuelles indiquera si les « preuves facultatives » passent principalement de TODO à des vecteurs de test renforcés.
La standardisation d’ExecutionWitness et du programme invité est la clé de voûte de la portabilité de la validation sans état entre les clients. Des références qui cartographient le gaz consommé en fonction des cycles d’essai et du temps d’essai détermineront si une revalorisation du prix du gaz pour une compatibilité ZK est réalisable.
Les progrès de l’ePBS et de Glamsterdam indiqueront si la fenêtre d’essai de six à neuf secondes devient une réalité. Les résultats des appels en petits groupes révéleront si les groupes de travail convergent sur les interfaces et la sémantique minimale de distribution de preuves viables.
Ethereum ne passera pas bientôt à la validation basée sur des preuves. EIP-8025 indique explicitement qu’il « ne peut pas encore baser les mises à niveau dessus » et le cadrage facultatif est intentionnel. En conséquence, il s’agit d’une voie testable plutôt que d’une activation imminente.
Pourtant, le fait que la Fondation Ethereum ait publié une feuille de route de mise en œuvre pour 2026, programmé un appel en petits groupes avec les propriétaires de projets et rédigé un EIP avec des mécanismes concrets de potins peer-to-peer signifie que ce travail est passé de la plausibilité de la recherche à un programme de livraison.
La transformation est discrète car elle n’implique pas de changements économiques dramatiques ni de fonctionnalités destinées aux utilisateurs. Mais c’est fondamental car cela réécrit la relation entre complexité d’exécution et coût de validation.
Si Ethereum peut dissocier les deux, la layer 1 ne sera plus le goulot d’étranglement qui force tout ce qui est intéressant à la layer 2.
Et si la vérification de preuve de layer 1 devient une infrastructure partagée, l’ensemble de l’écosystème de layer 2 doit répondre à une question plus difficile : que construisez-vous que la layer 1 ne peut pas construire ?
