Fusaka prêt en testnets : cap sur glamsterdam et une hausse du gas limit

En bref

• Le déploiement du hard fork Fusaka est fixé en testnets : Holesky le 1er octobre, Sepolia deux semaines après, puis Khudai deux semaines plus tard.
• Le gas limit par défaut est porté à 60 millions via une proposition d’EIP (Ethereum Improvement Proposal) finalisée.
• L’utilisation des « blobs » de données a atteint l’objectif réseau, avec en moyenne ~6 blobs par bloc et une forte part d’activité provenant de certaines L2.
• Les équipes se tournent déjà vers Glamsterdam (prochaine série d’améliorations), avec un devnet prévu en octobre et une proposition pour formaliser des « EIP champions ».

Les développeurs d’Ethereum ont verrouillé le calendrier des testnets pour Fusaka, ouvrant la voie à une activation mainnet qui n’a pas encore de date définitive. L’actualité technique se double d’un arbitrage organisationnel : plus d’outils pour coordonner les EIP (propositions d’amélioration) et une attention renouvelée à la charge des validateurs et à l’efficacité du réseau.

Le détail technique

Fusaka introduit des ajustements autour des blobs — des unités de données destinées à améliorer l’efficacité du stockage et des données pour les rollups. Une série de blob parameter optimizations (BPO) sera activée une semaine après Fusaka sur chaque testnet pour affiner ces paramètres en conditions réelles. Sur la question de la disponibilité des données, la mise en œuvre principale, PeerDAS, vise à déployer un système de DAS (data availability sampling, soit l’échantillonnage de disponibilité des données) entre pairs : l’objectif est qu’aucun nœud unique n’ait besoin de télécharger l’intégralité des données pour valider la chaîne.

Le hard fork comporte aussi une augmentation du gas limit par défaut à 60 millions (validée via une EIP), ce qui ajuste la capacité des blocs sur la couche d’exécution. Parallèlement, des mécanismes envisagés pour Glamsterdam incluent l’ePBS (execution-layer proposer-builder separation, une séparation des rôles proposant et construisant les blocs) et les BALs (block access lists, listes d’accès aux blocs) pour mieux organiser l’accès aux données et réduire certains frictions MEV. MEV signifie maximal extractable value, la valeur pouvant être extraite par l’ordre et la sélection des transactions dans un bloc.

Réactions du marché

Techniquement orientées, ces décisions ont des effets concrets pour les opérateurs de nœuds et les validateurs : la hausse du gas limit et l’utilisation accrue des blobs augmentent l’utilité du réseau mais suscitent des inquiétudes sur l’empreinte de stockage des validateurs. Les données on-chain montrent une montée régulière de l’usage des blobs, portée en grande partie par quelques acteurs de couche 2, l’une d’elles représentant près de la moitié de l’espace blob observé récemment.

La promesse de PeerDAS et des BPO vise à atténuer ces tensions, mais son succès dépendra des tests à venir et des releases clients — le logiciel que les opérateurs installent. Les développeurs attendent ces versions imminentes pour permettre une adoption plus large du paramétrage 60M par les validateurs avant activation réelle de Fusaka.

Calendrier et prochaines étapes

• 1er octobre : activation Fusaka sur Holesky (testnet).
• Deux semaines plus tard : activation sur Sepolia, puis deux semaines après sur Khudai. Chaque testnet activera les BPO une semaine après Fusaka.
• Devnet pour Glamsterdam : calendrier provisoire en octobre, selon l’avancement des implémentations (ePBS, BALs notamment).
• Coordination : proposition d’un rôle d’« EIP champion » pour clarifier les responsabilités et prochain changement de modération des appels All Core Devs.

En somme, l’écosystème avance par étapes : testnets pour éprouver les mécanismes, sorties clients pour permettre l’adoption, puis activation mainnet quand le risque aura été jugé acceptable. L’équilibre entre capacité réseau, charge des validateurs et sécurité reste central pour la suite.

Partager sur vos réseaux !