La semaine dernière, un peu plus de 100 contributeurs principaux d’Ethereum se sont réunis au-delà du cercle arctique, à Longyearbyen, Svalbard, pour le Soldøgn Interop, une semaine de travail intense sur la mise à niveau du réseau Glamsterdam.
Le Soldøgn a suivi le Berlinterop de l’année dernière, mais a renoué avec le format utilisé lors des événements Amphora 🏺, Edelweiss 🏔️ et Nyota ✨ : une semaine dédiée à des progrès multi-clients axés sur une mise à niveau spécifique, en l’occurrence, le renforcement du Glamsterdam.
À la fin de la semaine, le groupe avait atteint trois objectifs majeurs : un accord sur un plancher de limite de gaz post-Glamsterdam de 200M, des implémentations stables d’ePBS fonctionnant avec des constructeurs externes, et les chiffres de reclassement finaux pour l’EIP-8037 verrouillés. Des progrès significatifs ont également été réalisés sur des fonctionnalités de Hegotá telles que FOCIL et l’abstraction de compte native, ainsi que sur d’autres sujets variés.
Pourquoi Svalbard ?
Svalbard est l’un des rares endroits sur Terre où toute personne, quelle que soit sa nationalité, peut vivre et travailler sans visa. C’est aussi le foyer du Global Seed Vault et de l’Arctic World Archive, deux installations de stockage à froid creusées dans le permafrost aux abords de Longyearbyen. Elles contiennent des sauvegardes de cultures, de livres, de films, de manuscrits et de code source qui pourraient être nécessaires à l’humanité dans mille ans, y compris un instantané du code source d’Ethereum. Dernier point mais non des moindres, entre fin avril et août, le soleil ne se couche pas à Svalbard, offrant ainsi un temps de disponibilité continu, tout comme Ethereum, que les développeurs ont su exploiter au maximum durant la semaine.
[not-theb]
Renforcer Glamsterdam, Élargir Ethereum
L’objectif de la semaine était de renforcer les implémentations de Glamsterdam et de définir un objectif 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 aborde plusieurs aspects : la manière dont les blocs sont construits et proposés, l’espace disponible pour les implémentations clients sous charge et la façon dont les coûts de création d’état évoluent avec le débit.
Concrètement, cela impliquait d’achever la semaine avec un devnet multi-clients stable pour Glamsterdam, utilisant le dernier ePBS, ainsi que des spécifications de reclassement et des listes d’accès aux blocs, accompagnées de données de benchmark pour ancrer une proposition crédible de limite de gaz.
La plupart du temps a été consacré à écrire du code, souvent jusqu’aux premières heures du matin, entrecoupé de sessions de réflexion pour s’accorder sur des décisions de conception et discuter des éléments de feuille de route à long terme.
Trois équipes de l’Ethereum Foundation ont fourni l’infrastructure pour la semaine : EthPandaOps a livré ethIQ et un serveur panda MCP pour soutenir les workflows des équipes ; Protocol Support a mis en place soldogn.xyz comme source unique de vérité pour les objectifs d’interopérabilité, le calendrier et les notes ; et l’équipe EF Digital Studio a capturé la semaine en vidéo. Attendez-vous à voir le tout premier documentaire sur l’interopérabilité très bientôt !
ePBS
Au-delà de la clarification de la relation entre le proposeur et le constructeur, l’ePBS restructure les créneaux en ajoutant des délais pour la construction des blocs, la révélation des charges utiles et les attestations. Cela explicite combien de temps peut être alloué pour l’exécution, augmentant l’espace disponible pour augmenter la limite de gaz.
Les équipes ont commencé la semaine avec pour objectif un devnet Glamsterdam 4 EL × 4 CL d’ici lundi soir. Les premières tentatives ont révélé suffisamment de problèmes pour repousser cet objectif à mardi, où une configuration 4×3 a fonctionné de manière suffisamment stable pour commencer les tests de résistance.
De là, le reste de la semaine a consisté en un cycle de durcissement de l’ePBS : tests de résistance, exposition des cas limites, corrections et répétitions. Une session de débriefing sur l’API du constructeur a considérablement simplifié la spécification autour de l’enregistrement des validateurs, du flux d’enchères/entêtes/engagements et du modèle de confiance pour les paiements aux constructeurs. Les débogages du milieu de semaine se sont concentrés sur les cas limites inter-clients, notamment autour de l’invalidation des demandes d’exécution des demandes de balise, où une nouvelle suite de tests a révélé une lacune dans chaque implémentation de client. D’ici jeudi matin, les équipes CL rapportaient un ePBS stable, tandis que les chemins d’enchères côté EL étaient encore en débogage ; ceux-ci ont été résolus entre jeudi et vendredi. Deux questions demeurent vraiment controversées pour l’ACD : savoir si une signature de demande doit s’engager auprès du constructeur récepteur, et comment garder un modèle de constructeur staké à 1 ETH résilient aux attaques de type Sybil.
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 représente le côté consensus de l’histoire d’évolutivité de Glamsterdam, le volet de la couche d’exécution englobe principalement deux aspects : les reclassements de gaz et les listes d’accès au niveau des blocs. En fournissant aux clients suffisamment d’informations sur l’ensemble de lecture/écriture d’un bloc à l’avance, les BAL permettent une exécution parallèle, une entrée/sortie groupée et un calcul de racine d’état parallèle, qui déterminent tous la taille maximale d’un bloc que les clients peuvent traiter confortablement.
La piste BAL de Soldøgn a fonctionné sur ses propres devnets, distincts des chaînes ePBS de Glamsterdam, afin que les benchmarks d’optimisation ne soient pas entremêlés avec le travail de stabilisation de la couche de consensus. Chaque optimisation était derrière son propre drapeau de fonctionnalité pour que les travaux de mesure de la semaine puissent les comparer isolément plutôt qu’en un seul ensemble. Le tableau de bord de benchmark BAL a mis en lumière les pires scénarios de chaque client à travers la suite de tests — en se concentrant d’abord sur l’élévation des chemins les plus lents, les équipes pouvaient relever le plancher de limite de gaz de manière globale.
Reclassements de gaz
Le Glamsterdam comprend plusieurs reclassements de gaz EL, calibrant les coûts pour mieux correspondre à l’utilisation des ressources à débit élevé. L’EIP-8037, qui augmente le coût de création d’état, est au cœur : il élève le prix de l’écriture de nouveaux états afin qu’une limite de gaz plus élevée n’entraîne pas une croissance illimitée de l’état.
À l’entrée de Soldøgn, la spécification 8037 portait un prix dynamique par octet d’état lié à la limite de gaz du bloc, ce qui rendait les tests combinatoires douloureux et le benchmark presque ingérable. Les équipes ont convenu en début de semaine de renoncer à la tarification dynamique au profit d’un coût_par_octet_d’état fixe, avec des reclassements futurs gérés aux frontières des forks plutôt qu’au sein d’un fork.
Le modèle comptable lui-même a emprunté une voie plus itérative. La session de lundi a déplacé le comptage de gaz d’état de l’exécution intermédiaire à la fin du cadre 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 transactions CREATE ; mercredi a mis en lumière des cas limites de remboursement/rapport de réservoir qui ont nécessité une rethink. La session de jeudi a fait revenir la comptabilité à un niveau d’opcode, ayant conclu que la véritable complexité reposait dans le modèle de réservoir, et non dans le calcul à comptabiliser. D’ici vendredi, la spécification avait été stabilisée sur bal-devnet-6, avec la piste BAL livrant les chiffres finaux de reclassement.
Tout cela met en évidence l’un des aspects les plus cruciaux de l’interopérabilité : la capacité à résoudre des problèmes complexes de spécification, d’implémentation, de test, de débogage et de design en heures plutôt qu’en semaines. Au mieux, les semaines d’interopérabilité peuvent compresser un mois de progrès asynchrone en chaque jour !
Vendredi, les trois volets convergeaient sur le chiffre principal de la semaine : un crédible plancher de limite de gaz de 200M post-Glamsterdam. Cette augmentation significative est possible parce que l’ePBS structure le créneau pour donner plus de temps à l’exécution, que les optimisations BAL offrent aux clients l’espace de passage nécessaire dans cette structure, et que 8037 garantit que la limite de gaz plus élevée ne se traduit pas par une explosion de la croissance de l’état.
Autres Thèmes de Glamsterdam
Au-delà de l’ePBS, des BAL et des reclassements, la majorité du reste du champ d’application de Glamsterdam a été abordée au cours des sessions de réflexion.
Les équipes CL ont finalisé des décisions sur de plus petits EIPs de Glamsterdam : EIP-8061 (augmentation du roulement de sortie/consolidation) a été inclus dans glamsterdam-devnet-1 ; EIP-8080 (sorties via la file de consolidation) a été refusé ; EIP-8045 (suppression des devoirs des validateurs sanctionnés) a été limité aux devoirs de proposeur uniquement dans la fenêtre d’anticipation ; et EIP-7688 (conteneurs SSZ stables) reste dans le champ de Glamsterdam mais est tenu à l’écart de glamsterdam-devnet-1 pendant que l’équipe travaille sur la taille maximale des messages de gossip pour les attestations sous listes progressives.
Un débriefing architecture EL/CL de mercredi matin a reporté EIP-8237 à l’extérieur de Glamsterdam pour préserver des options pour une architecture de “synchronisation” à long terme dans un fork futur. À la place, la salle a convenu de rédiger un EIP normalisant la séquence forkchoiceUpdated / newPayload / getPayload, spécifiant un handshake d’initiation de snap-sync, et en resserrant la cohérence valide/invalides entre les surfaces de l’API du moteur.
Le durcissement a été un thème constant de la semaine. Une session de jeudi a abordé les cadres de tests de conformité de choix de fork, le dépôt Diamond de scénarios de cas limites réutilisables de CL, et buildoor, l’outil de test des constructeurs externes de PandaOps, a été présenté en milieu de session avec un long fil de scénarios d’attaque suggérés sur le champ.
Au-delà de Glamsterdam
Plusieurs sessions ont regardé vers Hegotá et les forks qui suivront.
Une session délibérément agnostique aux propositions sur l’Abstraction de Compte Native a ouvert le bal, examine les exigences et contraintes que tout futur design devra satisfaire. Des objectifs de fonctionnalités tels que des schémas de signature alternatifs, l’agrégation, le regroupement, le parrainage de gaz, des nonces flexibles et des portefeuilles de clés sont passés à la liste des contraintes autour de la compatibilité avec le mempool public, l’absence d’état et la résistance aux attaques DoS de L2.
Une session de jeudi sur le FOCIL s’est concentrée sur les mises à jour de l’implémentation : les premiers prototypes étaient déjà fonctionnels, avec une interopérabilité multi-clients et un devnet FOCIL dédié en tant que prochaines étapes immédiates. Deux décisions de conception notables ont également été prises : désactiver FOCIL pendant la non-finalité de 2 époques (s’inspirant du comportement de circuit-breaker de l’augmentation des proposeurs), et adopter une approche de signet basée sur l’index pour la compatibilité avec les transactions de cadre / EIP-7702.
Plus loin, une piste ETH P2P de longue date a élaboré un remplacement basé sur QUIC pour libp2p, avec confidentialité par défaut et intégration consciente des créneaux, ainsi qu’un prototype de diffusion codée en effacement qui simule une propagation ~6× plus rapide que GossipSub sur des charges utiles de 2,4 Mo. La piste CL a également montré un fort sentiment en faveur d’une éventuelle dépréciation totale des consolidations — déclarant un fork final qui les soutiendrait, puis forçant sortie puis redépôt par la suite — en tant que réponse plus propre à la croissance de l’état du jeu de validateurs.
Processus ACD
Mercredi après-midi, Nixo et Ansgar, les deux co-leaders ACDE, ont animé une session pour recueillir les avis des contributeurs principaux sur le processus ACD. La session a revisité la structure des titres, débattu des avantages et des inconvénients d’avoir une carte théorique, et formalisé les critères SFI d’EIP. La salle a largement voulu conserver les titres tout en assouplissant la rigidité entre l’EIP et le thème, acceptant “thème + EIP candidat” comme un modèle viable. Les attributions d’années par fork de la carte théorique au-delà de 2026 ont été signalées comme étant trop canoniques et probablement assouplies. Une nouvelle définition SFI en quatre points a été proposée, avec l’ACDT signalant la préparation et l’ACDE/ACDC conservant le dernier mot. Un nouveau processus de hiérarchisation — produit suite aux décisions du CFI et reflété dans le méta-EIP — remplacera le rôle ancien du SFI dans l’inclusion du devnet, en commençant par Hegotá.
Du côté de la coordination des appels, Alex Stokes a annoncé qu’il prendra un congé de trois mois à partir de la semaine prochaine, avec Pari couvrant la modération de l’ACDC en attendant et Barnabas prenant la relève pour l’ACDT. En résumé : Nixo et Ansgar président l’ACDE, Pari est intérimaire à l’ACDC, et Mario, Barnabas et Danceratopz se relaient à 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 présentiel pour progresser sur divers sujets allant des meilleurs outils de test (compressant les boucles de retour d’informations de Hive de plusieurs heures à quelques minutes), aux améliorations de l’API moteur (dé-duplication de gossip, appels groupés, et découverte des têtes pilotée par le client léger), 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
Les équipes retourneront chez elles pour mettre au point ce qui a été prototypé durant la semaine afin de le rendre prêt pour la production. Attendez-vous à ce que les prochaines semaines soient consacrées au durcissement des implémentations clients selon les nouvelles spécifications, à la finalisation de la couverture des tests, et à la transformation des PR en ébauche de Soldøgn en code approuvé.
Comme toujours, les décisions finales sur des valeurs telles que l’objectif de limite de gaz de 200M et les chiffres finaux de reclassement seront prises et partagées publiquement lors des appels AllCoreDevs. Ces sujets devraient constituer les principaux points de discussion pour la semaine à venir !
Un grand merci à tous ceux qui ont fait le déplacement jusqu’à 78°N et ont contribué au succès de cette semaine ! Un remerciement particulier à EthPandaOps pour avoir organisé le groupe jour après 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 se joignait à nous pour leur première interopérabilité. Ce fut une semaine incroyablement productive, et nous aurons la chance de nous souvenir de tout cela grâce à un court-métrage ! ☀️
Points à retenir
- La réunion à Svalbard a permis d’atteindre des objectifs clés pour l’Ethereum avec le Glamsterdam.
- Des progrès significatifs ont été réalisés dans le durcissement des implémentations et des relations entre clients.
- Les sessions de travail ont favorisé une collaboration étroite et efficace entre les participants.
- Les optimisations tant au niveau des reclassements que des listes d’accès sont essentielles pour la scalabilité.
- Les décisions prises lors de cette semaine auront un impact direct sur les futures mises à niveau d’Ethereum.
La semaine passée à Svalbard souligne non seulement l’engagement des contributeurs d’Ethereum vers un avenir plus robuste, mais aussi l’importance des collaborations inter-équipes. Avec un concert de talents et d’idées, le projet prend forme. Le défi reste maintenant de transformer ces idées prometteuses en réalité concrète, un vrai travail d’orfèvre qui exige patience, précision et innovation continue. Quels seront les prochains jalons marquants pour Ethereum ? La discussion reste ouverte et passionnante.
[not-theb]
Pas des conseils en investissement
Les informations fournies sur ce site web ne doivent pas être considérées comme des conseils en investissement, des conseils financiers, des conseils en trading ou toute autre sorte de conseil et aucun contenu du site web ne doit être considéré de la sorte. LesNews ne vous recommande pas d'acheter, vendre ou détenir des cryptomonnaies. Faites preuve de vigilance et consultez votre conseiller financier avant de prendre toute décision en matière d'investissement
Avis de non-responsabilité
[/not-theb]Avis de non-responsabilité. LesNews ne cautionne aucun contenu ou produit figurant sur cette page. Bien que nous nous efforcions de vous fournir toutes les informations importantes que nous avons pu obtenir, les lecteurs doivent faire leurs propres recherches avant d'entreprendre toute action liée à l'entreprise et assumer l'entière responsabilité de leurs décisions, et cet article ne peut être considéré comme un conseil d'investissement..