Glamsterdam : pourquoi l'ePBS retarde le fork d'Ethereum

Le prochain hard fork d'Ethereum, Glamsterdam, ne verra pas le jour cet été : la Ethereum Foundation l'a repoussé à la seconde moitié de 2026 — fin août dans le meilleur des cas, sans date de mainnet annoncée — et le goulot d'étranglement a un nom : l'EIP-7732, plus connu sous le nom d'ePBS. L'ePBS (enshrined Proposer-Builder Separation, ou séparation proposant-constructeur inscrite dans le protocole) est la pièce maîtresse qui réécrit la manière dont les blocs d'Ethereum sont construits. Sa complexité — couplée à une interaction encore non testée avec les nouvelles listes d'accès au niveau du bloc — est ce qui a freiné le calendrier. Pour les grands stakers institutionnels qui concentrent aujourd'hui une part importante du réseau — Lido avec environ 8,72 millions d'ETH et Coinbase avec près de 4,5 millions — il ne s'agit pas d'un détail technique lointain : l'ePBS change radicalement la structure de dépendance de leur activité de construction de blocs. Cet article explique les raisons de ce retard, les changements opérationnels pour ceux qui pratiquent le staking et la chronologie réelle des devnets vers le mainnet.

Qu'est-ce que Glamsterdam exactement et qu'apporte l'ePBS ?

Glamsterdam est le nom de code du hard fork (mise à jour du réseau nécessitant que tous les nœuds adoptent simultanément les nouvelles règles) qui succède à Pectra, activé sur le mainnet le 7 mai 2025. Ce pack combine plusieurs améliorations, mais celle qui domine les débats et dicte le rythme est l'EIP-7732, ePBS.

Pour comprendre l'ePBS, il convient de fixer quatre termes. Le proposer est le validateur à qui le protocole attribue le tour de proposer le bloc suivant. Le builder est celui qui assemble le contenu de ce bloc : il ordonne les transactions pour maximiser leur valeur. Le MEV (Maximal Extractable Value, valeur maximale extractible) est précisément cette valeur qui peut être capturée en réordonnant, incluant ou excluant des transactions au sein d'un bloc. Et le relay est l'intermédiaire externe qui connecte aujourd'hui builders et proposers pour que la répartition soit fiable sans que le contenu du bloc ne soit révélé à l'avance.

L'analogie la plus parlante est la suivante : le proposer choisit le menu — quel slot sera servi et sous quelles conditions —, mais le builder est celui qui cuisine le plat, décide de l'ordre des ingrédients et conserve le pourboire du MEV. Aujourd'hui, cette répartition entre celui qui choisit le menu et celui qui cuisine est arbitrée par un intermédiaire de confiance hors protocole : le relay, au sein du système MEV-Boost. L'ePBS intègre cet arrangement directement dans les règles d'Ethereum : le marché des builders ne dépend plus de relays externes et devient inscrit (d'où le terme « enshrined ») dans le protocole lui-même. La mécanique économique expliquant pourquoi cette répartition est cruciale — et comment le MEV est passé du statut de fléau à celui de composante inscrite et redistribuée — est développée dans notre analyse de l'Ère III du MEV ; les débutants trouveront les bases dans notre guide sur ce qu'est le MEV.

Parallèlement à l'ePBS, Glamsterdam incorpore l'EIP-7928 (Block-Level Access Lists, BALs), qui joint à chaque bloc la liste des comptes et du stockage que les transactions vont solliciter, permettant une exécution plus parallèle ; ainsi qu'un paquet de réajustement des prix du gas (gas repricing, dont l'EIP-7904 est l'un des principaux concernés). FOCIL (Fork-Choice Inclusion Lists), qui était pressenti, a été déplacé vers Hegotá, le fork suivant, précisément pour ne pas surcharger Glamsterdam.

Pourquoi Glamsterdam a-t-il été retardé ?

Ce retard n'est pas un échec : c'est une mesure de prudence technique. L'ePBS est l'une des modifications les plus invasives de la couche de consensus depuis la transition vers la Preuve d'Enjeu, car elle modifie le flux par lequel un bloc passe de la proposition à la confirmation. Deux causes techniques concrètes expliquent ce glissement de calendrier.

La première est la complexité intrinsèque de l'implémentation de l'EIP-7732. Faire en sorte que la répartition proposer-builder vive au sein du protocole oblige à coordonner des paiements « trustless » (sans intermédiaire de confiance) entre les deux parties, à redéfinir comment et quand le payload du bloc est validé, et à s'assurer que tous les clients de consensus implémentent la même logique de manière compatible. Ce n'est pas un code qui se teste en un après-midi.

La deuxième est l'interaction non testée à l'échelle du mainnet entre l'ePBS et les BALs (EIP-7928). Prises séparément, ces évolutions sont gérables ; le problème est qu'elles se chevauchent. Les BALs anticipent quels comptes et stockages seront touchés par chaque transaction pour paralléliser l'exécution, tandis que l'ePBS sépare le moment où un bloc est engagé du moment où son payload est validé. Combiner les deux crée de nouveaux chemins d'exécution — ce que l'on sait du contenu du bloc et à quel moment — qui ne se révèlent que sous une charge réelle et avec de nombreux clients différents communiquant entre eux. C'est pourquoi le processus prend le temps nécessaire sur les devnets avant de passer aux testnets publics : une faille de consensus ici n'est pas un simple bug, c'est une bifurcation de la chaîne.

