Correctif Glamsterdam Ethereum Sur Dépôts Staking Fusionné

Qui aurait parié qu’un correctif écarté faute de soutien des clients reviendrait sur le devant de la scène en moins d’une semaine ? Le 19 octobre, les développeurs d’Ethereum avaient mis de côté une modification jugée trop risquée à l’approche de Glamsterdam. Sept jours plus tard, la même proposition se retrouvait fusionnée dans les spécifications. Ce retournement s’explique par un report de calendrier et par l’insistance d’équipes comme celle de Lido, qui avaient identifié un risque bien réel pour les dépôts destinés aux validateurs des protocoles de staking liquide.

Comment Une Faille Sur Les Dépôts A Failli Passer Sous Silence

Tout commence avec l’arrivée de l’ePBS, cette séparation entre le proposeur de bloc et le constructeur que Glamsterdam doit intégrer au protocole. Les builders, ces acteurs spécialisés dans l’assemblage des blocs, obtiennent désormais leur propre compte alimenté par un dépôt d’ETH, exactement comme un validateur classique. Le problème apparaît au moment précis de l’activation du fork. Les dépôts encore en file d’attente doivent être répartis entre validateurs et builders. Le brouillon initial des spécifications prévoyait une règle trop simple : dès qu’un dépôt avait enregistré un builder pour une clé publique donnée, tous les dépôts suivants sur cette même clé lui étaient automatiquement attribués.

George Avsetsin, architecte protocole en chef chez Lido, a décrit le scénario dans un ticket GitHub le 12 octobre. Un opérateur enregistre d’abord un builder avec une clé neuve. Un protocole de staking dépose ensuite de l’ETH pour lancer un validateur sous cette clé. Si les deux dépôts restent en attente au moment du fork, les deux montants atterrissent chez le builder. L’opérateur peut alors retirer les fonds du protocole. Aucun validateur n’étant créé, le protocole lésé ne dispose d’aucune preuve pour récupérer sa mise. Avsetsin a examiné les contrats de Lido, Rocket Pool et Origin. Il parle de résultats conditionnels plutôt que d’exploits confirmés, car certains contrôles déjà en place pourraient bloquer l’attaque. Le risque existait néanmoins dans les spécifications qui n’avaient pas encore atteint le mainnet.

L’opérateur peut retirer les fonds du protocole. Aucun validateur n’étant créé, le protocole lésé ne peut pas produire la preuve qui lui permettrait de récupérer sa mise.

George Avsetsin, architecte protocole Lido

La Pull Request Qui Change La Logique Des Dépôts

La solution proposée dans la pull request 5736 paraît simple sur le papier. Chaque dépôt en attente est désormais trié selon ses identifiants de retrait, les fameux withdrawal credentials. Un dépôt destiné à un validateur reste affecté au validateur, même si un builder utilise la même clé publique. Cette distinction évite le basculement automatique qui menaçait les protocoles de staking liquide. Pourtant, modifier la logique des dépôts à quelques semaines d’un fork majeur a provoqué des frictions. Après deux appels de développeurs, Justin Traglia, responsable des spécifications de consensus, a clos le dossier le 19 octobre. Il n’y avait pas assez de soutien de la part des clients pour intégrer ce changement immédiatement.

Les appels All Core Devs fonctionnent sans vote formel. Les propositions avancent par consensus approximatif. Un sujet écarté peut revenir dès que le contexte évolue. C’est exactement ce qui s’est produit. Le 22 octobre, les développeurs ont annulé l’activation de Glamsterdam sur le testnet Hoodi, initialement prévue le 26. Une analyse de ChainSecurity sur les nouvelles règles de tarification du gaz, les EIP-8037 et EIP-8038, avait mis en évidence des points à clarifier. Ce report a offert le temps nécessaire pour réexaminer la question des dépôts.

Le Rôle Décisif De Lido Dans La Réouverture Du Dossier

