La feuille de route d’Ethereum pour 2026 s’articule autour de deux axes : augmenter la capacité de données des rollups via les blobs tout en poussant l’exécution de la couche de base plus haut via des modifications de la limite de gas.
Ces modifications de la limite de gas dépendent du passage des validateurs de la ré-exécution des blocs à la vérification de preuves d’exécution ZK.
Le premier axe est déjà ancré par Fusaka, qui a été déployé le 3 décembre 2025.
Fusaka
Fusaka met en place PeerDAS ainsi que des modifications des paramètres blob uniquement (BPO) qui peuvent augmenter le débit des blobs par étapes mesurées, selon ethereum.org.
Le second axe est moins mécanisé car il repose sur des EIP en projet, l’implémentation par les clients et les opérations des validateurs, qui doivent rester dans les contraintes de décentralisation, notamment la bande passante, la propagation des blocs et la structure du marché des preuves.
PeerDAS est positionné comme le levier le plus clair de « montée en capacité » car il est conçu pour faire évoluer la disponibilité des données des rollups sans forcer chaque nœud à télécharger chaque blob.
Selon ethereum.org, les cibles blob n’augmentent pas immédiatement à l’activation, puis peuvent doubler toutes les quelques semaines jusqu’à une cible maximale de 48, tandis que les développeurs surveillent la santé du réseau.
L’équipe d’Optimism a présenté le scénario haut de gamme comme « au moins 48 cibles blob par bloc », associé à une augmentation côté rollup du débit d’environ 220 à environ 3 500 UOPS sous cette cible, selon optimism.io.
Même dans ce cadre, la question pratique pour 2026 est de savoir si la demande se matérialisera sous forme d’utilisation de blobs plutôt que de surenchérir sur l’exécution L1.
Une autre question ouverte est de savoir si la stabilité du réseau pair-à-pair et la bande passante des nœuds resteront dans les tolérances des opérateurs à mesure que le déploiement des BPO augmente.
Du côté de l’exécution, Ethereum teste déjà un débit plus élevé via la coordination plutôt que par un hard fork.
GasLimit.pics a rapporté une dernière limite de gas de 60 000 000, avec une moyenne sur 24 heures d’environ 59 990 755 à l’heure indiquée.
Ce niveau est important car il fournit un point de référence pour ce que les validateurs ont accepté en pratique.
Il expose également le plafond de la « scalabilité sociale » avant que la latence, la charge de validation, et la pression sur le mempool et le pipeline MEV ne deviennent contraignantes.
Une manière simple de traduire les discussions sur la limite de gas en plages de débit est le gas par seconde, en utilisant le temps de slot de 12 secondes d’Ethereum (gas par seconde = limite de gas divisée par 12).
Les chiffres ci-dessous explicitent le calcul et distinguent les transactions EVM de la couche de base des affirmations de débit des rollups.
| Scénario | Limite de gas | Gas/sec (≈ gas/12) | Tx/sec à 21k gas | Tx/sec à 120k gas |
|---|---|---|---|---|
| Niveau de coordination actuel | 60 000 000 | 5 000 000 | ≈238 | ≈42 |
| Cas limite ×2 | 120 000 000 | 10 000 000 | ≈476 | ≈83 |
| Cas haut de gamme (nécessite un changement de validation) | 200 000 000 | 16 666 667 | ≈793 | ≈139 |
Glamsterdam
La marque de la mise à niveau prévue pour 2026 regroupe plusieurs idées orientées exécution sous le nom de « Glamsterdam », une liste abrégée qui a été discutée autour de la séparation intégrée proposant-constructeur (ePBS, EIP-7732), des listes d’accès au niveau du bloc (BAL, EIP-7928) et de la tarification générale (EIP-7904).
Chacune reste à l’état de projet, selon les pages EIP pour EIP-7732, EIP-7928 et EIP-7904.
La tarification cible les décalages du plan de gas qui persistent depuis des années.
Elle soutient que corriger le prix erroné du calcul peut augmenter le débit utilisable tout en reconnaissant le risque de DoS et la réalité des contrats qui codent en dur des hypothèses de gas, selon EIP-7904.
Les BAL sont présentées comme l’infrastructure pour le parallélisme.
L’EIP cite les lectures de disque parallèles, la validation de transactions parallèles, le calcul parallèle de la racine d’état et les « mises à jour d’état sans exécution », tout en estimant une taille moyenne compressée des BAL d’environ 70 à 72 KiB en surcharge, selon EIP-7928.
En pratique, ces gains ne se matérialisent que si les clients adoptent la concurrence sur les véritables goulots d’étranglement.
Ils dépendent également du fait que les données et étapes de vérification supplémentaires n’entraînent pas leur propre taxe de latence.
L’ePBS se trouve au centre des discussions à la fois sur le MEV et le débit, car il vise à découpler dans le temps la validation de l’exécution de la validation du consensus, selon EIP-7732.
Ce délai temporel est aussi là où de nouveaux modes de défaillance peuvent apparaître.
Un article académique sur le « problème d’option gratuite » pour l’ePBS estime l’exercice de l’option à environ 0,82 % des blocs en moyenne sous une fenêtre d’option de 8 secondes, atteignant environ 6 % les jours de forte volatilité dans ses conditions modélisées, selon arXiv.
Ethereum en 2026
Pour la planification 2026, cette recherche attire l’attention sur la disponibilité sous contrainte, et pas seulement sur les résultats de frais en régime stable.
Le pari plus structurel derrière les limites de gas « très élevées » est l’adoption des preuves ZK par les validateurs.
La feuille de route « Realtime Proving » de la Fondation Ethereum décrit un chemin par étapes où un petit ensemble de validateurs exécute d’abord des clients ZK en production.
Ensuite, seulement après qu’une supermajorité de stake est à l’aise, les limites de gas peuvent augmenter à des niveaux où la vérification de preuve remplace la ré-exécution pour une validation pratique sur du matériel raisonnable, selon le post du 10 juillet 2025 de la fondation sur blog.ethereum.org.
Le même post expose des contraintes importantes pour la faisabilité plutôt que pour le récit, notamment viser une sécurité de 128 bits (avec 100 bits acceptés temporairement), une taille de preuve inférieure à 300 KiB et éviter de dépendre d’emballages récursifs avec des configurations de confiance, selon blog.ethereum.org.
L’implication en matière de scalabilité est liée aux marchés de preuve : l’offre de preuves en temps réel doit être bon marché et crédible sans se concentrer en un ensemble étroit de prouveurs qui recréerait les dépendances de type relay d’aujourd’hui dans une autre couche de la pile.
Après Glamsterdam, « Hegota » est positionné comme un créneau nommé pour fin 2026, qui reste davantage lié au processus qu’au périmètre.
La Fondation Ethereum a publié un calendrier pour les propositions phares avec une fenêtre de proposition du 8 janvier au 4 février, suivie d’une discussion et finalisation du 5 au 26 février, puis une fenêtre pour les propositions non phares, selon blog.ethereum.org.
Un méta-EIP Hegotá existe en projet (EIP-8081) et liste des éléments comme étant considérés plutôt que verrouillés, y compris FOCIL (EIP-7805) actuellement considéré, selon EIP-8081.
La valeur immédiate de ce calendrier pour le reporting est qu’il crée des points de décision datés que les investisseurs et les développeurs peuvent suivre sans déduire d’engagements des noms de code.
Le premier est que les propositions phares pour Hegota se clôturent le 4 février.
L’article La feuille de route 2026 d’Ethereum inclut ce risque pour les validateurs, plus important qu’on ne le pense est apparu en premier sur CryptoSlate.
