Ethereum veut que les validateurs domestiques vérifient les preuves mais une réalité de 12 GPU soulève une nouvelle menace

Le chercheur Ethereum ladislaus.eth a publié la semaine dernière un guide expliquant comment Ethereum prévoit de passer de la ré-exécution de chaque transaction à la vérification de Preuve à divulgation nulle de connaissance.

Le post le présente comme une "transformation silencieuse mais fondamentale", et cette formulation est exacte. Non pas parce que le travail est secret, mais parce que ses implications se répercutent sur l'ensemble de l'architecture d'Ethereum de manières qui ne seront pas évidentes tant que les pièces ne seront pas connectées.

Il ne s'agit pas pour Ethereum "d'ajouter ZK" comme fonctionnalité. Ethereum prototypage une voie de validation alternative dans laquelle certains validateurs peuvent attester des blocs en vérifiant des preuves d'exécution compactes plutôt qu'en ré-exécutant chaque transaction.

Si cela fonctionne, le rôle de la couche 1 d'Ethereum passe de "règlement et disponibilité des données pour les Roll up" vers "exécution à haut débit dont la vérification reste suffisamment peu coûteuse pour les validateurs domestiques."

Ce qui est réellement en cours de construction

L'EIP-8025, intitulé "Optional Execution Proofs", a été publié sous forme de projet et spécifie les mécanismes.
Les preuves d'exécution sont partagées sur le réseau pair-à-pair de la couche de 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 stipule explicitement qu'elle "ne nécessite pas de Hard Fork" et reste rétrocompatible, tandis que les nœuds peuvent toujours ré-exécuter 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 : standardisation des témoins d'exécution et des programmes invités, standardisation de l'API zkVM-invité, intégration de la couche de consensus, infrastructure de prouveur, benchmarking et métriques, et sécurité avec vérification formelle.

Le premier appel de groupe de travail L1-zkEVM est prévu pour le 11 février à 15h00 UTC.

Le pipeline de bout en bout fonctionne comme suit : 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 détenir l'état complet.

Un programme invité standardisé consomme ce témoin et valide la transition d'état. Une zkVM exécute ce programme, et un prouveur génère une preuve d'exécution correcte. Le client de la couche de consensus vérifie ensuite cette preuve au lieu d'appeler le client de la couche d'exécution pour ré-exécuter.

La dépendance clé est ePBS (Enshrined Proposer-Builder Separation), ciblé pour le prochain Hard Fork Glamsterdam. Sans ePBS, la fenêtre de preuve est d'environ une à deux secondes, ce qui est trop serré pour une preuve en temps réel. Avec ePBS fournissant un pipelining de blocs, la fenêtre s'étend à six à neuf secondes.

Le compromis de décentralisation

Si les preuves optionnelles et les formats de témoins arrivent à maturité, davantage de validateurs domestiques peuvent participer sans maintenir l'état complet de la couche d'exécution.

L'augmentation des limites de gas 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 linéairement avec l'activité on-chain.

Cependant, la preuve comporte son propre risque de centralisation. Un post 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 préoccupations concernant la centralisation et note que les limites restent difficiles à prévoir. Si la preuve reste gourmande en GPU et se concentre dans les réseaux de constructeurs ou de prouveurs, Ethereum pourrait échanger "tout le monde ré-exécute" contre "peu prouvent, 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 attesteur 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 de clients 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 au matériel.

La formulation la plus honnête est qu'Ethereum déplace le champ de bataille de la décentralisation. La contrainte d'aujourd'hui est "pouvez-vous vous permettre d'exécuter un client de couche d'exécution ?" Celle de demain pourrait être "pouvez-vous accéder à des clusters GPU ou à des réseaux de prouveurs ?"

Le pari est que la vérification de preuve est plus facile à marchandiser que le stockage d'état et la ré-exécution, mais la question matérielle reste ouverte.

Déblocage de la scalabilité L1

La feuille de route d'Ethereum, dernièrement mise à jour le 5 février, liste "Statelessness" comme thème de mise à niveau majeur : vérifier les blocs sans stocker un état important.

Les preuves d'exécution optionnelles et les témoins sont le mécanisme concret qui rend la validation sans état pratique. Un nœud sans état ne nécessite qu'un client de consensus et vérifie les preuves lors du traitement de la charge utile.

La synchronisation se réduit au téléchargement de preuves pour les blocs récents depuis le dernier point de contrôle de finalisation.

Cela compte pour les limites de gas. Aujourd'hui, chaque augmentation de la limite de gas rend l'exécution d'un nœud plus difficile. Si les validateurs peuvent vérifier les preuves plutôt que de ré-exécuter, le coût de vérification n'évolue plus avec la limite de gas. La complexité d'exécution et le coût de validation se dissocient.

