La semaine dernière, un peu plus de 100 contributeurs principaux d'Ethereum se sont réunis au-dessus du cercle polaire arctique — à Longyearbyen, au Svalbard — pour l'Interop Soldøgn : une semaine de travail intense sur la mise à niveau du réseau Glamsterdam.
Soldøgn a fait suite à Berlinterop de l'année dernière, mais est revenu au format utilisé par Amphora 🏺, Edelweiss 🏔️ et Nyota ✨ : une semaine à voie unique de progrès ciblés et multi-clients vers une mise à niveau spécifique — dans ce cas, le renforcement de Glamsterdam.
Vendredi, le groupe avait atteint ses trois objectifs principaux : un alignement sur un plancher de limite de gaz post-Glamsterdam de 200M, des implémentations ePBS stables fonctionnant avec des constructeurs externes, et les chiffres finaux de réévaluation des prix de l'EIP-8037 verrouillés. Des progrès significatifs ont également été réalisés sur les fonctionnalités de Hegotá telles que FOCIL et l'abstraction de compte native, ainsi que sur une multitude d'autres sujets.
Pourquoi le Svalbard ?
Le Svalbard est l'un des rares endroits sur Terre où quiconque, quelle que soit sa nationalité, peut vivre et travailler sans visa. Il abrite également la Réserve mondiale de semences (Global Seed Vault) et les Archives mondiales de l'Arctique (Arctic World Archive), deux installations de stockage à froid creusées dans le pergélisol à l'extérieur de Longyearbyen. À elles deux, elles conservent des sauvegardes de cultures, de livres, de films, de manuscrits et de code source dont l'humanité pourrait avoir besoin dans mille ans, y compris un Snapshot du code source d'Ethereum. Enfin et surtout, de fin avril à août, le soleil ne se couche pas au Svalbard. Il a une disponibilité 24h/24 et 7j/7, tout comme Ethereum, ce dont les développeurs principaux ont profité au maximum pendant la semaine !
Renforcer Glamsterdam, faire passer Ethereum à l'échelle
L'objectif de la semaine était de renforcer les implémentations de Glamsterdam et de dériver une cible pour un plancher de limite de gaz post-mise à niveau. Augmenter la limite de gaz en toute sécurité est un problème multidimensionnel et Glamsterdam s'attaque à plusieurs d'entre eux : comment les blocs sont construits et proposés, de quelle marge de manœuvre disposent les implémentations de clients sous charge, et comment les coûts de création d'état évoluent parallèlement au débit.
En pratique, cela signifiait terminer la semaine avec un devnet Glamsterdam multi-clients stable exécutant les dernières spécifications ePBS, de réévaluation des prix et de listes d'accès aux blocs, ainsi que des données d'évaluation des performances pour ancrer une proposition de limite de gaz crédible.
La majeure partie du temps a été passée la tête dans le guidon à écrire du code, souvent jusqu'aux premières heures du matin, ponctuée par des sessions en petits groupes pour s'aligner sur les décisions de conception et discuter des éléments de la feuille de route à plus long terme.
Trois équipes de l'EF ont fourni l'infrastructure pour la semaine : EthPandaOps a livré ethIQ et un serveur MCP panda pour soutenir les flux de travail agentiques des équipes ; Protocol Support a mis en place soldogn.xyz comme source unique de vérité pour les objectifs, le calendrier et les notes de l'interop ; et l'équipe EF Digital Studio a filmé la semaine. Attendez-vous au tout premier documentaire sur l'interop 🔜 !
ePBS
Au-delà de l'assainissement de la relation proposant/constructeur, l'ePBS restructure les créneaux en ajoutant des délais pour la construction de blocs, la révélation de la charge utile et les attestations. Cela rend explicite le temps qui peut être alloué à l'exécution, augmentant ainsi la marge de manœuvre dont nous disposons pour augmenter la limite de gaz.
Les équipes ont commencé la semaine en visant un devnet Glamsterdam 4 EL × 4 CL pour lundi soir. Les premières tentatives ont fait ressortir suffisamment de problèmes pour repousser l'objectif à mardi, lorsqu'une configuration 4×3 a fonctionné de manière suffisamment stable pour que les tests de résistance puissent commencer.
À partir de là, le reste de la semaine a été un cycle de renforcement de l'ePBS : tests de résistance, exposition des cas limites, corrections, et on recommence. Une session en petits groupes sur l'API des constructeurs mardi matin a considérablement simplifié la spécification autour de l'enregistrement des validateurs, du flux offre/en-tête/engagements, du modèle de confiance pour les paiements des constructeurs et du comportement du disjoncteur. Le débogage de milieu de semaine s'est concentré sur les cas limites inter-clients — notamment autour de l'invalidation des requêtes de la chaîne balise par les requêtes d'exécution, où une nouvelle suite de tests a révélé une lacune dans chaque implémentation de client. Jeudi matin, les équipes CL signalaient un ePBS stable tandis que les voies d'offre côté EL étaient encore en cours de débogage ; celles-ci ont été résolues entre jeudi et vendredi. Deux questions restent véritablement litigieuses pour l'ACD : si une signature de requête doit engager le constructeur récepteur, et comment maintenir une conception de constructeur avec une mise de 1 ETH résiliente face aux attaques de vivacité basées sur Sybil en P2P.
Vendredi, presque tous les clients fonctionnaient ensemble sur glamsterdam-devnet-2 avec le pipeline des constructeurs externes testé de bout en bout !
Optimisations BAL
Si l'ePBS est le côté couche de consensus de l'histoire de la mise à l'échelle de Glamsterdam, la contrepartie de la couche d'exécution comporte deux éléments dominants : les réévaluations des prix du gaz et les listes d'accès au niveau du bloc (BAL). En donnant aux clients suffisamment d'informations sur l'ensemble de lecture/écriture d'un bloc à l'avance, les BAL permettent l'exécution parallèle, les E/S traitées par lots et le calcul parallèle de la racine d'état, qui déterminent tous la taille d'un bloc que les clients peuvent gérer confortablement.
La voie BAL de Soldøgn a fonctionné sur ses propres devnets, séparément des chaînes ePBS de Glamsterdam, de sorte que les évaluations d'optimisation n'étaient pas enchevêtrées avec le travail de stabilisation de la couche de consensus. Chaque optimisation se trouvait derrière son propre indicateur de fonctionnalité afin que le travail de mesure de la semaine puisse les comparer de manière isolée plutôt que comme un seul ensemble. Le tableau de bord d'évaluation des performances BAL et le classement ont fait ressortir les pires scénarios de chaque client dans la suite de tests — en se concentrant d'abord sur l'amélioration des chemins les plus lents, les équipes ont pu relever le plancher de la limite de gaz de manière générale, et pas seulement pour l'implémentation la plus rapide.
Réévaluations des prix du gaz
Glamsterdam inclut un certain nombre de réévaluations des prix du gaz sur l'EL, calibrant les coûts pour mieux correspondre à l'utilisation des ressources à un débit plus élevé. L'EIP-8037, l'augmentation du coût en gaz de la création d'état, se trouve au cœur du dispositif : elle augmente le prix de l'écriture d'un nouvel état afin qu'une limite de gaz plus élevée ne se traduise pas par une croissance illimitée de l'état.
En abordant Soldøgn, la spécification 8037 comportait une tarification dynamique par octet d'état liée à la limite de gaz du bloc, ce qui rendait les tests combinatoirement pénibles (une matrice de fuzzing par bande de limite de gaz) et l'évaluation des performances presque insoluble. Les équipes ont convenu au début de la semaine d'abandonner la tarification dynamique au profit d'un cost_per_state_byte fixe, les futures réévaluations de prix étant gérées aux limites des forks plutôt qu'à l'intérieur d'un fork.
Le modèle comptable lui-même a suivi une voie plus itérative. La session en petits groupes de lundi a déplacé la comptabilisation du gaz d'état du milieu de l'exécution vers la fin de la trame d'appel ; un suivi mardi a clôturé les coûts de création de compte, les coûts de dépôt de code et les annulations de transaction CREATE ; mercredi a fait ressortir des cas limites de remboursement/remplissage de réservoir qui ont forcé à repenser le modèle. La session de jeudi a ramené la comptabilisation au niveau du code d'opération, ayant conclu que la véritable complexité résidait dans le modèle de réservoir, et non dans le calcul comptable. Vendredi, la spécification s'était stabilisée sur bal-devnet-6, la voie BAL fournissant les chiffres finaux de réévaluation des prix.
Tout cet arc met en évidence l'un des aspects les plus importants de l'interop : la capacité à résoudre des problèmes complexes de spécification, d'implémentation, de test, de débogage et de conception en quelques heures au lieu de plusieurs semaines. Dans le meilleur des cas, les semaines d'interop peuvent condenser un mois de progrès asynchrones en une seule journée !
Vendredi, les trois fils conducteurs ont convergé vers le chiffre phare de la semaine : un plancher de limite de gaz post-Glamsterdam crédible de 200M. Cette augmentation significative est possible car l'ePBS structure le créneau pour donner plus de temps à l'exécution, les optimisations BAL donnent aux clients la marge de manœuvre en matière de débit sous cette structure, et l'EIP-8037 garantit que la limite de gaz plus élevée ne se traduise pas par une croissance incontrôlée de l'état.
Autres fils conducteurs de Glamsterdam
Au-delà de l'ePBS, des BAL et des réévaluations de prix, la majeure partie du périmètre restant de Glamsterdam a été débattue lors de sessions en petits groupes.
Les équipes CL ont finalisé les décisions sur les EIP plus petites de Glamsterdam : l'EIP-8061 (augmentation du taux de rotation des sorties/consolidations) a été incluse dans glamsterdam-devnet-1 ; l'EIP-8080 (sorties via la file d'attente de consolidation) a été refusée pour inclusion ; l'EIP-8045 (suppression des tâches des validateurs ayant subi une réduction) a été réduite aux seules tâches de proposant dans la fenêtre d'anticipation ; et l'EIP-7688 (conteneurs stables SSZ) reste dans le périmètre de Glamsterdam mais est tenue à l'écart de glamsterdam-devnet-1 pendant que l'équipe travaille sur la taille limitée des messages de potins (gossip) pour les attestations sous des listes progressives.
Une session en petits groupes sur l'architecture de synchronisation EL/CL mercredi matin a reporté l'EIP-8237 hors de Glamsterdam afin de préserver l'optionnalité pour une architecture de « synchronisation d'appoint » à plus long terme dans un futur fork. À la place, la salle a convenu de rédiger une EIP qui normalise le séquençage forkchoiceUpdated / newPayload / getPayload, spécifie une poignée de main d'initiation de synchronisation instantanée (snap-sync), et resserre la cohérence valide/invalide entre les surfaces de l'API du moteur.
Le renforcement a été un thème constant de la semaine. Une session de jeudi a couvert les cadres de test de conformité du choix de fork, le dépôt Diamond de scénarios de cas limites CL reproductibles, et buildoor, l'outil de test de constructeur externe de PandaOps, dont la démonstration a été faite en milieu de session face à un long flux de scénarios d'attaque suggérés sur place par les participants.
Au-delà de Glamsterdam
Plusieurs sessions en petits groupes se sont tournées vers Hegotá et les forks qui suivront.
Une session délibérément agnostique quant aux propositions sur l'abstraction de compte native a lancé les débats, en examinant les exigences et les contraintes que toute conception future doit satisfaire. Les objectifs d'ensemble de fonctionnalités tels que les schémas de signature alternatifs, l'agrégation, le traitement par lots, la récupération, le parrainage de gaz, les nonces flexibles et les portefeuilles de magasin de clés côtoyaient des contraintes strictes autour de la compatibilité avec la mempool publique, de l'absence d'état et de la résistance aux attaques DoS sur la couche 2 (l2).
Une session en petits groupes sur FOCIL jeudi s'est concentrée sur les mises à jour d'implémentation : les premiers prototypes étaient déjà fonctionnels, avec l'interopérabilité multi-clients et un devnet FOCIL dédié comme prochaines étapes immédiates. Deux décisions de conception notables ont également été prises : la désactivation de FOCIL pendant une non-finalité de 2 époques (reflétant le comportement du disjoncteur de boost du proposant), et l'adoption d'une approche de signet basée sur l'indice pour la compatibilité avec les transactions de trame / EIP-7702.
Plus loin, une voie ETH P2P de longue date a esquissé un remplacement basé sur QUIC pour libp2p avec une confidentialité par défaut et une intégration sensible aux créneaux, aux côtés d'un prototype de diffusion à code d'effacement qui a simulé une propagation environ 6 fois plus rapide que GossipSub sur des charges utiles de 2,4 Mo. La voie CL a également fait ressortir un fort sentiment en faveur de l'abandon éventuel et total des consolidations — en déclarant un fork final qui les prend en charge, puis en forçant la sortie puis le redépôt par la suite — comme la réponse à long terme la plus propre à la croissance de l'état de l'ensemble des validateurs.
Processus ACD
Mercredi après-midi, Nixo et Ansgar, les deux co-responsables de l'ACDE, ont animé une session pour recueillir les commentaires des contributeurs principaux sur le processus ACD. La session a réexaminé le concept de tête d'affiche (headliner), a débattu des avantages et des inconvénients d'avoir une feuille de route provisoire (strawmap), et a formalisé les critères EIP SFI. La salle souhaitait globalement conserver les têtes d'affiche mais assouplir la rigidité EIP-vs-thème, en acceptant « thème + EIP candidate » comme un modèle viable. Les affectations annuelles par fork de la feuille de route provisoire au-delà de 2026 ont été signalées comme étant trop canonisées et susceptibles d'être assouplies. Une nouvelle définition SFI en quatre points a été proposée, l'ACDT signalant son état de préparation et l'ACDE/ACDC conservant la décision finale. Un nouveau processus d'ordre de priorisation — produit après les décisions CFI et reflété dans la méta-EIP — remplacera l'ancien rôle du SFI consistant à piloter l'inclusion dans le devnet, à commencer par Hegotá.
Du côté de la coordination des appels, Alex Stokes a annoncé qu'il prendrait un congé sabbatique de trois mois à partir de la semaine prochaine, Pari assurant la modération de l'ACDC dans l'intérim et Barnabas le remplaçant pour l'ACDT. En résumé : Nixo et Ansgar président l'ACDE, Pari assure l'intérim sur l'ACDC, et Mario, Barnabas et Danceratopz se relaient pour la modération de l'ACDT.
Tout le reste
En plus de tout ce qui précède, les équipes ont utilisé le temps en personne pour progresser sur tous les fronts, allant de meilleurs harnais de test (réduisant les boucles de rétroaction de Hive de plusieurs heures à quelques minutes), aux améliorations de la plomberie de l'API du moteur (déduplication des potins, appels traités par lots et découverte de la tête pilotée par les clients légers), en passant par des compromis difficiles autour de la diversité des clients, et bien d'autres sujets. La liste complète des notes de session est disponible sur soldogn.xyz.
Prochaines étapes
À partir de là, les équipes rentrent chez elles pour prendre ce qui a été prototypé pendant la semaine et le rendre prêt pour la production. Attendez-vous à ce que les prochaines semaines soient consacrées au renforcement des implémentations de clients par rapport aux nouvelles spécifications, à la finalisation de la couverture des tests et à la transformation des brouillons de PR de Soldøgn en code fusionné.
Comme toujours, les décisions finales pour des valeurs telles que l'objectif de limite de gaz de 200M et les chiffres finaux de réévaluation des prix seront prises et partagées publiquement lors des appels AllCoreDevs. Attendez-vous à ce que ce soient les sujets majeurs de la semaine prochaine !
Merci beaucoup à tous ceux qui sont venus jusqu'à 78°N et ont fait de cette semaine un succès ! Une mention spéciale à EthPandaOps pour avoir remis le groupe en forme chaque jour, et à tous ceux qui ont travaillé sous le soleil de minuit pour s'assurer que nous atteignions nos objectifs quotidiens — y compris l'équipe Ethrex, qui s'est jointe à nous pour sa première interop. Ce fut une semaine incroyablement productive, et heureusement, nous aurons un court métrage complet pour nous en souvenir ☀️