Ethereum prépare Glamsterdam pour le quatrième trimestre 2026. Le fork n’a toujours pas de date mainnet définitive, mais le calendrier officiel fixe désormais le prochain jalon important au 6 octobre avec son activation sur Sepolia.

La mise à niveau est déjà testée sur des devnets ainsi que sur Platåberget, un réseau public temporaire créé spécifiquement pour donner aux développeurs, opérateurs de validateurs et fournisseurs d’infrastructure le temps de casser leurs outils avant que les mêmes changements atteignent les testnets longue durée.

Ce détail est important parce que Glamsterdam n’est pas simplement une collection de petites EIP indépendantes. Plusieurs de ses changements modifient directement des hypothèses que les outils Ethereum utilisent depuis des années.

Le bloc Ethereum actuel passe par une plomberie que le protocole ne contrôle pas entièrement

Le premier gros chantier s’appelle ePBS, pour enshrined Proposer-Builder Separation.

Ethereum sépare déjà largement deux fonctions : le validator sélectionné pour proposer un bloc et les builders spécialisés qui cherchent à construire le bloc le plus rentable.

Le problème est que cette séparation repose aujourd’hui en partie sur une infrastructure hors protocole, notamment des relais qui transmettent les blocs et les offres entre builders et proposers.

Le réseau bénéficie donc de la spécialisation des builders, mais une portion importante du mécanisme existe dans une couche intermédiaire que le consensus Ethereum lui-même ne peut pas entièrement vérifier.

EIP-7732 inscrit cette relation directement dans le protocole.

ePBS ne sert pas seulement à supprimer des intermédiaires

L’un des bénéfices les plus importants concerne le temps.

Dans l’architecture actuelle, une partie critique du traitement doit être diffusée et exécutée dans une fenêtre d’environ deux secondes.

Glamsterdam réorganise le calendrier du slot en séparant plus explicitement le bloc de consensus du payload d’exécution construit par le builder.

Selon la roadmap Ethereum, cette organisation fait passer la fenêtre disponible pour propager les données d’environ deux secondes à près de neuf secondes.

Ce n’est pas une réduction du temps d’un slot Ethereum. C’est davantage de temps utilisable à l’intérieur de ce slot pour transporter et vérifier des payloads importants.

Cette marge compte lorsque le réseau cherche à augmenter simultanément la quantité de données de Layer 2 et la capacité d’exécution L1.

Le builder devient un participant que le protocole peut réellement sanctionner

Intégrer la séparation proposer-builder permet également de déplacer le paiement du builder dans les règles du protocole.

Le proposer peut sélectionner une offre sans devoir simplement faire confiance à un relais externe pour garantir que le builder livrera correctement son payload.

Glamsterdam ajoute notamment des mécanismes de contrôle de disponibilité temporelle du payload.

Cette construction est plus complexe qu’un simple remplacement de logiciel middleware : le consensus doit maintenant savoir quoi faire si proposer et builder ne remplissent pas leurs obligations dans le bon ordre.

C’est précisément ce qui a rendu ePBS difficile à implémenter. Les équipes clients doivent gérer des situations intermédiaires où une partie d’un bloc existe alors que l’autre n’est pas encore disponible.

Les Block-Level Access Lists changent l’autre moitié du problème

ePBS s’intéresse beaucoup à la fabrication et à la propagation du bloc. Les Block-Level Access Lists, ou BAL, s’attaquent davantage à son exécution.

Aujourd’hui, un nœud qui exécute un bloc découvre progressivement les comptes et emplacements de stockage dont chaque transaction a besoin.

Cette dépendance encourage un traitement largement séquentiel : exécuter une opération permet de découvrir l’état dont la suivante dépend.

EIP-7928 ajoute au niveau du bloc une liste obligatoire des emplacements d’état accédés et des modifications produites.

Le nœud obtient donc à l’avance une carte beaucoup plus précise du travail à effectuer.

Connaître les dépendances à l’avance ouvre réellement la porte au parallélisme

Deux transactions complètement indépendantes n’ont pas nécessairement besoin d’attendre l’une après l’autre.

Si un client sait qu’elles touchent des comptes et slots de stockage différents, il peut préparer leur lecture ou une partie de leur traitement en parallèle sur plusieurs cœurs CPU.

Les BAL ne transforment pas magiquement l’EVM en moteur entièrement parallèle dès le jour du fork.

Elles fournissent en revanche l’information structurée qui manquait pour permettre aux clients d’exploiter progressivement ce parallélisme sans devoir deviner les dépendances pendant l’exécution.

