Les développeurs d'Ethereum ont provisoirement programmé la mise à niveau Glamsterdam pour une activation sur Sepolia à 13h53 UTC le 6 octobre 2026, tandis qu'un autre test sur un devnet privé reste nécessaire avant que le fork du testnet public ne se poursuive.
Résumé
- Les développeurs d'Ethereum ont provisoirement programmé l'activation de Glamsterdam sur Sepolia pour le 6 octobre à précisément 13h53 UTC.
- Glamsterdam n'a pas achevé d'activation stable sur un quelconque devnet privé, ce qui rend le calendrier de Sepolia encore conditionnel.
- Les développeurs prévoient désormais Devnet-11 pour le 14 septembre, remplaçant les attentes antérieures centrées sur les plans de test de Devnet-10.
- Les tests sur devnet ont exposé des bugs de consensus et d'exécution, y compris un problème d'implémentation lié au code EIP-8037.
- Aucune date pour Hoodi ou le mainnet n'est confirmée, bien que les développeurs aient discuté d'une possible activation en décembre.
Les notes de la réunion ACDC #186 et les rapports ultérieurs de la chercheuse sur le protocole Ethereum Christine D. Kim montrent que la date reste conditionnelle. Les développeurs n'avaient pas achevé une activation stable de Glamsterdam sur un réseau de développement privé lorsqu'ils ont choisi le calendrier de Sepolia.
Le plan de test a depuis avancé d'une nouvelle itération. Kim a déclaré le 11 septembre que l'attention s'était tournée vers Glamsterdam-Devnet-11, dont le lancement est prévu le lundi 14 septembre. Des plans antérieurs avaient identifié Devnet-10 comme le prochain test majeur.
Aucune date d'activation n'a été confirmée pour le testnet Hoodi ou le mainnet Ethereum. Les développeurs ont discuté d'une possible sortie sur le mainnet en décembre, mais les résultats des tests détermineront si ce calendrier reste pratique.
La date de la mise à niveau Glamsterdam d'Ethereum reste provisoire
Lors de la réunion All Core Developers Consensus du 3 septembre, les participants se sont mis d'accord sur l'époque 351232 de Sepolia pour l'activation proposée. Kim a rapporté que l'heure correspondante serait le 6 octobre à 13h53 UTC. La réunion s'est tenue avant que les développeurs n'aient démontré des performances stables sur les réseaux de test privés utilisés pour Glamsterdam.
Le choix de l'époque donne aux équipes clientes, aux opérateurs d'infrastructure et aux développeurs d'applications une cible de planification commune. Cela ne rend pas l'activation définitive. Les développeurs peuvent reporter le fork si la prochaine phase de test révèle un défaut majeur ou si les équipes clientes ne peuvent pas préparer des versions fiables.
La mise en garde reste pertinente après que Devnet-9 a connu des problèmes de finalité. Selon le matériel de la réunion, le réseau comprenait environ 1 000 nœuds validateurs, ce qui en faisait le plus grand devnet Glamsterdam par nombre de validateurs à ce stade.
La finalité exige qu'un nombre suffisant de validateurs s'accordent sur l'état de la chaîne. Lorsqu'un réseau de test ne parvient pas à finaliser, les développeurs doivent déterminer si la cause implique le logiciel client, la participation des validateurs, la configuration du réseau ou une interaction entre des changements de protocole distincts.
Devnet-11 testera les correctifs avant Sepolia
Le plan initial prévoyait Devnet-10 après l'apparition de défauts lors des essais précédents. La dernière mise à jour de Kim identifie désormais Devnet-11 comme le prochain test que les développeurs surveillent, ce qui indique que la séquence de tests privés a progressé au-delà du plan antérieur.
Un Devnet-11 stable donnerait aux équipes clientes Ethereum un autre environnement pour tester les spécifications combinées de Glamsterdam. Les équipes de layer 2, les fournisseurs de staking et d'autres opérateurs d'infrastructure ont besoin d'implémentations clientes fonctionnelles avant de pouvoir tester en toute sécurité leurs systèmes contre le fork proposé.
La diversité des clients rend le processus plus complexe. Ethereum fonctionne via plusieurs clients d'exécution et de consensus développés indépendamment, et la mise à niveau doit fonctionner sur différentes combinaisons de clients. Un défaut limité à une implémentation peut toujours interrompre un réseau de test lorsque les validateurs affectés détiennent suffisamment de poids.
L'ordre du jour de l'ACDC #186 consigne les demandes de Lido et Optimism pour au moins une journée stable avant un fork. L'ordre du jour listait les correctifs des clients et une interopérabilité réussie comme des questions nécessitant une confirmation avant Sepolia.
Un Devnet-11 défaillant ou instable n'annulerait pas automatiquement l'activation du 6 octobre. Les développeurs devraient évaluer la cause et le temps nécessaire aux réparations. Un problème grave pourrait les amener à reconsidérer la date lors d'une réunion All Core Developers.
Des bugs de consensus et d'EIP-8037 prolongent les tests
Les essais antérieurs de Glamsterdam ont exposé des défauts des deux côtés de l'architecture d'Ethereum. L'ingénieur des opérations de développement de la Fondation Ethereum, Stefan Starflinger, a rapporté que le Devnet-8 a révélé un problème de couche de consensus impliquant des blocs qui répétaient un hash parent.
« Vous pouviez faire arrêter tout le réseau », a déclaré Starflinger en décrivant le scénario de test.
Le problème affectait le système responsable de l'accord sur les blocs. Le Devnet-9 a ensuite souffert d'une non-finalité, poussant les ingénieurs à étudier davantage de cas limites sur un ensemble de validateurs plus large.
Du côté de l'exécution, la chercheuse de la Fondation Ethereum Maria Silva a signalé un problème d'implémentation lié à l'EIP-8037. La proposition modifie la façon dont Ethereum facture le gaz pour la création de nouvel état, y compris les nouveaux comptes, contrats et entrées de stockage.
L'EIP-8037 sépare les coûts de création d'état des coûts d'exécution normaux via un modèle de gaz multidimensionnel. Sa spécification publiée indique que la conception vise à contrôler la croissance de l'état à mesure qu'Ethereum augmente sa limite de gaz par bloc. La proposition reste en cours d'examen par les pairs.
Le problème découvert a nécessité que les clients d'exécution révisent leurs implémentations et a conduit à un travail de spécification. Comme crypto.news l'a rapporté dans sa couverture des progrès antérieurs du devnet de Glamsterdam, l'EIP-8037 a été testé aux côtés des autres changements de protocole de la mise à niveau.
Les tests servent un objectif différent de l'approbation individuelle de chaque proposition. Les développeurs doivent confirmer que tous les changements sélectionnés fonctionnent ensemble sur plusieurs clients, configurations de validateurs et modèles de transactions.
Les dates de Hoodi et du réseau principal dépendent des résultats des tests
Les développeurs ont refusé de programmer Glamsterdam sur Hoodi tant que Sepolia reste conditionnel. Hoodi devrait servir de deuxième étape de testnet public, offrant aux opérateurs de staking et aux équipes de protocole un autre environnement qui représente plus fidèlement les conditions du réseau principal.
Le développeur de Teku, Enrico del Fante, a soutenu qu'il fallait attendre avant de fixer la date de Hoodi. Lors de l'ACDC #186, il a cité les récents problèmes du Devnet-9 et a préféré accorder plus de temps de test après la décision concernant Sepolia.
Une activation du réseau principal en décembre reste un objectif possible, et non une fenêtre de lancement confirmée. Programmer Sepolia pour début octobre préserve suffisamment de temps calendaire pour une autre phase de testnet public et la préparation des versions clients, à condition que les tests progressent sans longs retards.
Les développeurs n'ont pas publié d'époque pour le réseau principal, d'horodatage d'activation ni de calendrier final de publication des clients. Aucune échéance formelle n'a été annoncée pour décider si le 6 octobre reste approprié pour Sepolia.
L'événement procédural immédiat est le lancement prévu du Devnet-11 le 14 septembre. Les équipes clients examineront la finalité, le comportement entre clients et les correctifs introduits après les tests précédents avant de décider si Sepolia peut procéder selon le calendrier actuel.
