Les développeurs Ethereum ont confirmé une activation de Glamsterdam le 6 octobre sur Sepolia, tout en avertissant qu'un ether de test bon marché pourrait permettre à des constructeurs malveillants de remporter à plusieurs reprises des enchères de blocs et de retenir leurs charges utiles de transactions pendant la phase de test publique.
Le compte rendu du 17 septembre du consensus des développeurs d'Ethereum (All Core Developers Consensus) montre que les participants ont accepté la date du 6 octobre après avoir examiné les résultats récents du devnet Glamsterdam, bien que les développeurs aient simultanément soulevé des préoccupations quant à la manière dont la séparation Proposer-Builder (Enshrined Proposer-Builder Separation) pourrait se comporter sur un réseau public où l'ETH de test n'a pas de coût économique significatif.
Au centre de l'avertissement se trouve l'EIP-7732, la conception de la séparation Proposer-Builder Intégrée (Enshrined Proposer-Builder Separation) de Glamsterdam. Ethereum.org décrit l'ePBS comme un changement de protocole qui sépare la tâche d'assemblage des charges utiles de transactions des fonctions de consensus du validateur, déplaçant une relation qui repose actuellement fortement sur des infrastructures externes vers les règles de consensus d'Ethereum.
Selon cette conception, les constructeurs peuvent soumettre des offres pour le droit de fournir une charge utile d'exécution. Une fois qu'un proposant s'engage sur l'offre gagnante, le constructeur est censé libérer les transactions qui la sous-tendent. La spécification de consensus d'Ethereum définit les constructeurs comme des acteurs distincts avec participation (staked actors) qui soumettent des offres de charge utile d'exécution signées avant de diffuser l'enveloppe de charge utile correspondante.
Lors de l'appel des développeurs de jeudi, Potuz, développeur de consensus, a averti que l'économie change sur un réseau de test car les attaquants peuvent obtenir de l'ETH de test sans payer sa valeur marchande sur le réseau principal. Un opérateur malveillant pourrait créer de nombreuses identités de constructeur, soumettre des offres bien supérieures à celles des concurrents légitimes, puis refuser de fournir la charge utile promise après avoir gagné.
« Je peux simplement lancer un millier de constructeurs », a déclaré Potuz, expliquant que l'attaquant pourrait les faire tourner, enchérir agressivement et retenir les charges utiles. Il a ajouté plus tard : « N'importe quel adolescent peut faire cela. »
Le développeur a présenté cette préoccupation comme un problème de disponibilité du réseau de test public, et non comme une nouvelle voie pour voler de l'ETH sur le réseau principal. Sur le réseau principal, un participant peut déjà payer pour produire un bloc vide, mais le coût économique d'obtention de l'espace de bloc limite ce comportement. L'ETH de test rend les perturbations persistantes beaucoup moins chères.
Les mesures de protection existantes pourraient ne pas être suffisantes pour l'environnement Sepolia. Potuz a déclaré aux développeurs que certains disjoncteurs clients ne se replient sur des blocs construits localement qu'après que plusieurs charges utiles ont été manquées, alors qu'il n'avait pas connaissance de protections universelles pouvant rejeter les constructeurs abusifs individuels.
Sa préoccupation était centrée sur le retour des attaquants sous de nouvelles identités. Même si un client réagit aux charges utiles manquantes, les constructeurs "jetables" pourraient continuer à enchérir à moins que la logique défensive n'identifie et ne restreigne le comportement suffisamment rapidement.
Les développeurs n'ont pas présenté l'attaque du constructeur comme un exploit confirmé contre Sepolia. La discussion portait sur un scénario qu'ils s'attendent à ce que les tests publics révèlent une fois que des acteurs externes pourront participer dans les conditions de l'ePBS. Potuz a soutenu que les réseaux de test d'Ethereum ont besoin de garanties plus solides car les équipes d'application et d'infrastructure s'appuient sur eux pour tester les logiciels contre des blocs fonctionnels.
Ethereum.org note que Sepolia utilise un ensemble de validateurs permissionnés contrôlé par les équipes clientes et de test, tandis que Hoodi dispose d'un ensemble de validateurs ouvert destiné au staking et aux tests de protocole. La structure de Sepolia donne aux développeurs Ethereum un contrôle opérationnel accru si le premier déploiement public et durable de Glamsterdam rencontre des problèmes.
Comme crypto.news l'avait déjà rapporté, les développeurs avaient provisoirement choisi le 6 octobre avant le dernier appel, la date restant dépendante d'une autre transition stable sur le réseau de développement privé. L'appel de consensus du 17 septembre a fait avancer ce calendrier après que Devnet-11 ait terminé sa répétition de fork prévue.
Glamsterdam Devnet-11 a été créé comme une répétition contrôlée de « chemin heureux » plutôt qu'un réseau d'attaque adversaire. Sa spécification officielle prévoyait la genèse pour le 14 septembre, la transition Gloas pour le 16 septembre et une augmentation de la limite de gaz des blocs de 60 millions à 200 millions peu après.
Le réseau de test a utilisé 84 000 validateurs sur une configuration multi-clients et a mis en œuvre le même ensemble d'EIP de base prévu pour les tests de Glamsterdam. Ses organisateurs ont explicitement exclu les attaques délibérées du champ d'application de Devnet-11, gardant les expériences adverses sur l'environnement Platåberget, qui fonctionne depuis plus longtemps.
CoinDesk a rapporté que Devnet-11 a terminé la transition et a porté la limite de gaz à près de 200 millions sans perdre la finalité. Le réglage de 200 millions est un paramètre de test, et non un engagement confirmé de limite de gaz pour le réseau principal.
La feuille de route de Glamsterdam d'Ethereum indique que la mise à niveau est conçue pour augmenter la capacité de la Couche 1 tout en modifiant la façon dont les blocs sont construits et vérifiés. L'EIP-7732 étend la fenêtre de propagation de la charge utile d'exécution d'environ deux secondes à environ neuf secondes, donnant aux nœuds plus de temps pour distribuer et valider des charges utiles plus importantes.
La mise à niveau comprend également des listes d'accès au niveau des blocs (Block-Level Access Lists) et une série de changements de tarification du gaz. Une couverture antérieure sur la compatibilité de Glamsterdam a rapporté que les portefeuilles, les indexeurs et les estimateurs de gaz utilisant des hypothèses fixes pourraient nécessiter des modifications car la création de nouveaux comptes et certaines opérations intensives en état reçoivent un traitement de gaz différent sous le fork prévu.
Un examen séparé des risques liés aux contrats intelligents a révélé que les contrats utilisant des allocations de gaz fixes ou des modèles d'exécution sensibles au gaz pourraient nécessiter des tests avant que la mise à niveau n'atteigne le réseau principal.
Le calendrier du 6 octobre accorde aux équipes clientes moins de temps d'examen que ce que le processus de mise à niveau normal d'Ethereum recommande.
Lors de l'appel du 17 septembre, le développeur Fredrik Svantes a informé les participants que le processus standard prévoit au moins 14 jours entre la publication d'un logiciel client prêt à être lancé et la première activation sur un réseau de test public. Il a précisé que ces deux semaines sont normalement utilisées pour les audits de sécurité internes, l'exposition aux programmes de primes de bogues (bug-bounty) et d'éventuels travaux de sécurité externes.
À l'approche de Sepolia, les développeurs ont discuté d'une date limite du 29 septembre pour les versions clientes. Sept jours entre le 29 septembre et le 6 octobre laisseraient la moitié de la période d'examen normale. Les participants ont accepté ce risque pour Sepolia en partie parce que son ensemble de validateurs est relativement centralisé et que le réseau peut être récupéré plus facilement en cas de défaillance logicielle.
Le développeur principal Alex Stokes a exhorté les équipes à publier les logiciels plus tôt si possible afin que davantage de relecteurs puissent les examiner. Une fois les clients prêts à être publiés, ils peuvent immédiatement entrer dans le processus de primes de bogues d'Ethereum.
Le calendrier compressé fait suite à plusieurs problèmes de test antérieurs. Un ordre du jour des développeurs du 3 septembre a enregistré une non-finalité lors de l'activation de Gloas sur Devnet-8, affectant plusieurs clients de consensus, tandis que des tests ultérieurs sur Devnet ont examiné des correctifs et des cas limites supplémentaires.
Un autre appel de test a signalé des problèmes où un scénario Platåberget a mis hors ligne 12 des 13 nœuds Besu et a ralenti les nœuds Erigon et Ethrex. Devnet-9 a connu une non-finalité imprévue, poussant les équipes à de nouvelles itérations avant Devnet-11.
La feuille de route publique d'Ethereum continue de lister Glamsterdam pour le quatrième trimestre 2026, mais précise que la date du réseau principal n'a pas été confirmée. Le prochain jalon publié est le fork Sepolia du 6 octobre.
Hoodi devrait suivre Sepolia car il fournit un environnement de validateur ouvert pour le staking et les tests de mise à niveau. Les développeurs ont discuté de la phase Hoodi lors de l'appel du 17 septembre, mais ont lié son calendrier aux progrès de Sepolia, ce qui signifie que des problèmes sur le premier réseau de test public pourraient décaler les dates ultérieures.
Le projet de plan de réponse aux incidents du réseau principal d'Ethereum ne contient toujours aucune époque ou horodatage d'activation. Le document laisse plutôt les champs d'information sur la mise à niveau vides tout en énumérant les rôles de client et de coordination qui seront remplis avant le déploiement sur le réseau principal.
Comme l'a rapporté une couverture antérieure de crypto.news sur Glamsterdam, la mise à niveau se concentre sur l'ePBS, les listes d'accès au niveau des blocs (Block-Level Access Lists) et la nouvelle tarification du gaz, conçus pour un débit plus élevé de la Couche 1. Les développeurs ont continué à considérer les tests multi-clients réussis comme une condition préalable avant de fixer le fork du réseau principal.
Pour l'instant, les équipes clientes sont confrontées à la date limite logicielle du 29 septembre discutée lors de l'appel, suivie de l'activation de Sepolia le 6 octobre. Les développeurs Ethereum n'ont pas publié d'époque du réseau principal ni d'horodatage d'activation final.
ETH