Cette distinction est importante : Glamsterdam construit l’infrastructure du parallélisme avant de promettre que toutes les transactions seront soudain exécutées simultanément.

Un nœud pourrait aussi suivre l’état sans rejouer chaque transaction

Les Block-Level Access Lists ouvrent une deuxième piste : l’executionless sync.

Pour maintenir une vue correcte de l’état Ethereum, un nœud doit traditionnellement exécuter les transactions afin de calculer les changements qu’elles produisent.

Une BAL contient également les informations sur les changements d’état après exécution.

Cela permet d’envisager des nœuds qui mettent à jour leur état à partir des résultats vérifiés plutôt que de rejouer systématiquement chaque opération.

Tout le monde n’a pas besoin de cette méthode et elle ne remplace pas les nœuds qui vérifient réellement l’exécution.

Mais elle peut réduire fortement le coût de certaines formes de synchronisation et d’infrastructure.

Le troisième problème est moins visible : Ethereum accumule une base de données qui ne disparaît pas

Augmenter la limite de gas permet d’exécuter davantage d’opérations par bloc.

Toutes ces opérations n’ont pourtant pas le même coût matériel à long terme.

Une opération de calcul utilise du CPU pendant quelques instants puis disparaît. Créer un nouveau compte, un slot de stockage ou du bytecode peut augmenter l’état que les nœuds doivent conserver et consulter pendant des années.

Glamsterdam change donc également la façon dont le gas représente ces coûts.

EIP-8037 sépare le coût de création d’état

EIP-8037 augmente et harmonise le coût des opérations qui créent de nouveaux éléments persistants : comptes, slots de stockage et bytecode notamment.

Surtout, cette croissance est mesurée dans une dimension de state gas distincte.

Un transfert simple d’ETH vers un compte existant peut ainsi conserver son coût de base classique, tandis que créer un nouvel état peut engendrer une facturation supplémentaire.

L’objectif n’est pas simplement de rendre certaines transactions plus chères.

Il s’agit d’empêcher une hausse générale de la capacité d’exécution de produire mécaniquement une explosion de la base de données que chaque opérateur doit ensuite gérer.

EIP-8038 remet aussi à jour le prix de lire cet état

Ethereum n’avait pas largement recalibré certains coûts d’accès à l’état depuis le fork Berlin de 2021.

Entre-temps, cette base de données a grossi et les mesures réelles des clients ont évolué.

EIP-8038 augmente donc certains coûts associés à SLOAD, SSTORE, aux accès froids de comptes et à d’autres opérations liées à l’état afin que leur prix en gas reflète mieux leur coût réel pour le matériel.

La logique est simple : si le protocole sous-évalue une opération coûteuse, augmenter la limite globale de gas autorise trop de cette opération dans un seul bloc.

Une limite élevée n’est durable que si chaque unité de gas représente à peu près correctement le travail qu’elle permet d’acheter.

Le fameux objectif des 200 millions de gas vient de cette combinaison

Lors d’un interop organisé au printemps, les équipes Ethereum Foundation ont établi un objectif crédible d’environ 200 millions de gas après Glamsterdam.

Ce nombre n’est pas présenté comme une activation automatique au moment du fork.

Il représente un niveau que les développeurs considèrent techniquement défendable grâce à la convergence d’ePBS, des optimisations rendues possibles par les BAL et de la nouvelle tarification de l’état.

La différence avec une simple hausse de limite est essentielle.

Passer arbitrairement d’une capacité plus faible à 200 millions ferait travailler les nœuds beaucoup plus dur. Glamsterdam tente d’abord de rendre une unité de travail plus parallélisable, plus prévisible et mieux tarifée.

La nouvelle tarification peut casser quelques contrats

Une modification du gas touche nécessairement les logiciels qui ont supposé que certains coûts resteraient constants.

L’Ethereum Foundation a rejoué des transactions historiques avec les nouvelles règles afin d’identifier les incompatibilités.

La grande majorité s’exécute normalement, mais certains contrats utilisent des hypothèses codées en dur : stipends fixes, limites de gas pré-signées, branches conditionnelles basées sur gasleft() ou appels auxquels une quantité précise de gas est attribuée.

Dans beaucoup de cas, augmenter la limite suffit.

Une petite catégorie peut réellement devoir être modifiée avant Glamsterdam.

C’est l’une des raisons pour lesquelles Platåberget existe plusieurs mois avant le mainnet.

Certains wallets et indexeurs ont un problème encore plus banal

