Ethereum doit faire passer Sepolia sous Glamsterdam le 6 octobre 2026.

La date figure toujours sur la roadmap officielle d’Ethereum, qui présente le fork comme le prochain jalon après les devnets et le réseau public temporaire Platåberget.

Le mainnet reste simplement ciblé pour le quatrième trimestre. Aucune date d’activation définitive n’est encore annoncée.

Quelques semaines avant Sepolia, les développeurs viennent pourtant d’identifier un scénario de test assez particulier autour d’ePBS.

Le problème commence avec le changement le plus important de Glamsterdam

ePBS, pour enshrined Proposer-Builder Separation, formalise dans le protocole la séparation entre deux rôles.

Le proposer est le validateur sélectionné pour proposer le bloc de consensus.

Le builder assemble de son côté le payload d’exécution contenant les transactions et propose une enchère pour que son bloc soit choisi.

Ethereum utilise déjà largement une séparation de ce type aujourd’hui, notamment au travers de MEV-Boost et de relais externes.

Glamsterdam déplace une partie essentielle de cette relation directement dans les règles du protocole via EIP-7732.

Le proposer peut choisir une offre avant de recevoir tout le payload

Cette séparation permet de résoudre plusieurs problèmes d’architecture.

Le builder peut s’engager à fournir un payload et effectuer le paiement prévu, tandis que le proposer n’a pas besoin de construire lui-même le bloc d’exécution.

Le protocole ajoute également un Payload Timeliness Committee chargé d’attester si le payload est arrivé dans la fenêtre prévue.

Cette nouvelle organisation agrandit fortement le temps disponible pour propager les données : Ethereum.org décrit un passage d’environ deux secondes à environ neuf secondes pour cette partie critique du slot.

C’est l’une des raisons pour lesquelles ePBS est considéré comme un élément de scaling plutôt qu’une simple réforme du marché du MEV.

Mais une enchère économique n’a pas tout à fait le même sens quand l’argent est gratuit

Sur Ethereum mainnet, un builder ne manipule pas de l’argent fictif.

Se comporter de manière irrationnelle peut coûter de la valeur réelle.

Sepolia possède une propriété différente : son ETH sert aux tests et peut être obtenu sans la rareté économique de l’ETH du mainnet.

Cette différence crée une situation que la théorie économique du protocole doit explicitement prendre en compte pendant les tests.

L’attaque consiste presque à gagner trop facilement

Le scénario discuté par les développeurs est conceptuellement simple.

Un opérateur crée un builder, lui fournit suffisamment de test ETH et soumet une offre beaucoup plus élevée que celles de builders normaux.

Le proposer sélectionne logiquement cette enchère.

Puis le builder ne publie pas le payload promis.

Au lieu d’utiliser la fonction pour construire un bloc rentable, l’attaquant l’utilise pour gagner le droit de ne rien fournir.

Une identité bannie ne suffit pas si l’attaquant peut simplement en fabriquer une autre

Le scénario devient surtout gênant lorsque les builders sont jetables.

Un attaquant peut créer de nouvelles identités et répéter le comportement plutôt que préserver la réputation d’un builder de production utilisé pendant des mois.

Lors d’un All Core Developers call, le développeur consensus Potuz a décrit la possibilité de lancer un grand nombre de builders, de les faire tourner, de soumettre des offres extrêmement hautes puis de ne pas produire les payloads.

La remarque visait précisément la facilité de reproduire cette nuisance sur un réseau où le capital nécessaire n’a presque aucune valeur économique.

Ce n’est pas un scénario qui permet de voler les ETH du mainnet

Il faut séparer très nettement les deux environnements.

Le problème discuté concerne la robustesse du test Sepolia.

Aucun fonds du mainnet n’est exposé par le simple fait qu’un builder de Sepolia retienne son payload.

Cela ne signifie pas non plus qu’un attaquant a découvert un moyen de contourner le consensus Ethereum pour produire arbitrairement un état invalide.

Le risque immédiat est surtout la disponibilité utile des blocs et la qualité du test.

Un bloc peut rester sans payload d’exécution utilisable

Avec ePBS, consensus et payload possèdent des étapes distinctes.

Si un builder remporte l’enchère puis refuse de révéler correctement son payload, le réseau doit gérer ce cas plutôt que supposer que la deuxième moitié arrivera toujours.

EIP-7732 est justement conçu avec des états où le payload peut être considéré comme retenu.

Le protocole doit rester cohérent même lorsque le builder n’est pas honnête.

La question soulevée pour Sepolia est davantage opérationnelle : combien de fois un acteur peut-il imposer ce chemin dégradé avant de rendre le réseau de test pénible à utiliser ?

Les clients disposent déjà de mécanismes de repli

Les développeurs ne partent pas de zéro.

Les implémentations prévoient des comportements permettant de continuer lorsque des payloads manquent, et les équipes testent précisément les scénarios pathologiques de consensus depuis les devnets.

La Fondation Ethereum avait d’ailleurs annoncé dès août qu’un devnet sans finalité serait utilisé pour pousser ce type de cas extrême.

Le problème discuté cette semaine porte sur la rapidité avec laquelle les logiciels peuvent cesser de faire confiance à un builder qui se comporte mal.

Écarter le builder devient aussi important que survivre au payload manquant

Si un client attend plusieurs échecs avant d’adopter un autre comportement, un attaquant peut obtenir plusieurs occasions de perturber la production.

Et si la sanction s’applique uniquement à une identité précise, le même opérateur peut revenir avec un nouveau builder.

Les développeurs discutent donc de la manière dont les clients pourraient mieux identifier et refuser les builders défaillants.