Le lendemain du report, Dmitry Gusakov, responsable de l’ingénierie staking chez Lido, a demandé la réouverture du ticket en raison des changements de calendrier. Potuz, développeur du client Prysm, a validé le jour même, non sans exprimer une réserve. Il avouait toujours craindre de placer ce changement avant le fork. Avec une activation désormais sans date fixe, il estimait cependant disposer de suffisamment de temps pour étudier les effets sur les spécifications et les caches des clients. Nico Flaig, ingénieur chez ChainSafe, a donné son feu vert le 26 octobre après des tests concluants sur Lodestar. Justin Traglia a fusionné le correctif dans la foulée. La modification rejoint ainsi la branche principale du dépôt et la liste des changements que chaque client devra implémenter avant le fork.

Cette séquence illustre le fonctionnement réel de la gouvernance technique d’Ethereum. Les décisions ne relèvent pas d’un vote majoritaire rigide. Elles évoluent avec les nouvelles informations et le temps disponible. Le report de Hoodi a transformé une opposition initiale en acceptation prudente. Les équipes clientes ont pu tester, discuter et finalement valider une modification qui protège des millions d’ETH confiés aux protocoles de staking liquide.

Ce Que Glamsterdam Apporte Au-Delà Du Correctif

Le correctif sur les dépôts ne modifie en rien les deux grandes nouveautés de Glamsterdam. L’ePBS met fin à la confiance que les validateurs accordent aujourd’hui aux relais de MEV-Boost, opérés hors protocole par des acteurs privés. Les builders et les proposeurs échangent désormais dans un cadre intégré au consensus. Les block-level access lists, issues de l’EIP-7928, obligent chaque bloc à lister les emplacements de stockage qu’il lit et modifie. Les nœuds peuvent ainsi exécuter les transactions en parallèle et charger l’état à l’avance. Cette optimisation prépare le terrain à des blocs plus volumineux sans sacrifier la décentralisation.

La mise à jour tourne déjà sur Sepolia depuis le 6 octobre. Hoodi doit recevoir une nouvelle date avant que l’on puisse parler sérieusement du mainnet. L’ordre du jour de l’appel du 22 octobre listait les 1er, 8 et 9 décembre comme dates candidates, à condition que Hoodi se déroule sans accroc. L’histoire récente d’Ethereum montre que les calendriers glissent souvent. L’EIP-3074 avait été retirée de Pectra en mai 2024 au profit de l’EIP-7702, rédigée par Vitalik Buterin deux semaines plus tôt. Dencun et Pectra avaient eux aussi pris plusieurs mois de retard par rapport aux projections initiales.

Rien de neuf sous le soleil d’Ethereum. Les mises à jour majeures avancent par étapes prudentes, avec des reports qui offrent parfois le temps de corriger des détails critiques.

Pourquoi Les Protocoles De Staking Liquide Sont Particulièrement Exposés

Lido, Rocket Pool et les autres protocoles de staking liquide gèrent des volumes considérables d’ETH confié par des utilisateurs qui ne souhaitent pas opérer eux-mêmes un validateur. Ces protocoles déposent des ETH sous des clés publiques contrôlées par des opérateurs. Si un opérateur malveillant ou simplement opportuniste parvient à faire basculer ces dépôts vers un compte de builder, les fonds disparaissent sans création de validateur. Le protocole ne dispose alors d’aucun mécanisme simple pour prouver la perte et récupérer les ETH. C’est précisément ce scénario qu’Avsetsin a mis en lumière. Son analyse a servi de déclencheur. Sans l’intervention de Lido, le correctif aurait probablement attendu une version ultérieure.

Depuis The Merge, Ethereum a enchaîné Shapella, Dencun, Pectra et Fusaka sans interrompre la production de blocs. Chaque mise à jour a apporté son lot de nouveautés et de défis techniques. Glamsterdam s’inscrit dans cette continuité. Les réseaux de test servent de terrain d’expérimentation. Les reports ne sont pas des échecs. Ils constituent des garde-fous qui permettent de corriger des détails avant qu’ils n’atteignent le mainnet. Dans le cas présent, le report de Hoodi a directement permis de sécuriser les dépôts de staking.

Les Implications Pour Les Opérateurs Et Les Stakers

