Ethereum Corrige Faille Glamsterdam Dépôts

Imaginez un instant qu’un opérateur malin puisse, en quelques manœuvres techniques, faire atterrir des millions d’ETH destinés à créer de nouveaux validateurs directement sur son propre compte de builder. C’est exactement le scénario que les développeurs d’Ethereum ont découvert au cœur de l’upgrade Glamsterdam. Et après avoir d’abord rejeté le correctif, ils ont finalement fait marche arrière.

Ethereum Corrige Une Faille Critique Dans Glamsterdam

Le 26 octobre 2026, Justin Traglia, mainteneur des spécifications de consensus d’Ethereum, a fusionné un correctif important. Ce changement porte sur la façon dont les dépôts en attente sont traités lors du passage à la fork Gloas, partie intégrante de l’upgrade Glamsterdam. Le risque ? Qu’un builder reçoive des fonds destinés à un validateur simplement parce que les deux utilisaient la même clé publique.

Cette faille n’existait pas encore sur le réseau principal. Elle concernait uniquement les règles en cours d’élaboration. Pourtant, les implications étaient suffisamment sérieuses pour que la communauté reverse sa décision initiale et impose des tests supplémentaires.

Comment la faille aurait pu fonctionner

Avec l’arrivée de l’enshrined proposer-builder separation (PBS), Ethereum sépare clairement les rôles. Les builders assemblent les payloads de transactions. Les validateurs proposent et confirment les blocs. Cette séparation apporte de nombreux avantages, mais elle a aussi introduit une subtilité dangereuse dans le traitement des dépôts.

Le chercheur avsetsin a mis en lumière le problème dès le 12 octobre. Si un builder s’enregistrait avec une clé publique avant qu’un dépôt de validateur n’arrive sous la même clé, la logique prévue créditait les deux montants au builder. Les fonds destinés à créer un nouveau validateur se retrouvaient donc dans le solde du builder, avec une adresse de retrait potentiellement contrôlée par l’opérateur.

L’opérateur peut retirer les fonds du protocole.

avsetsin, rapport GitHub

Dans un scénario concret, un opérateur de staking reçoit des fonds d’un protocole de liquid staking pour lancer un nouveau validateur. En s’enregistrant d’abord comme builder, il pouvait détourner le dépôt. Le validateur attendu n’était jamais créé, et le protocole de staking se retrouvait dans l’impossibilité d’obtenir les preuves nécessaires pour récupérer ou finaliser le dépôt.

Un retournement de situation inattendu

Le 19 octobre, Justin Traglia avait fermé la pull request. Les discussions entre développeurs de clients n’avaient pas suffi à convaincre. « Il n’y avait pas assez de soutien des clients pour faire ce changement à ce moment-là », avait-il écrit. Beaucoup estimaient que le risque restait théorique ou que d’autres priorités prenaient le dessus.

Quatre jours plus tard, le 23 octobre, la proposition était rouverte. Après un examen plus approfondi, le reviewer potuz a approuvé l’approche, mais a demandé des tests supplémentaires pour des combinaisons de dépôts spécifiques. Avsetsin a fourni ces tests le même jour. Le 26 octobre, le correctif était finalement fusionné dans les spécifications de consensus.

Ce retournement illustre bien la culture d’Ethereum. Les décisions techniques restent ouvertes à la discussion, même après un rejet initial. La sécurité du réseau prime sur la rigidité du calendrier.

Impact potentiel sur les protocoles de staking

Avsetsin a examiné de manière préliminaire l’exposition de plusieurs protocoles majeurs. Lido, Origin et Rocket Pool figuraient parmi ceux étudiés. Les conclusions restaient conditionnelles : tout dépendait de la façon dont chaque protocole gérait ses dépôts et de l’ordre dans lequel les opérations étaient effectuées.

Aucun exploit réel n’a été constaté. La faille n’existait que dans les règles en développement. Pourtant, le simple fait qu’un scénario aussi clair ait pu être imaginé a suffi à convaincre la majorité des développeurs de sécuriser le mécanisme avant le déploiement.

Les protocoles de liquid staking gèrent des volumes considérables. Un détournement, même temporaire, aurait pu créer une crise de confiance et des complications opérationnelles importantes pour récupérer les fonds.

Glamsterdam et le report du testnet Hoodi

Le correctif arrive dans un contexte déjà tendu. L’activation de Glamsterdam sur le testnet Hoodi, initialement prévue le 26 octobre, a été reportée. La raison n’est pas liée aux dépôts, mais à un problème de compatibilité avec l’EIP-8037.

Le chercheur Toni Wahrstätter a expliqué que cette EIP pouvait interférer avec des contrats intelligents qui reposent sur des hypothèses précises concernant le gaz restant pendant l’exécution. Dans certains cas, la comptabilité du gaz pouvait provoquer un revert inattendu ou ouvrir un chemin d’exécution que les développeurs pensaient inaccessible.

La Fondation Ethereum a donc retiré à la fois les changements d’exécution Amsterdam et les changements de consensus Gloas du calendrier Hoodi. L’augmentation proposée de la limite de gaz à 200 millions a également été mise en pause.

Glamsterdam a déjà été activé avec succès sur le testnet Sepolia le 6 octobre. Les développeurs ont pu y observer les changements de construction de blocs et la capacité de traitement accrue. Le prochain test sur Hoodi reste sans date confirmée, et aucun calendrier précis n’existe encore pour le réseau principal.

Pourquoi cette séparation builder-validateur est stratégique

L’enshrined PBS représente une évolution majeure pour Ethereum. En intégrant directement dans le protocole la séparation entre ceux qui construisent les blocs et ceux qui les proposent, le réseau cherche à réduire les risques de centralisation et à améliorer l’équité du MEV (Maximal Extractable Value).

