Ethereum Teste Glamsterdam Le 6 Octobre

Le 6 octobre 2026, à 13 h 53 min 36 s UTC pile, le testnet public Sepolia d’Ethereum basculera vers un ensemble de règles que beaucoup attendent depuis des mois. Ce n’est pas encore le mainnet. Ce n’est pas non plus une simple rustine. C’est la première épreuve grandeur nature de Glamsterdam, le prochain paquet de scaling de la couche 1, celui qui veut changer la manière dont un bloc est construit, vérifié, payé et stocké. Les opérateurs de nœuds sur Sepolia n’ont plus le droit d’attendre. Les détenteurs d’ether sur le réseau principal, eux, n’ont rien à faire pour l’instant. Entre les deux, il y a une question qui revient partout : cette fourche de test ouvre-t-elle vraiment la porte à un Ethereum plus rapide, ou seulement à une nouvelle série de surprises techniques ?

Ce Que Change Vraiment Glamsterdam Sur Sepolia

Glamsterdam n’est pas un nom marketing inventé pour faire joli. Il assemble deux couches distinctes : Amsterdam côté exécution et Gloas côté consensus. L’activation est calée sur l’époque 353 024, au slot 11 296 768. Hoodi et le mainnet n’ont toujours pas de date officielle. Autrement dit, le rendez-vous du 6 octobre ne concerne que Sepolia. Cette précision compte. Trop souvent, une annonce de testnet est lue comme un feu vert immédiat pour le réseau principal. Ici, la Fondation Ethereum a volontairement séparé les calendriers.

Le cœur du paquet tient en deux mécaniques. La première s’appelle ePBS, pour enshrined proposer-builder separation, portée par l’EIP-7732. La seconde, l’EIP-7928, introduit des listes d’accès au niveau du bloc. Autour de ces deux piliers gravitent des changements de tarification du gas, des ajustements de calldata, une nouvelle manière de compter la création d’état et une séparation plus nette entre la validation du consensus et celle de l’exécution. Le tout vise un objectif simple à formuler et difficile à tenir : préparer la couche 1 à un débit plus élevé sans tout casser en chemin.

Le protocole lui-même gère désormais le paiement entre le constructeur de bloc et le proposant, au lieu de s’en remettre à une infrastructure de confiance externe.

Fondation Ethereum, synthèse des notes techniques de Glamsterdam

Pourquoi Sepolia, et pourquoi maintenant

Sepolia est le terrain d’essai public le plus proche du mainnet pour ce type de fourche. Les développeurs y ont d’abord avancé à tâtons. Le 6 octobre était une cible conditionnelle tant que des bogues de finalité et d’implémentation d’EIP-8037 restaient ouverts. Les notes de la réunion All Core Developers Testing du 21 septembre ont tranché : la date est confirmée. Le 23 septembre, l’équipe des spécifications d’exécution a publié un premier jeu de fixtures mainnet contenant les changements Amsterdam, après revue des quinze EIP d’exécution du paquet.

Entre-temps, les clients sont arrivés. Go Ethereum 1.17.6 embarque explicitement l’horodatage d’activation Amsterdam sur Sepolia. Besu 26.9.0 est sorti le 25 septembre. Nethermind 2.0.0 a précédé. Reth 2.7.0 et Erigon 3.7.0 figurent aussi dans le tableau de versions compatible. Côté consensus, Lodestar 1.49.0, Prysm 7.2.0 et Teku 26.9.1 sont listés, d’autres versions devant suivre. Un détail Prysm mérite d’être souligné : après activation, le client part sur une limite de gas de 60 millions par défaut. Qui veut proposer des blocs à 200 millions doit configurer les nouveaux contrôles de proposant. Oublier ce réglage, c’est proposer trop petit au moment où le réseau teste précisément sa capacité.

Les utilisateurs ordinaires d’ether n’ont aucune action à mener pour cette fourche de test. C’est une phrase que l’on répète à chaque upgrade, et elle reste vraie. Elle ne dit pas que les applications déployées sur Sepolia peuvent dormir. Les contrats qui s’appuient sur des stipends fixes, des plafonds de gas en dur ou des hypothèses sur le gas restant pendant l’exécution peuvent se comporter autrement. La Fondation l’a déjà signalé. Des portefeuilles, indexeurs et estimateurs qui hardcodent une limite maximale ont déjà été identifiés comme fragiles.