À cela s'est ajoutée une décision stratégique. L'équipe d'ingénierie de Base (le L2 de Coinbase) a averti que l'inclusion de FOCIL en plus de l'ePBS aurait repoussé le fork au-delà de 2026. La réponse a été de retirer FOCIL du paquet pour le transférer vers Hegotá. C'est cette logique qui a guidé tout le redesign de Glamsterdam : au lieu de vouloir tout inclure au risque d'un fork impossible à finaliser, le périmètre est limité à l'ePBS plus les deux EIP de support (BALs et gas repricing), le reste étant reporté. Réduire l'ambition pour protéger la date est, en soi, un signe de maturité du processus.

Il convient de préciser le cadre temporel pour éviter les titres trompeurs. ethereum.org classe déjà Glamsterdam comme une mise à jour de la seconde moitié de 2026. L'objectif interne ambitieux se situe autour de fin août 2026, sans date de mainnet annoncée, avec un risque réel de glissement vers le quatrième trimestre si l'ePBS nécessite plus d'itérations sur testnet. Il ne s'agit pas d'un retard par rapport à la fenêtre prévue : le fork reste dans sa tranche de la seconde moitié de 2026, mais avec sa pièce la plus lourde encore en phase de consolidation.

Qu'est-ce qui change opérationnellement pour Lido et Coinbase ?

C'est ici que se trouve le véritable enjeu, car cela affecte ceux qui concentrent le réseau. Aujourd'hui, plus de 90 % du marché des builders opère via MEV-Boost, avec des relays externes d'acteurs comme Flashbots ou bloXroute (avec Commit-Boost qui gagne du terrain, autour de 20 % d'adoption comme alternative middleware). Cela signifie qu'un grand opérateur de staking, lorsqu'il doit proposer un bloc, n'en construit pas le contenu : il le met aux enchères auprès des builders via un relay et conserve l'offre la plus haute. La construction de blocs — et la capture de MEV associée — est externalisée à une poignée d'intermédiaires hors protocole.

L'ePBS réécrit cette dépendance. En inscrivant le marché des builders dans le protocole, la répartition proposer-builder ne nécessite plus de relay de confiance : Ethereum lui-même garantit que le proposer est payé et que le builder livre. Pour Lido, Coinbase et tout grand opérateur, cela change le point de contrôle et le profil de risque de leur activité de construction de blocs — moins de dépendance vis-à-vis des infrastructures tierces, des règles de répartition plus prévisibles —, bien que le redesign introduise de nouvelles exigences (par exemple, du capital immobilisé pour les builders inscrits) dont l'effet sur la concurrence du marché des builders est l'un des points de débat.

Le contexte explique pourquoi cela pèse tant : le staking d'Ethereum est à des sommets, et le marché surveille de près l'architecture de validation. Lido domine avec environ 8,72 millions d'ETH (environ 24 % du staking total) et Coinbase gère près de 4,5 millions (environ 12 %, données du premier trimestre 2026). Ce contexte de staking record est analysé dans notre article sur la paradoxe staking-ETF, et l'état spécifique de Lido dans staking institutionnel avec stETH. Le fait que le plafond par validateur soit passé de 32 à 2 048 ETH avec Pectra (EIP-7251) n'a fait que concentrer davantage de stake par nœud, rendant plus urgente la résolution de la centralisation de la construction de blocs que l'ePBS cherche à combattre.

Qui est le plus affecté par ce changement et de quelle manière ?

L'impact n'est pas uniforme. Il convient de le segmenter par type d'acteur, car chacun aborde l'ePBS depuis une position différente.

La répartition inégale comporte une nuance importante pour les builders. Aujourd'hui, une poignée de builders professionnels capture la majorité du flux de MEV car ils contrôlent la relation avec les relays et l'infrastructure d'enchères. L'ePBS n'élimine pas l'avantage du builder spécialisé — ordonner des transactions pour extraer de la valeur reste un métier d'échelle —, mais en inscrivant les règles dans le protocole et en exigeant un capital immobilisé pour les builders inscrits, il modifie les leviers de la concurrence. Savoir si cette barrière de capital consolidera les géants ou, au contraire, ouvrira la voie à de nouveaux entrants en supprimant le relay comme garde-barrière, est précisément le point que personne ne peut encore affirmer avec certitude et que le débat de Sigma Prime a laissé ouvert.

Pour l'investisseur qui n'opère pas de nœuds, l'élément pertinent est que le marché surveille la date de Glamsterdam comme un signal sur la santé de la roadmap d'Ethereum. Des analyses baissières comme celle de JPMorgan sur la sous-performance structurelle de l'ETH utilisent justement l'exécution de la roadmap comme l'un de leurs axes : un retard ordonné et communiqué n'est pas la même chose qu'un retard chaotique, et les équipes privilégient la première option. Le staker qui délègue à Lido ou Coinbase ne remarquera rien de tout cela dans son rendement quotidien ; ce qui change, c'est la solidité de l'infrastructure sur laquelle repose ce rendement.

