## Ethereum face une croisée critique dans sa feuille de route 2026 : le défi caché pour les validateurs

La stratégie de scalabilité d'Ethereum pour 2026 se bifurque en deux voies simultanées. D’un côté, l’augmentation de la capacité de données via des blobs ; de l’autre, la recherche d’améliorer la performance de la couche de base en ajustant les paramètres de gas. La complexité réside dans le fait que ces deux objectifs dépendent de changements fondamentaux dans la façon dont les validateurs traitent et vérifient l’information. Cette transition silencieuse comporte des risques opérationnels plus importants que ne le suggèrent les titres techniques.

## La première de Fusaka : premier pas dans la feuille de route

Fusaka, lancée le 3 décembre 2025, marque l’étape initiale. Cette mise à jour implémente PeerDAS ainsi que des ajustements granulaires des paramètres de blob (BPO). Contrairement aux changements radicaux, cette approche permet d’augmenter la performance par étapes mesurées, permettant à le réseau de s’adapter progressivement.

PeerDAS est la levier la plus directe pour augmenter la capacité : il permet aux rollups d’accéder à une plus grande disponibilité des données sans obliger chaque nœud à télécharger tous les blobs. Initialement, les objectifs de blobs ne sont pas immédiatement augmentés après l’activation. Par la suite, ils peuvent être doublés toutes les quelques semaines jusqu’à atteindre un maximum de 48 blobs par bloc, toujours sous surveillance de la santé du réseau.

Les données de l’équipe Optimism projettent une performance en rollups qui se multiplierait : environ de 220 à près de 3 500 UOPS sous cet objectif de 48 blobs. Cependant, une question pratique persiste pour 2026 : la demande réelle arrivera-t-elle sous forme d’utilisation de blobs, ou les enchères pour l’exécution en L1 continueront-elles à dominer ? De plus, la stabilité P2P et la consommation de bande passante des nœuds doivent rester dans des tolérances opérationnelles pendant que BPO augmente.

## Le plafond du scalabilité sociale : métriques de gas qui comptent

En parallèle, Ethereum expérimente avec une performance accrue via la coordination plutôt que par des hard forks. Le dernier enregistrement montre une limite de gas de 60 000 000, avec une moyenne sur 24 heures proche de 59 990 755. Ce niveau sert de référence à ce que les validateurs ont accepté de pratiquer. Il expose aussi la limite du « scalabilité sociale » avant que la latence, la charge de validation, la tension dans mempool et la compétition MEV ne deviennent limitants.

Convertir ces chiffres de gas en performance utilise l’intervalle de blocs de 12 secondes d’Ethereum. Le tableau des scénarios révèle :

**Scénario actuel de coordination** : limite de gas de 60 000 000 = ~5 000 000 gas/sec = ~238 transactions/sec (a 21k gas) ou ~42 transactions/sec (a 120k gas).

**Scénario 2× limite de gas** : limite de 120 000 000 = ~10 000 000 gas/sec = ~476 tx/s (a 21k) ou ~83 tx/s (a 120k).

**Scénario de performance maximale** (requiert changement de validation) : limite de 200 000 000 = ~16 666 667 gas/sec = ~793 tx/s (a 21k) ou ~139 tx/s (a 120k).

Ces échelles représentent le spectre théorique, mais chaque niveau introduit des complexités opérationnelles que les validateurs doivent absorber.

## Glamsterdam : la convergence de trois fronts d’exécution

Le nom clé « Glamsterdam » regroupe plusieurs propositions visant à optimiser l’exécution sous une bannière conceptuelle. Trois éléments clés restent en état de brouillon selon leurs pages EIP respectives :