Pour les opérateurs de validateurs, le correctif clarifie la frontière entre dépôt de builder et dépôt de validateur. Ils doivent désormais s’assurer que les withdrawal credentials correspondent bien à l’intention du dépôt. Pour les protocoles de staking liquide, la fusion du correctif apporte une protection supplémentaire avant même le déploiement sur le mainnet. Les utilisateurs qui confient leurs ETH à ces protocoles n’ont pas de démarche particulière à effectuer. La modification se situe au niveau des spécifications de consensus. Les clients l’intégreront progressivement.

Il reste toutefois prudent de suivre l’évolution des tests sur Hoodi. Une nouvelle date d’activation sera annoncée. Les équipes clientes continueront d’examiner les interactions entre ePBS, les nouvelles règles de gaz et la logique des dépôts. Les discussions techniques restent ouvertes. Tout report supplémentaire offrirait encore plus de temps pour peaufiner les implémentations. À l’inverse, un déroulement fluide sur Hoodi pourrait accélérer le passage au mainnet vers décembre.

Une Gouvernance Technique Qui S’Adapte En Temps Réel

Le processus qui a conduit à la fusion du correctif révèle une caractéristique souvent sous-estimée d’Ethereum. Les décisions techniques évoluent avec le contexte. Un report de testnet peut transformer une opposition en consensus. Les acteurs qui portent les risques, comme Lido dans ce cas, jouent un rôle d’alerte. Leur expertise terrain complète le travail des développeurs de clients et des mainteneurs de spécifications. Cette interaction entre protocoles de staking, équipes clientes et coordinateurs de consensus constitue l’un des moteurs de la robustesse du réseau.

Les prochaines semaines seront déterminantes. Hoodi doit recevoir sa nouvelle date. Les tests se poursuivront. Les clients implémenteront la pull request 5736. Les discussions sur les règles de gaz continueront. Glamsterdam avancera, comme les mises à jour précédentes, par étapes mesurées. Pour les stakers, l’essentiel demeure : une faille potentielle a été identifiée, discutée et corrigée avant d’atteindre le mainnet. Le réseau continue de produire des blocs sans interruption. Cette continuité, depuis The Merge, reste l’un des atouts majeurs d’Ethereum face aux défis techniques successifs.

Regard Sur Les Mises À Jour Passées Et Les Leçons Tirées

L’histoire des forks d’Ethereum regorge d’exemples similaires. Des propositions écartées puis réintroduites, des calendriers ajustés, des analyses de sécurité qui déclenchent des reports. Chaque cycle renforce les processus. Les équipes apprennent à mieux anticiper les interactions entre nouvelles fonctionnalités. L’ePBS et les block-level access lists représentent des changements structurels. Leur déploiement exige une vigilance particulière sur les mécanismes de dépôt, de retrait et de tarification. Le correctif fusionné le 26 octobre s’inscrit dans cette culture de prudence.

Les protocoles de staking liquide occupent une place centrale dans l’écosystème. Ils concentrent une part significative de l’ETH staké. Toute vulnérabilité qui les concerne mérite une attention prioritaire. L’intervention de Lido a rappelé que les acteurs de terrain restent essentiels au processus de sécurisation. Leur capacité à analyser rapidement les spécifications, parfois avec l’aide d’outils d’intelligence artificielle comme l’a fait Avsetsin, accélère la détection des problèmes. Les résultats conditionnels qu’il a présentés ont suffi à relancer le débat et à obtenir la fusion du correctif.

Ce Qui Attend Les Utilisateurs Dans Les Prochaines Semaines

Les utilisateurs n’ont aucune action immédiate à entreprendre. Le correctif concerne les spécifications et les clients. Les protocoles de staking liquide continueront de fonctionner normalement. Les dépôts déjà effectués ne sont pas concernés, puisque la faille n’existait que dans des spécifications non déployées. L’attention se porte désormais sur le nouveau calendrier de Hoodi et sur les éventuels ajustements supplémentaires. Les développeurs surveilleront de près le comportement des clients après intégration de la pull request 5736. Toute anomalie détectée sur le testnet pourra encore être corrigée avant le mainnet.