ePBS : sortir le constructeur de l’ombre du protocole

Aujourd’hui, une grande partie des blocs Ethereum naît hors protocole. Des constructeurs spécialisés assemblent la charge d’exécution, puis parlent aux validateurs via une infrastructure externe. Ça marche. Ça marche même très bien pour extraire de la valeur et remplir les blocs. Mais ça repose sur de la confiance dans des relais, des enchères et des chemins qui n’appartiennent pas au consensus. ePBS veut rentrer cette relation dans le protocole.

Concrètement, le proposant n’embarque plus forcément toute la charge d’exécution au moment où il propose. Il inclut un engagement du constructeur. Plus tard, le constructeur révèle la charge complète. Le protocole s’occupe du paiement entre les deux. Les validations consensus et exécution se séparent dans le temps. Les validateurs gagnent une fenêtre plus large pour vérifier la charge, parce qu’ils n’ont plus à tout faire d’un seul tenant. Un comité de ponctualité de la charge décide si le constructeur a bien révélé sa charge et les données de blobs associées dans les délais.

Cette séparation n’est pas cosmétique. Elle touche la censure, la centralisation des constructeurs, la robustesse des relais et la capacité à monter le débit sans écraser les validateurs modestes. Elle ne supprime pas le métier de constructeur. Elle le formalise. C’est une nuance que beaucoup d’articles passent trop vite. ePBS n’interdit pas la spécialisation. Il encadre la spécialisation pour que le réseau n’ait plus à faire confiance à une tuyauterie parallèle.

Les validateurs disposent de davantage de temps pour vérifier les charges d’exécution, car les contrôles de consensus et d’exécution ne se font plus en même temps.

Notes de conception autour de l’EIP-7732

Le risque, bien sûr, est dans le calendrier de révélation. Si un constructeur tarde, si les blobs n’arrivent pas, si le comité de ponctualité se trompe, le créneau se vide ou se dégrade. Les devnets l’ont déjà montré : la finalité peut tousser quand les hypothèses de timing glissent. C’est précisément pour cela que Sepolia existe. Un testnet public n’est pas un laboratoire privé. Il accueille des opérateurs hétérogènes, des versions un peu en retard, des configurations bizarres. C’est là que l’on voit si ePBS tient hors des conditions idéales.

Les listes d’accès de bloc, le levier discret du débit

L’EIP-7928 paraît moins spectaculaire qu’ePBS. Elle l’est peut-être davantage pour les clients. Une liste d’accès au niveau du bloc consigne les comptes et emplacements de stockage touchés, ainsi que les changements d’état produits par les transactions. Avec cette carte, un client peut lire l’état disque à l’avance, paralléliser une partie de la validation et calculer plus vite la racine d’état.

Le goulot d’Ethereum n’est pas seulement le nombre de transactions par seconde sur une diapositive. C’est aussi le temps que met un nœud à relire l’état, à exécuter, à hasher, à propager. Quand on promet plus de capacité couche 1, on promet surtout que les clients tiendront la charge sans exploser en I/O. Les listes d’accès attaquent ce problème de face. Elles ne rendent pas magiquement l’état petit. Elles rendent l’état prévisible pour un passage de bloc.

Les développeurs décrivent Glamsterdam comme une préparation à une hausse de capacité couche 1. La formule est prudente, et elle doit le rester. Une liste d’accès mal formée, incomplète ou trop coûteuse à vérifier annulerait le gain. D’où l’intérêt d’un testnet public : on verra si les clients lisent vraiment plus vite, si la parallélisation tient, si les racines d’état restent cohérentes sous charge réelle.

Le gas ne se calcule plus comme avant

Glamsterdam ne se limite pas à la construction de blocs. Plusieurs EIP reprennent la comptabilité du gas pour mieux coller aux ressources réellement consommées quand un contrat crée ou lit de l’état. L’EIP-8037 augmente et mesure séparément le coût de création d’état. L’EIP-8038 revoit le coût d’accès à l’état. D’autres propositions touchent le gas des transactions, le calldata, les listes d’accès et la comptabilité au niveau du bloc.