**ePBS (EIP-7732) — Propositions-Construction Séparées Encriptées** : Détache temporairement la validation d’exécution de la validation de consensus. Cette flexibilité temporaire, bien que puissante pour la performance, est précisément là où peuvent se former de nouveaux modes de défaillance. La recherche académique sur le « problème de l’option gratuite » estime que les validateurs exerceraient des options dans environ 0,82 % des blocs en conditions normales, mais ce pourcentage grimpe à 6 % lors de jours de forte volatilité. Ces épisodes d’exercice d’option représentent des moments où le réseau subit une pression non linéaire.

**BALs (EIP-7928) — Listes d’Accès au Niveau de Bloc** : Se positionnent comme infrastructure pour le parallélisme. La proposition prévoit des lectures parallèles disque, validation concurrente des transactions, calcul parallèle de racine d’état et « mises à jour d’état sans exécution ». La surcharge moyenne estimée est de 70-72 KiB compressés par bloc. La différence entre théorie et pratique est significative : ces gains ne se matérialisent que si les clients implémentent une véritable concurrence dans les goulets d’étranglement réels. De plus, les données et étapes de vérification supplémentaires ne peuvent devenir leur propre impôt de latence.

**Réévaluation Générale (EIP-7904)** : Traite des déséquilibres chroniques dans le schéma de gas qui persistent depuis des années. La correction de calculs erronés de calcul pourrait augmenter la performance utilisable, mais comporte des risques d’attaques par déni de service et la réalité de contrats codant des hypothèses de gas spécifiques.

## Le vrai risque : la charge sur les validateurs

Voici le risque qui dépasse l’évidence : la transition de la réexécution des blocs à la vérification des preuves ZK n’est pas seulement un changement technique, mais une transformation opérationnelle profonde pour les validateurs.

La feuille de route « Realtime Proving » de la Fondation Ethereum décrit un déploiement progressif où d’abord un petit groupe de validateurs exécute des clients ZK en production. Ce n’est qu’après qu’une majorité de stake se sente à l’aise que les limites de gas puissent être élevées à des niveaux où la vérification des preuves remplace la réexécution comme mécanisme pratique en hardware raisonnable.

Les contraintes techniques importent plus que la narration : objectif de sécurité de 128 bits (avec 100 bits acceptés temporairement), taille de preuve inférieure à 300 KiB, et éviter les dépendances de wrappers récursifs avec des configurations de confiance. Plus critique encore, la scalabilité liée aux marchés de preuves exige que l’offre de preuves soit économique et crédible sans se concentrer sur un petit groupe de vérificateurs qui recréeraient des dépendances de type relais dans une autre couche de la pile.

## Hegota : calendrier visible pour des décisions cruciales

Après Glamsterdam, « Hegota » émerge comme une étiquette pour fin 2026, bien que son périmètre reste plus processuel que défini. La Fondation Ethereum a établi un calendrier explicite : fenêtre de propositions principales du 8 janvier au 4 février, suivie de discussions et finalisation du 5 au 26 février, avec une fenêtre ultérieure pour propositions non principales.

L’EIP méta de Hegota (EIP-8081) en état de brouillon liste des éléments « considérés » plutôt que fixés, incluant FOCIL (EIP-7805) actuellement en considération. La valeur immédiate réside dans la création de points de décision avec date que les investisseurs et développeurs peuvent suivre sans inférer d’engagements de noms en clé. La première étape critique : les propositions principales de Hegota se ferment le 4 février.

## La conclusion : une feuille de route qui exige une adaptation opérationnelle

La feuille de route d’Ethereum pour 2026 ne présente pas seulement des changements techniques, mais une reconfiguration du rôle du validateur. La transition de la coordination de performance sociale vers la dépendance aux preuves ZK, combinée à des augmentations de gas et un traitement parallèle accru, crée une fenêtre de vulnérabilité opérationnelle. Les validateurs ont besoin non seulement d’une nouvelle infrastructure ; ils doivent faire confiance à des marchés de preuves qui n’existent pas encore à grande échelle. C’est cette prémisse silencieuse qui rend les risques plus grands qu’ils ne paraissent en rétrospective technique.