Glamsterdam reste une mise à jour majeure. Elle transforme la relation entre proposeurs et builders. Elle prépare le réseau à une exécution plus parallèle des transactions. Le correctif sur les dépôts de staking constitue un détail technique important, mais il s’inscrit dans un ensemble plus large de changements. La prudence affichée par les équipes, les reports acceptés et la capacité à réintégrer une modification écartée montrent un processus mature. Ethereum continue d’évoluer sans sacrifier la sécurité des fonds stakés. C’est peut-être le message le plus clair de cette séquence d’octobre.

Dans les mois à venir, d’autres discussions techniques surgiront. De nouvelles EIP seront proposées. Des analyses de sécurité pointeront d’éventuelles interactions imprévues. Le même mécanisme de consensus approximatif, de reports et de réouvertures de tickets permettra d’avancer. Les stakers, les opérateurs et les protocoles de staking liquide resteront attentifs. Leur vigilance collective contribue à la résilience du réseau. Le correctif de Glamsterdam sur les dépôts de staking, finalement fusionné, en constitue un exemple concret et récent.

Perspectives Pour Le Mainnet Et Au-Delà

Une fois Hoodi validé, le passage au mainnet pourra être envisagé. Les dates de décembre restent des hypothèses. Elles dépendent entièrement du bon déroulement des tests. Si tout se passe bien, Glamsterdam pourrait arriver avant la fin de l’année. Si de nouveaux points nécessitent des clarifications, le calendrier glissera à nouveau. Cette flexibilité fait partie intégrante de la culture de développement d’Ethereum. Elle a permis de corriger le problème des dépôts avant qu’il ne devienne critique. Elle continuera de guider les prochaines étapes.

Les utilisateurs qui suivent de près les évolutions techniques disposeront bientôt de plus d’informations sur la nouvelle date de Hoodi. Les blogs spécialisés, les comptes des développeurs et les résumés des appels All Core Devs relayeront les annonces. En attendant, le correctif fusionné offre une garantie supplémentaire. Les dépôts destinés aux validateurs des protocoles de staking liquide resteront protégés, même en cas de clé publique partagée avec un builder. Cette distinction claire, introduite par la pull request 5736, ferme une porte qui aurait pu s’ouvrir au moment du fork.

L’épisode rappelle aussi l’importance de la collaboration entre les différentes couches de l’écosystème. Les protocoles de staking, les équipes clientes, les coordinateurs de spécifications et les chercheurs en sécurité forment un réseau d’acteurs complémentaires. Chacun apporte son regard. Lido a joué le rôle d’alerte. ChainSafe a validé sur Lodestar. Prysm a exprimé des réserves tout en acceptant le report. Justin Traglia a fusionné lorsque le consensus s’est formé. Cette dynamique collective a permis de résoudre un point technique en quelques jours une fois le calendrier assoupli.

À plus long terme, Glamsterdam prépare le terrain pour des améliorations futures. L’exécution parallèle des transactions, facilitée par les block-level access lists, ouvre la voie à une augmentation de la capacité du réseau. L’ePBS renforce la décentralisation en réduisant la dépendance aux relais externes. Le correctif sur les dépôts s’assure que ces avancées ne se font pas au détriment de la sécurité des fonds stakés. L’équilibre entre innovation et protection demeure au cœur des priorités. Les événements d’octobre 2026 en apportent une illustration concrète et récente.

Les prochains appels de développeurs préciseront le calendrier. Les tests sur les réseaux de développement continueront. Les clients intégreront les dernières modifications. Les protocoles de staking liquide mettront à jour leurs processus si nécessaire. Les utilisateurs, de leur côté, pourront suivre l’évolution en toute tranquillité. Aucune action urgente n’est requise. Le réseau avance, corrige, teste et déploie. C’est le rythme habituel d’Ethereum depuis le passage au proof-of-stake. Glamsterdam ne déroge pas à cette règle. Le correctif sur les dépôts de staking, d’abord écarté puis fusionné, en est la preuve la plus récente.