C’est une question différente de la sûreté cryptographique du consensus.

Le protocole peut rester sûr tout en devenant temporairement très désagréable à exploiter.

Un testnet n’est pas censé reproduire parfaitement l’économie du mainnet

C’est même une partie du paradoxe.

Le test ETH doit être facile à obtenir.

Sinon, tester un smart contract, un validateur ou une infrastructure nécessiterait d’acheter une ressource artificiellement rare sans valeur productive.

Mais dès qu’un mécanisme de protocole utilise le coût économique comme élément de défense, cette gratuité peut déformer le système que le testnet cherche à reproduire.

ePBS rend cette tension beaucoup plus visible parce que le builder devient lui-même une entité économique inscrite dans le protocole.

Sepolia sert précisément à découvrir ce genre de différence

Le scénario n’est pas nécessairement une raison de retarder Glamsterdam.

Une longue phase de test existe précisément pour faire apparaître des comportements qui ne ressortent pas dans un devnet très contrôlé.

Platåberget est public et accepte déjà des dépôts de builders et de validateurs.

Sepolia ajoute une infrastructure, des outils et des utilisateurs beaucoup plus proches du vrai écosystème de test Ethereum.

Le passage du laboratoire à ce réseau longue durée augmente donc volontairement le nombre de choses susceptibles de mal se passer.

Glamsterdam demande déjà aux outils d’apprendre un nouveau processus de construction des blocs

Le changement touche directement les infrastructures qui supposent que proposer et builder interagissent comme avant.

Les pools de staking, logiciels de validateurs, services de block building et systèmes de surveillance doivent comprendre les nouveaux messages et délais introduits par ePBS.

Les clients d’exécution et de consensus doivent eux aussi être mis à jour.

Ethereum.org classe ces mises à jour comme nécessaires pour rester synchronisé après le fork.

Et ePBS n’est qu’une partie de Glamsterdam

Le même fork apporte également les Block-Level Access Lists, une nouvelle tarification de l’état et plusieurs modifications des limites EVM.

Ces changements sont suffisamment larges pour que Platåberget soit ouvert depuis août aux développeurs d’applications en plus des opérateurs d’infrastructure.

La Fondation Ethereum avertit par exemple que certains wallets, indexeurs ou estimateurs de gas utilisant une limite maximale codée en dur devront être modifiés.

Sepolia ne servira donc pas uniquement à savoir si les builders livrent correctement leurs payloads.

Le calendrier laisse peu de place entre la release client et le fork

Selon le calendrier discuté par les développeurs, les équipes clientes visent des versions compatibles Sepolia pour le 29 septembre.

Le fork est prévu sept jours plus tard, le 6 octobre.

Ce délai est plus court que la fenêtre de quatorze jours habituellement recherchée pour les revues de sécurité et le bug bounty avant un testnet.

Les développeurs ont accepté cette contrainte en considérant notamment que Sepolia est plus facile à récupérer qu’un réseau de production en cas de problème.

Cela augmente néanmoins l’importance des tests conduits immédiatement après la publication des versions.

Hoodi reste l’étape suivante, pas le mainnet

Après Sepolia, les développeurs envisagent Hoodi comme second testnet longue durée.

Une date du 27 octobre a été évoquée de manière provisoire.

Elle dépendra des résultats observés sur Sepolia.

La roadmap officielle se contente toujours d’indiquer un mainnet au quatrième trimestre avec une date non confirmée.

Une date Hoodi ou mainnet doit donc rester considérée comme ajustable tant que les équipes n’ont pas achevé les tests précédents.

Le problème des builders jetables est presque une bonne nouvelle pour le processus de test

Pas parce qu’il est souhaitable de rendre Sepolia inutilisable.

Mais parce que la différence économique entre un testnet et le mainnet vient d’être transformée en scénario concret avant la mise en production.

Les mécanismes économiques sont difficiles à tester si tous les participants au test se comportent raisonnablement.

Un réseau public où quelqu’un peut dépenser gratuitement des quantités absurdes de test ETH fournit justement un adversaire que les simulations internes reproduisent moins naturellement.

ePBS doit survivre aux builders irrationnels, pas seulement aux builders rentables

Sur le long terme, l’objectif d’ePBS reste de retirer une partie des hypothèses de confiance actuellement confiées aux relais et à des mécanismes hors protocole.

Cela implique que le protocole doit définir ce qui arrive lorsqu’un builder paie, promet, disparaît ou refuse de livrer.

Le mainnet ajoute une discipline économique à ces règles.

Sepolia retire une partie de cette discipline.

Cette distorsion peut rendre le test plus chaotique que la production, mais elle force aussi les clients à montrer ce qu’ils font lorsqu’un acteur n’a littéralement aucune raison économique d’être raisonnable.

Le 6 octobre sera donc autant un test des logiciels que des incitations

Glamsterdam est souvent présenté sous l’angle de ses objectifs de capacité : plus de temps de propagation, davantage de parallélisme et un chemin vers des blocs beaucoup plus gros.

Sepolia va aussi tester quelque chose de moins visible.

Ethereum inscrit désormais dans son consensus un véritable marché entre proposers et builders.

Un marché fonctionne grâce à du code, mais également parce que ses participants ont quelque chose à gagner et quelque chose à perdre.

Sur Sepolia, la deuxième moitié de cette équation est volontairement très faible.

Si les clients parviennent à rester utilisables même face à des builders jetables qui offrent de l’argent sans valeur puis refusent de travailler, le test aura probablement appris à Ethereum davantage qu’un réseau où tout le monde se comporte correctement.