Le chemin d'Ethereum 2026 : Défis des validateurs sous-estimés

La feuille de route d’Ethereum pour 2026 s’articule autour de deux stratégies fondamentales visant à évoluer simultanément en capacité de données et en exécution. Cependant, ces ambitions comportent des risques opérationnels pour les validateurs qui passent souvent inaperçus.

Les Deux Piliers de l’Escalabilité

Ethereum poursuit une voie duale : augmenter le throughput des blobs par des améliorations de la disponibilité des données, tout en étendant la capacité d’exécution en couche de base en ajustant la limite de gaz. Le problème est que la seconde voie dépend d’une technologie encore en phase expérimentale que les opérateurs de nœuds doivent adopter sans garanties immédiates de stabilité.

La première voie dispose déjà d’une ancre concrète avec Fusaka, déployé le 3 décembre 2025. Cette mise à jour introduit PeerDAS ainsi que des ajustements au paramètre de blobs (BPO), permettant des augmentations progressives des performances sans obliger chaque nœud à télécharger la totalité des données de blobs. Selon les directives d’ethereum.org, les objectifs de blobs ne sautent pas immédiatement après l’activation, mais peuvent se doubler toutes les quelques semaines jusqu’à atteindre un maximum de 48 blobs par bloc, tout en surveillant la santé du réseau.

L’équipe d’Optimism prévoit dans son scénario optimiste “au moins 48 blobs objectif”, ce qui impliquerait d’augmenter la performance du rollup d’environ 220 à près de 3 500 UOPS. Mais ici apparaît la première incertitude : la demande d’utilisation des blobs arrivera-t-elle réellement, ou les enchères compétitives pour l’exécution en L1 continueront-elles à escalader ?

Les Incertitudes de l’Infrastructure

La stabilité peer-to-peer et la bande passante des nœuds représentent des tensions réelles à mesure que le BPO augmente. GasLimit.pics rapporte une limite de gaz actuelle de 60 000 000, avec une moyenne sur 24 heures de 59 990 755 lors des observations. Ce chiffre sert de référence sur ce que les validateurs ont accepté en pratique, mais expose aussi le plafond du “scaling social” avant que la latence, la charge de validation et les pressions sur mempool ne deviennent restrictives.

Traduire le discours sur la limite de gaz à la vitesse des transactions nécessite d’utiliser l’intervalle de 12 secondes d’Ethereum. Sous la coordination actuelle, la performance est d’environ 238 transactions par seconde (a 21k gas) ou 42 (a 120k gas). Un scénario de 2× porterait ces valeurs à 476 et 83 respectivement, tandis que les niveaux plus élevés (requérant des changements de validation) atteindraient 793 et 139 Tx/sec.

Glamsterdam : Complexité Cachée

La mise à jour prévue pour 2026 regroupe des initiatives orientées vers l’exécution sous le nom “Glamsterdam”, qui englobe séparation du proposeur-construit (ePBS, EIP-7732), Listes d’Accès au Niveau de Bloc (BALs, EIP-7928) et réévaluation générale du gaz (EIP-7904). Toutes restent des brouillons.

La réévaluation du gaz vise à corriger des déséquilibres accumulés au fil des années dans le schéma tarifaire. EIP-7904 argumente que rectifier des erreurs de calcul pourrait augmenter la performance utilisable, tout en reconnaissant les risques de DoS et la réalité des contrats intelligents codant des hypothèses spécifiques de gaz.

Les BALs se positionnent comme une infrastructure pour un parallélisme véritable. L’EIP mentionne des lectures parallèles disque, une validation concurrente des transactions et un calcul parallèle de la racine d’état, estimant une surcharge d’environ 70-72 KiB par BAL compressé. Mais ces gains théoriques ne se concrétisent que si les clients adoptent la concurrence dans les véritables goulets d’étranglement.

ePBS occupe le centre des débats car il découple temporairement la validation de l’exécution de la validation du consensus, ouvrant des fenêtres pour de nouveaux modes de défaillance. La recherche académique sur le “problème de l’option gratuite” estime que l’exercice d’options dans une fenêtre de 8 secondes se produit en moyenne dans 0,82% des blocs, montant à 6% lors de volatilités extrêmes selon une analyse sur arXiv.

Le Rôle des ZK Proofs dans la Feuille de Route

L’enjeu le plus structurel derrière des limites de gaz significativement plus élevées repose sur l’adoption par les validateurs de preuves d’exécution ZK. La feuille de route “Realtime Proving” de la Fondation Ethereum décrit un déploiement progressif : d’abord un petit ensemble de validateurs exécute en production des clients ZK, puis, seulement après qu’une majorité qualifiée de stake soit à l’aise, les limites de gaz peuvent augmenter jusqu’à des niveaux où la vérification des preuves remplace la réexécution.

Les contraintes techniques importent plus que la narration : objectif de sécurité de 128 bits (100 bits acceptés temporairement), taille de preuve inférieure à 300 KiB, et éviter la dépendance à des enveloppes récursives avec des configurations fiables. La scalabilité résultante est liée aux marchés de tests : l’offre doit être peu coûteuse et crédible sans se concentrer sur des vérificateurs uniques recréant des dépendances de type relais dans une autre couche du stack.

Hegota et Calendrier Critique

“Hegota” se positionne comme une fenêtre temporelle pour fin 2026, plus axée sur le processus que sur l’étendue définitive. La Fondation Ethereum a fixé une fenêtre de propositions principales du 8 janvier au 4 février, une discussion du 5 au 26 février, puis une fenêtre pour des propositions secondaires.

Le meta-EIP de Hegota (EIP-8081) énumère des éléments comme “considérés” plutôt que “fixés”, incluant FOCIL (EIP-7805). La valeur réelle à court terme est qu’il crée des points de décision avec une date précise que les investisseurs et développeurs peuvent suivre sans inférer d’engagements de noms en code.

Le premier jalon critique : clôture des propositions principales de Hegota le 4 février. Ce calendrier offre une visibilité sur les éléments de la feuille de route d’Ethereum pour 2026 qui avanceront réellement vers la mise en œuvre versus ceux qui resteront en débat spéculatif.

Ce que les Validateurs Doivent Préparer à Confronter

Le risque pour les validateurs n’est pas catastrophique, mais il est multidimensionnel. La bande passante, la synchronisation de l’état, de nouvelles dépendances aux preuves ZK, et la possibilité que les fonctionnalités planifiées ne se matérialisent pas dans le calendrier attendu. La coordination sociale sur la limite de gaz a ses limites où la physique de la propagation des blocs et la capacité de validation deviennent restrictives, et personne ne peut simplement “mettre à jour” la vitesse de la lumière.

La vraie question que la feuille de route d’Ethereum pour 2026 pose aux opérateurs d’infrastructure est s’ils sont prêts à investir dans du matériel et des logiciels neufs pour une fonctionnalité qui pourrait être retardée ou ne pas être largement adoptée si la demande réelle du marché diverge des projections techniques.