Le flux de travail de benchmarking et de réévaluation des prix dans la feuille de route 2026 cible explicitement les métriques qui mappent le gas consommé aux cycles de preuve et au temps de preuve.

Si ces métriques se stabilisent, Ethereum gagne un levier qu'il n'a jamais eu auparavant : la capacité d'augmenter le débit sans augmenter proportionnellement le coût d'exécution d'un validateur.

Ce que cela signifie pour les blockchains de couche 2

Un post récent de Vitalik Buterin soutient que les blockchains de couche 2 devraient se différencier au-delà du scaling et lie explicitement la valeur d'un "native rollup precompile" au besoin de preuves zkEVM enchâssées qu'Ethereum a déjà besoin pour mettre à l'échelle la couche 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 un precompile EXECUTE pour les Roll up natifs. L'infrastructure de preuve de la couche 1 devient une infrastructure partagée.

Cela modifie la proposition de valeur de la couche 2. Si la couche 1 peut évoluer vers un débit élevé tout en maintenant les coûts de vérification bas, les Roll up ne peuvent pas se justifier sur la base de "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é comme les Roll up qui s'appuient sur des conceptions de preuve rapide.

Le scénario dans lequel les couches 2 restent pertinentes est celui dans lequel les rôles sont répartis entre spécialisation et interopérabilité.

La couche 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 couche 2 articulent de nouvelles propositions de valeur et qu'Ethereum tienne sa feuille de route de vérification de preuve.

Trois voies à suivre

Il existe trois scénarios potentiels pour l'avenir.

Le premier scénario consiste en ce que la validation basée sur les preuves devienne courante. Si les preuves optionnelles et les formats de témoins arrivent à maturité et que les implémentations de clients se stabilisent autour d'interfaces standardisées, davantage de validateurs domestiques peuvent participer sans exécuter l'état complet de la couche d'exécution.

Les limites de gas augmentent car le coût de validation ne s'aligne plus sur la complexité d'exécution. Cette voie dépend de la convergence du flux de travail de standardisation ExecutionWitness et du programme invité vers des formats portables.

Le scénario deux est celui où la centralisation des prouveurs devient le nouveau point d'étranglement. Si la preuve reste gourmande 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 prouveurs.

Le protocole fonctionne toujours, car un prouveur honnête n'importe où 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 la couche 1 devienne une infrastructure partagée. Si l'intégration de la couche de consensus se durcit et que l'ePBS offre la fenêtre de preuve étendue, alors la proposition de valeur des couches 2 s'oriente vers des VM spécialisées, une latence ultra-faible et de nouveaux modèles de composabilité plutôt que "mettre à l'échelle Ethereum" uniquement.

Cette voie nécessite que l'ePBS soit livré dans les délais pour Glamsterdam.

La vue d'ensemble

La maturité de l'intégration des spécifications de consensus indiquera si les "preuves optionnelles" passent de principalement des TODO à des vecteurs de test durcis.

La standardisation de l'ExecutionWitness et du programme invité est la pierre angulaire de la portabilité de validation sans état entre clients. Les benchmarks qui mappent le gas consommé aux cycles de preuve et au temps de preuve détermineront si la réévaluation du gas pour la convivialité ZK est faisable.

Les progrès de l'ePBS et de Glamsterdam indiqueront si la fenêtre de preuve de six à neuf secondes devient une réalité. Les résultats des appels de groupe de travail révéleront si les groupes de travail convergent sur les interfaces et la sémantique minimale viable de distribution de preuves.

Ethereum ne passe pas bientôt à la validation basée sur les preuves. L'EIP-8025 stipule explicitement qu'il "ne peut pas encore baser les mises à niveau dessus", et le cadrage optionnel est intentionnel. En conséquence, il s'agit d'une voie testable plutôt qu'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 de groupe de travail avec les propriétaires de projet et rédigé un EIP avec des mécaniques de gossip pair-à-pair concrètes signifie que ce travail est passé de la plausibilité de la recherche à un programme de livraison.

La transformation est silencieuse car elle n'implique pas de changements spectaculaires dans l'économie des tokens ou de fonctionnalités orientées utilisateur. Mais elle est fondamentale car elle réécrit la relation entre la complexité d'exécution et le coût de validation.

Si Ethereum peut dissocier les deux, la couche 1 ne sera plus le goulot d'étranglement qui force tout ce qui est intéressant sur la couche 2.

Et si la vérification de preuve de la couche 1 devient une infrastructure partagée, l'ensemble de l'écosystème de couche 2 doit répondre à une question plus difficile : que construisez-vous que la couche 1 ne peut pas faire ?

Le post Ethereum wants home validators to verify proofs but a 12 GPU reality raises a new threat est apparu en premier sur CryptoSlate.