La nouvelle organisation du gas met aussi en lumière une hypothèse profondément installée dans certains outils : l’existence d’une limite maximale de gas simple et codée en dur.

L’Ethereum Foundation avertit explicitement que les wallets, indexeurs ou estimateurs qui reposent sur cette hypothèse peuvent casser et doivent être testés.

Ce genre de problème n’a rien de spectaculaire cryptographiquement.

Il illustre néanmoins pourquoi une évolution de protocole ne concerne jamais uniquement les logiciels validateurs. Des milliers de services ont construit leurs propres raccourcis autour du comportement historique du réseau.

Glamsterdam augmente aussi franchement la taille maximale des contrats

La mise à niveau prévoit de faire passer la taille maximale du bytecode déployé de 24 KiB à 64 KiB.

La limite de l’initcode passe de 48 KiB à 128 KiB.

Ces augmentations donnent davantage de latitude aux applications complexes et aux architectures de smart contracts qui devaient auparavant fragmenter davantage leur logique.

Elles arrivent en même temps qu’une tarification plus stricte de la création d’état, ce qui évite précisément de présenter la taille supplémentaire comme une ressource gratuite.

Le nom Glamsterdam cache en réalité deux mises à niveau

Comme plusieurs forks Ethereum modernes, Glamsterdam fusionne un nom de couche consensus et un nom de couche exécution.

Gloas désigne la partie consensus et Amsterdam la partie exécution.

Le premier apporte notamment ePBS. Le second porte entre autres les Block-Level Access Lists et les changements EVM.

Le nom combiné est donc moins fantaisiste qu’il n’en a l’air : il rappelle qu’Ethereum fonctionne depuis The Merge avec deux couches logicielles distinctes qui doivent évoluer ensemble.

Hegotá est déjà en préparation, mais certaines fonctions attendront volontairement

Ethereum développe désormais ses forks avec une cadence plus stricte après les difficultés rencontrées lorsque trop de fonctionnalités étaient concentrées dans une même mise à niveau.

La suivante, Hegotá, est déjà en phase de définition pour 2027.

La résistance à la censure via FOCIL doit notamment y jouer un rôle majeur.

Cela signifie que Glamsterdam ne tente pas de résoudre simultanément toute la roadmap Ethereum.

Les développeurs ont même gelé son périmètre, tout en précisant que des modifications restent techniquement possibles avant le mainnet si les tests découvrent un problème suffisamment important.

Le 6 octobre sera donc plus important que n’importe quelle rumeur de date mainnet

À ce stade, le calendrier officiel indique seulement le quatrième trimestre 2026 pour le mainnet.

Sepolia doit recevoir Glamsterdam le 6 octobre.

Une activation sur Hoodi et les dernières validations clients doivent suivre avant qu’une date définitive puisse être considérée comme sûre.

Les développeurs ont volontairement évité de fixer trop tôt un bloc ou un timestamp de mainnet.

ePBS modifie une portion suffisamment fondamentale de la production des blocs pour qu’un calendrier légèrement plus long coûte beaucoup moins cher qu’un fork précipité.

Pour un détenteur d’ETH, il n’y aura rien à convertir

Comme à chaque grand hard fork, l’Ethereum Foundation insiste sur un point destiné surtout à prévenir les arnaques.

Les ETH existants ne deviennent pas des « ETH Glamsterdam » et n’ont pas besoin d’être migrés, convertis ou envoyés vers une nouvelle adresse.

Les soldes restent dans l’état du réseau après la mise à niveau.

Ce sont surtout les opérateurs de nœuds, validateurs, développeurs d’outils et certains smart contracts qui doivent préparer des changements techniques.

Glamsterdam essaie finalement de déplacer la limite avant de pousser dessus

Ethereum veut davantage de capacité L1 et davantage de données pour les rollups.

La méthode la plus facile serait de demander aux nœuds d’accepter des blocs toujours plus lourds.

La méthode Glamsterdam consiste à gagner du temps de propagation avec ePBS, exposer les dépendances avec les BAL, paralléliser davantage le travail et faire payer correctement les opérations qui gonflent durablement l’état.

Ce n’est qu’après cette réorganisation que l’objectif d’environ 200 millions de gas devient raisonnable.

Le fork ne rendra donc probablement pas Ethereum quatre fois plus rapide le matin de son activation.

Il essaie surtout de modifier l’architecture pour que les prochaines hausses de capacité cessent d’être synonymes d’une hausse équivalente de la machine minimale nécessaire pour vérifier le réseau.