Pour un utilisateur final, cela peut se traduire par des frais différents selon le profil d’une transaction. Créer beaucoup d’état coûtera davantage. Lire de l’état déjà chaud pourra suivre une autre logique. Les applications qui ont figé des constantes depuis 2021 ou 2022 devront retester. Ce n’est pas un détail de développeur solitaire. Les estimateurs de frais, les bundlers, les relais de compte abstrait, les ponts et certains jeux on-chain s’appuient encore sur des marges héritées.

Les tests privés l’ont déjà illustré. Des bogues liés à la finalité et à l’implémentation d’EIP-8037 ont forcé les équipes clientes à prolonger les essais avant de confirmer la fourche publique. En août, Ethereum a même lancé un testnet temporaire baptisé Platåberget pour offrir davantage de temps de rodage. Ce n’est pas un aveu d’échec. C’est le rythme normal d’un protocole qui refuse de brûler le mainnet pour gagner trois semaines de communication.

Ce que les notes de développeurs disent vraiment

Les comptes rendus de l’All Core Developers Testing du 21 septembre sont plus secs que les fils d’actualité, et c’est tant mieux. Ils fixent Sepolia au 6 octobre, époque 353 024, 13 h 53 min 36 s UTC. Ils laissent Hoodi en discussion, avec le 27 octobre comme cible provisoire et une décision go or no-go après l’activation Sepolia. Ils ne calendrier pas le mainnet. ethereum.org situe encore Glamsterdam au quatrième trimestre 2026, en précisant que la date n’est pas confirmée.

Cette prudence a une histoire récente. Le 6 octobre a d’abord été une hypothèse pendant que les bugs de consensus et d’exécution étaient chassés. Confirmer Sepolia sans confirmer Hoodi ni le mainnet, c’est accepter de juger sur pièces. Si Sepolia se passe bien, Hoodi pourra suivre. Si Sepolia révèle un angle mort, le calendrier glissera. Les marchés aiment les dates. Les clients aiment les spécifications stables. Les deux ne avancent pas à la même vitesse.

Le programme de bug bounty de la Fondation est ouvert sur les spécifications et les EIP de Glamsterdam. Les implémentations clientes deviennent éligibles au fur et à mesure que les versions compatibles sont officiellement ajoutées. C’est un signal utile pour les chercheurs en sécurité : le moment de chercher n’est pas après le mainnet, c’est maintenant, pendant que Sepolia absorbe les premiers chocs.

Après Sepolia, Hoodi, puis le flou du mainnet

Si Sepolia se comporte comme prévu, Hoodi devrait être la prochaine étape publique. Le 27 octobre circule comme hypothèse. Rien n’est gravé. Une discussion de validation est prévue après l’activation Sepolia. Le mainnet, lui, reste sans horodatage. Cette absence agace. Elle protège aussi. Une fourche de scaling qui touche à la fois la construction de blocs, la vérification parallèle et le gas ne se déploie pas comme un changement de constante cosmétique.

La feuille de route qui suit Glamsterdam pointe vers Hegotá en 2027. Le prochain paquet devrait couvrir un autre ensemble de changements protocolaires, pendant que les équipes travaillent sur l’abstraction de compte native, une vérification cryptographique plus forte et une infrastructure résistante au quantique. Vitalik Buterin a indiqué que Hegotá pourrait être la dernière fourche d’apparence classique, avant que le développement bascule davantage vers les STARK récursifs, la vérification automatisée, la confidentialité et des systèmes de consensus redessinés. L’équipe protocole a par ailleurs fixé une cible de décembre 2029 pour la résistance quantique sur les couches exécution, consensus et données. Beaucoup de propositions individuelles restent en revue. Glamsterdam n’est donc pas la dernière station. C’est une station intermédiaire, mais une station chargée.

Ce que cela change pour le marché, sans en faire un oracle

Un testnet n’achète pas un cycle haussier. Il ne le tue pas non plus. L’annonce du 6 octobre arrive dans un climat où le prix de l’ether se heurte encore à des résistances techniques, et où d’autres titres parlent de trésoreries qui accumulent ou de positions courtes sur des dérivés. Mélanger tout cela dans une même phrase de certitude serait malhonnête. Ce que l’on peut dire sans se tromper, c’est que le marché observe la cadence des fourches. Une Sepolia propre rassure sur la capacité de livrer. Une Sepolia chaotique rappelle que le scaling couche 1 reste un métier d’ingénierie, pas un slogan.