Y a-t-il un consensus pour inclure l'ePBS dans ce fork ?

Pas totalement, et cette tension est instructive. Le débat le plus cité provient de Sigma Prime, l'entreprise derrière le client de consensus Lighthouse, et il convient de le rapporter avec précision car la position de la structure n'était pas monolithique. En interne, il y a eu des désaccords : Dapplion a argumenté contre l'inscription de l'EIP-7732 dans Glamsterdam, soutenant qu'inscrire la séparation proposer-builder aujourd'hui est inutile — MEV-Boost fonctionne avec des incidents minimes, une partie des bénéfices de mise à l'échelle est atteinte avec le « payload split + delayed execution » sans besoin de paiements trustless, et le réseau peut se permettre d'attendre un cycle de fork supplémentaire. Sa nuance : « s'il faut envoyer une forme d'ePBS maintenant, je voterai pour programmer l'EIP-7732 pour Glamsterdam », le reconnaissant comme la spécification la plus mature disponible.

Face à cette position, Mark Mackey l'a défendu comme la tête d'affiche du fork, et l'entreprise a fini par soutenir son inclusion. En d'autres termes : ce n'est pas « Sigma Prime contre », mais un débat interne résolu par l'affirmative, avec des arguments sérieux des deux côtés qu'il est utile de connaître avant de lire des titres simplistes. Le cœur de la discussion — doit-on inscrire l'ePBS maintenant ou attendre ? — est exactement ce qu'une analyse superficielle ne peut distiller sans avoir lu les sources primaires. CleanSky ne prend pas parti : nous exposons que la prudence du calendrier et l'existence même de ce débat expliquent pourquoi le fork avance lentement, mais avec une révision technique rigoureuse.

Quelle est la chronologie réelle des devnets vers le mainnet ?

Le chemin d'un changement de consensus sur Ethereum suit des phases bien définies : d'abord les devnets (réseaux de test internes des équipes clients), puis les testnets publics (Sepolia, Hoodi) et enfin le mainnet. Glamsterdam est encore dans la première phase.

• Tout au long de 2024 — MEV-Boost consolide sa domination sur la construction de blocs (plus de 90 % du marché des builders).
• 7 mai 2025 — Pectra est activé sur le mainnet ; le plafond par validateur passe de 32 à 2 048 ETH (EIP-7251).
• Début 2026 — Glamsterdam se dessine comme le prochain fork, avec l'ePBS (EIP-7732) comme pièce maîtresse.
• ~Première semaine de mai 2026 — Fin du devnet Soldøgn (phase d'interopérabilité entre clients) ; Devnet-4 est achevé.
• Juin 2026 (actuel) — devnets de Glamsterdam actifs (la ligne ePBS+BALs est encore en test) ; testnets publics (Sepolia, Hoodi) toujours en attente.
• Fin août 2026 (meilleur cas) — Objectif ambitieux d'activation, sans date de mainnet confirmée.
• Quatrième trimestre de 2026 (risque) — Fenêtre alternative si l'ePBS nécessite plus d'itérations sur testnet.

La lecture honnête de cette chronologie est que le progrès est réel mais que l'incertitude demeure sur la dernière ligne droite : le passage des devnets aux testnets publics est le prochain jalon à surveiller, et de sa fluidité dépendra si la fin août reste plausible ou si le fork glisse vers l'automne.

Que doit retenir le staker ?

Trois idées pour ceux qui pratiquent le staking ou investissent dans l'ETH. Premièrement, le retard de Glamsterdam est un signe de discipline, pas de décomposition : l'équipe préfère consolider l'ePBS sur les devnets plutôt que d'envoyer sur le mainnet une réécriture du flux de blocs avec des interactions non testées. Deuxièmement, le changement opérationnel de fond est que le marché des builders ne dépendra plus de relays externes — où se concentre aujourd'hui plus de 90 % du flux — pour être inscrit dans le protocole, ce qui réduit la dépendance aux tiers pour Lido, Coinbase et les validateurs indépendants. Troisièmement, la date n'est pas figée : fin août 2026 est le meilleur scénario, le quatrième trimestre est le risque, et l'indicateur à suivre est le passage des devnets aux testnets publics (Sepolia et Hoodi).

Pour ceux qui souhaitent approfondir la mécanique économique du MEV que l'ePBS réorganise, l'analyse complète est disponible dans notre dossier sur l'Ère III du MEV. Glamsterdam n'est pas la fin de cette histoire : c'est le moment où Ethereum décide d'intégrer le marché des builders au sein de ses propres règles.

Sources et liens : ethereum.org — roadmap Glamsterdam · Ethereum Foundation — Checkpoint #9 · Sigma Prime — débat sur l'EIP-7732 · Everstake — Glamsterdam expliqué · Figment — ce que cela signifie pour les stakers institutionnels