Ethereum se Prépare à Valider les Blocs Sans les Exécuter – Voici Comment

Un changement subtil mais important prend forme au cœur de l'architecture d'Ethereum. Plutôt que de valider les blocs en réexécutant chaque transaction, le réseau prépare une voie alternative où les validateurs confirment l'exactitude en vérifiant des Preuve à divulgation nulle de connaissance.

Ce travail s'inscrit dans la feuille de route Layer-1 d'Ethereum pour 2026 et représente un changement structurel dans la manière dont le consensus peut être atteint, et non une nouvelle fonctionnalité de mise à l'échelle ajoutée en périphérie.

La proposition a été rendue publique après qu'un membre de l'Ethereum Foundation, connu sous le nom de ladislaus.eth, a exposé les progrès vers une conception L1-zkEVM. Ce changement ne modifie pas la manière dont les blocs sont produits ni ce que les utilisateurs soumettent on-chain. Au lieu de cela, il modifie la manière dont les validateurs décident si un bloc est valide. Le premier atelier L1-zkEVM est prévu pour le 11 février 2026, marquant le début formel de la coordination autour de cet effort.

De la réexécution complète à la vérification de preuve

Aujourd'hui, tout validateur qui souhaite attester un bloc doit réexécuter chaque transaction qu'il contient. Chaque nœud répète indépendamment le même calcul, vérifie les mêmes transitions d'état et stocke le même état d'exécution. Ce modèle existe depuis la genèse d'Ethereum, mais il évolue de manière linéaire avec l'activité. Des limites de gas plus élevées augmentent la charge de calcul, la taille de l'état et les exigences en bande passante pour chaque participant.

L'alternative en cours de développement remplace le calcul répété par une vérification cryptographique. Au lieu de réexécuter les transactions, un validateur vérifie une Preuve à divulgation nulle de connaissance compacte montrant que l'exécution a été effectuée correctement. Le temps de vérification reste à peu près constant quelle que soit la complexité interne du bloc. C'est l'idée centrale derrière les preuves zkEVM, désormais intégrées directement dans le flux de travail de consensus d'Ethereum.

Fonctionnement du pipeline L1-zkEVM

Dans la conception actuelle, un client d'exécution produit un Execution Witness, un ensemble de données autonome suffisant pour valider la transition d'état d'un bloc sans détenir l'état d'exécution complet. Un programme invité standardisé consomme ce témoin et vérifie l'exactitude de l'exécution. Une zkVM exécute ce programme et génère une preuve attestant que l'exécution a suivi les règles d'Ethereum.

Les clients de consensus peuvent alors vérifier cette preuve au lieu d'invoquer un client d'exécution complet. Les validateurs qui choisissent cette voie sont appelés zkAttesters. Il est important de noter que cette voie est optionnelle. Les validateurs peuvent continuer à réexécuter les blocs exactement comme ils le font aujourd'hui.

Ce mécanisme est formalisé dans l'EIP-8025 (Optional Execution Proofs). La proposition ne nécessite pas de hard fork et n'oblige pas les validateurs à adopter la validation basée sur les preuves. Elle ajoute un chemin de vérification parallèle à la réexécution.

Intégration du consensus et diversité des clients

L'EIP-8025 spécifie comment les preuves circuleraient sur le réseau peer-to-peer. Les preuves d'exécution provenant de différentes implémentations de clients sont diffusées sur un sujet dédié. Lors du traitement d'un bloc, un zkAttester peut vérifier ces preuves au lieu d'appeler un client d'exécution.

L'hypothèse de travail actuelle est un seuil de 3 sur 5. L'exécution d'un bloc est acceptée une fois que trois preuves indépendantes sur cinq sont vérifiées avec succès. Ce seuil peut évoluer, mais l'intention est claire : préserver la diversité des clients d'exécution tout en permettant la validation basée sur les preuves. La diversité reste une caractéristique au niveau du protocole plutôt qu'un choix opérationnel.

Pourquoi cela importe pour les validateurs

Un zkAttester n'a pas besoin de stocker l'état d'exécution ni de synchroniser la chaîne complète de la couche d'exécution. La synchronisation se réduit au téléchargement des preuves récentes depuis le dernier point de contrôle finalisé. Cela réduit considérablement les exigences matérielles pour participer au consensus.

Pour les stakers solo et les validateurs domestiques, cela est significatif. Exécuter un validateur aujourd'hui nécessite de maintenir à la fois un client de consensus et un client d'exécution gourmand en ressources. La vérification de preuve remplace la réexécution, réduisant les besoins en stockage, calcul et bande passante. Cela abaisse la barrière à l'entrée sans affaiblir les garanties de vérification.

Les implications vont au-delà des attesteurs. Parce que les preuves zkEVM sont sans état, vérifier Ethereum localement sur du matériel grand public devient à nouveau plus accessible. Le principe « ne faites pas confiance, vérifiez » est renforcé plutôt que dilué.

Dépendances et contraintes temporelles

Un prérequis est important. La génération de preuves nécessite du temps, et sans pipelining, la fenêtre est trop étroite. C'est là que l'ePBS (Enshrined Proposer-Builder Separation) devient pertinent. Ciblé pour le prochain hard fork Glamsterdam, l'ePBS étend la fenêtre de preuve d'environ une à deux secondes à environ six à neuf secondes. Cette extension rend la génération de preuves à slot unique beaucoup plus réaliste.

Sans ePBS, la vérification de preuve L1 reste contrainte. Avec elle, la conception devient opérationnellement viable.

Qui est impacté

Les équipes de clients de la couche d'exécution gagnent une nouvelle surface de preuve, chaque client devenant une source potentielle de preuve. La conception du prouveur reste une question ouverte. Concentrer la preuve dans un petit ensemble de constructeurs sophistiqués introduit des risques de vivacité, tandis qu'une preuve entièrement distribuée soulève des défis de performance et de coordination. L'objectif de conception est explicite : la preuve doit rester viable en dehors des grands centres de données.

Les fournisseurs de zkVM qui prouvent déjà les blocs Ethereum gagnent une interface standardisée sur laquelle construire. Les équipes Layer-2 en bénéficient également. Une fois que les preuves d'exécution sont vérifiées par les validateurs, les mêmes preuves peuvent servir les rollups natifs via une infrastructure partagée.

En fin de compte, les utilisateurs bénéficient d'une vérification moins coûteuse, d'une participation plus large des validateurs et de limites de gas réalisables plus élevées sans pression de centralisation.

Statut actuel

L'EIP-8025 est entré dans la branche des fonctionnalités consensus-specs et progresse vers le statut de proposition. La feuille de route L1-zkEVM pour 2026 est désormais publique, structurée autour de la standardisation des témoins d'exécution, des interfaces zkVM, de l'intégration du consensus, de l'infrastructure de preuve, de l'analyse comparative et de la vérification formelle de la sécurité.

L'atelier du 11 février 2026 marque le début d'une coordination ciblée sur ces volets. Ce n'est pas une mise à niveau qui fait la une des journaux, mais elle est fondamentale. Si Ethereum met à l'échelle sa couche d'exécution sans augmenter les exigences des validateurs, c'est ainsi que cela se produit.

L'article Ethereum se prépare à valider des blocs sans les exécuter – Voici comment est apparu en premier sur ETHNews.