Les applications couche 2 regardent aussi. Plus la base est capable d’absorber de la data et de régler plus vite, plus les rollups respirent. Glamsterdam ne remplace pas les rollups. Il prépare un sol plus solide sous leurs pieds. Les listes d’accès et ePBS visent d’abord la couche 1, mais l’effet secondaire intéresse tout l’écosystème qui ancre ses preuves et ses blobs sur Ethereum.

Les clients, ces héros discrets de chaque fourche

On parle trop des EIP et pas assez des binaires. Une fourche réussit ou échoue dans les dépôts Git des clients. Le tableau actuel pour Sepolia est déjà fourni : Besu 26.9.0, Erigon 3.7.0, go-ethereum 1.17.6, Nethermind 2.0.0, Reth 2.7.0 côté exécution ; Lodestar 1.49.0, Prysm 7.2.0, Teku 26.9.1 côté consensus, avec d’autres versions attendues. Cette liste bougera. C’est normal. Ce qui n’est pas normal, c’est de laisser un nœud Sepolia sur une version d’août et d’espérer suivre l’époque 353 024.

La diversité cliente reste une assurance. Si un seul client dominait et se trompait sur ePBS ou sur EIP-8037, Sepolia se figerait dans une branche morte. Plusieurs implémentations, plusieurs langages, plusieurs équipes : le coût est élevé, le bénéfice aussi. Glamsterdam, parce qu’il touche consensus et exécution en même temps, met précisément cette diversité à l’épreuve.

Une lecture plus large de la feuille de route

Ethereum n’essaie plus de tout résoudre dans une seule fourche monumentale. Glamsterdam prépare le débit. Hegotá devra porter d’autres sujets. La cible 2029 sur le quantique rappelle que le protocole pense désormais en décennies, pas seulement en trimestres. Cette temporalité détonne avec le rythme des réseaux sociaux. Elle est pourtant plus fidèle à l’histoire récente : The Merge, puis Dencun, puis Pectra, puis les paquets suivants. Chaque fois, le récit public accélère. Chaque fois, les spécifications ralentissent juste assez pour ne pas casser l’état mondial.

On peut trouver cette lenteur frustrante. On peut aussi y voir une méthode. Sepolia le 6 octobre est la méthode en action : on expose le code à un réseau public, on observe, on décide ensuite seulement si Hoodi et le mainnet méritent une date. Le suspense n’est pas un effet de style. Il est le produit d’un processus qui refuse de confondre un test réussi et une mise en production.

Ce qu’il faut retenir avant l’heure H

Le 6 octobre à 13 h 53 min 36 s UTC, Sepolia active Glamsterdam. Les nœuds du testnet doivent être à jour, exécution et consensus. ePBS formalise la séparation proposant-constructeur. Les listes d’accès de bloc visent la lecture parallèle de l’état. Le gas change, surtout pour la création et l’accès à l’état. Hoodi reste provisoire autour du 27 octobre. Le mainnet n’a pas de date. Hegotá se profile pour 2027. Les chasseurs de bugs ont déjà un terrain de jeu.

Rien de tout cela ne garantit que le débit couche 1 bondira du jour au lendemain. Tout cela indique qu’Ethereum a choisi de tester en public les deux leviers qu’il juge nécessaires pour y parvenir. Le reste se jouera après l’époque 353 024, dans les logs des clients, dans les rapports de finalité, dans les contrats qui se briseront ou tiendront, et dans la décision, quelques semaines plus tard, d’oser ou non la fourche suivante.

D’ici là, la seule action urgente concerne ceux qui font tourner Sepolia. Mettre à jour. Vérifier la limite de gas. Surveiller l’activation. Relire les contrats qui supposent encore un monde où le gas se comporte comme en 2024. Le réseau principal, lui, continue comme avant. Jusqu’au jour, encore non inscrit au calendrier, où Glamsterdam cessera d’être un test pour devenir la règle.