Jusqu’à présent, cette séparation reposait en grande partie sur des solutions hors protocole. L’intégration native offre plus de garanties, mais elle complexifie aussi le traitement de certaines opérations, notamment les dépôts. C’est précisément dans cette zone grise que la faille a pu apparaître.

Les credentials de retrait deviennent désormais l’élément clé de distinction. Même si deux entités partagent la même clé publique, le type de credentials détermine si les fonds alimentent un solde builder ou une file de validateurs.

Ce que doivent faire les équipes clients

Le correctif est maintenant dans les spécifications de consensus. Cela ne signifie pas qu’il est déjà actif. Chaque équipe de client de consensus doit intégrer le changement dans son logiciel, puis le tester minutieusement.

Les tests de régression inclus dans la fusion couvrent les cas où un dépôt builder et un dépôt validateur partagent la même clé publique. Ces tests sont essentiels pour s’assurer qu’aucune régression n’apparaît lors des futures activations.

La coordination entre clients reste un défi permanent. Une implémentation incomplète ou divergente pourrait créer des incohérences lors d’une future fork. Les équipes disposent désormais de plus de temps grâce au report de Hoodi pour finaliser ces travaux.

Une culture de sécurité qui s’affirme

Ce qui ressort de cet épisode, c’est la capacité d’Ethereum à remettre en question ses propres décisions. Rejeter un correctif, puis le réintégrer après de nouveaux arguments, montre une maturité technique. La pression du calendrier n’a pas primé sur la solidité du protocole.

Dans un écosystème où les montants en jeu se comptent en milliards, ce type de vigilance est crucial. Les protocoles de staking liquid, les opérateurs de nœuds et les utilisateurs finaux bénéficient tous d’un processus de revue qui n’hésite pas à ralentir pour mieux sécuriser.

Avsetsin a joué un rôle central en documentant clairement le scénario d’attaque et en fournissant les tests demandés. La collaboration entre chercheurs indépendants et mainteneurs du protocole reste l’un des atouts majeurs d’Ethereum.

Les prochaines étapes pour Glamsterdam

Avec Hoodi reporté, les développeurs disposent d’une fenêtre pour approfondir l’investigation sur l’EIP-8037 et pour finaliser l’implémentation du correctif de dépôts. Aucune date n’a encore été annoncée pour la réactivation sur Hoodi, ni pour le déploiement sur le réseau principal.

Les utilisateurs et les protocoles de staking peuvent suivre l’évolution via les spécifications de consensus et les discussions publiques. La transparence du processus permet à chacun de comprendre les enjeux et de se préparer aux changements.

Glamsterdam vise à améliorer significativement la capacité de traitement et à formaliser la séparation des rôles. Ces objectifs restent intactes. Seul le calendrier a été ajusté pour intégrer les leçons apprises en octobre.

Pourquoi ce correctif compte pour tout l’écosystème

Au-delà de la technique pure, cet épisode rappelle que chaque upgrade majeure introduit de nouvelles surfaces d’attaque potentielles. La complexité croissante du protocole nécessite une attention constante, même sur des mécanismes qui semblent secondaires.

Les dépôts de validateurs représentent le point d’entrée de nouveaux participants dans le consensus. Protéger ce flux est essentiel pour maintenir la confiance et la décentralisation. Un bug qui aurait permis de détourner ces fonds, même dans un scénario limité, aurait pu freiner l’adoption de nouveaux validateurs.

En choisissant de corriger plutôt que de reporter le problème à plus tard, les développeurs ont envoyé un signal clair : la sécurité prime, même si cela implique de ralentir le rythme des déploiements.

Regard sur les risques restants

Le correctif ne résout pas tous les défis de Glamsterdam. L’investigation autour de l’EIP-8037 se poursuit. D’autres interactions complexes entre les nouvelles règles de gaz et les contrats existants pourraient encore être découvertes.

Les équipes de clients doivent également s’assurer que l’implémentation du correctif de dépôts est homogène. Toute divergence pourrait créer des problèmes de consensus lors d’une activation future.

Enfin, les protocoles de staking auront intérêt à revoir leurs propres flux de dépôts pour s’assurer qu’ils restent robustes face aux nouvelles distinctions entre builder et validateur.

Une leçon de gouvernance technique

Le parcours de cette pull request – ouverte, fermée, rouverte, puis fusionnée – offre un exemple concret de gouvernance ouverte. Les arguments techniques ont finalement prévalu sur les résistances initiales. Les tests demandés ont été fournis rapidement, et la décision a été prise de manière transparente.

Cette capacité à changer d’avis sans rigidité excessive est précieuse. Dans un environnement où les enjeux financiers sont énormes, elle contribue à maintenir la crédibilité du processus de développement.

Pour les observateurs extérieurs, cet épisode montre aussi que les upgrades d’Ethereum ne sont jamais de simples mises à jour logicielles. Elles impliquent des discussions approfondies, des compromis et parfois des retours en arrière pour garantir la solidité du réseau.

Conclusion : un réseau qui avance avec prudence

Ethereum a choisi de corriger une faille potentielle avant qu’elle n’existe réellement sur le réseau principal. Ce choix, même s’il a nécessité un retournement de décision, renforce la confiance dans le processus. Glamsterdam continuera son chemin, mais avec des bases plus solides concernant le traitement des dépôts.

Les prochains mois seront déterminants. Entre la résolution des questions liées à l’EIP-8037 et l’implémentation homogène du correctif par les clients, le calendrier reste ouvert. Une chose est certaine : la communauté a démontré qu’elle savait prioriser la sécurité, même face à la pression du déploiement.

Dans un univers crypto souvent marqué par la précipitation, cette approche méthodique constitue un atout majeur pour l’avenir d’Ethereum et de son écosystème de staking.