Imaginez un instant : vous envoyez des fonds pour créer un nouveau validateur Ethereum, et ces ETH atterrissent soudainement sur le compte d’un builder de blocs. Pas sur le mainnet aujourd’hui, mais dans les règles mêmes d’une future mise à jour. C’est exactement le scénario qu’un chercheur a mis au jour, et qui a poussé les développeurs à faire machine arrière après avoir d’abord rejeté la correction. Glamsterdam, l’upgrade attendue, vient de connaître un rebondissement technique digne d’un thriller de protocole.
Une faille discrète mais potentiellement coûteuse dans les règles de dépôt
Le 26 octobre, Justin Traglia, mainteneur des spécifications de consensus d’Ethereum, a fusionné une correction importante. Elle concerne le traitement des dépôts en attente lors du fork Gloas, partie intégrante de Glamsterdam. Le problème ? Une logique de traitement qui pouvait, dans certaines conditions, créditer un builder plutôt qu’un validateur lorsque les deux utilisaient la même clé publique.
Ce n’était pas une vulnérabilité active sur le réseau principal. Aucun vol n’a eu lieu. Il s’agissait de règles encore en développement. Pourtant, le risque était clair : un opérateur malintentionné ou simplement opportuniste pouvait enregistrer d’abord une identité de builder, puis laisser arriver un dépôt de validateur sous la même clé. Résultat possible : les fonds destinés au staking se retrouvaient sur le solde du builder, dont l’adresse de retrait pouvait être contrôlée par cet opérateur.
Le chercheur avsetsin a décrit le scénario le 12 octobre. Un opérateur de staking reçoit des fonds d’un protocole de liquid staking pour lancer un nouveau validateur. En s’enregistrant préalablement comme builder, il pouvait détourner le dépôt. « L’opérateur peut retirer les fonds du protocole », a-t-il prévenu dans son rapport GitHub. Et comme le validateur attendu n’était jamais créé, le service de staking risquait de se retrouver sans la preuve nécessaire pour récupérer ou finaliser correctement ses opérations.
Comment la séparation enshrined proposer-builder a ouvert la porte
Glamsterdam introduit l’enshrined proposer-builder separation. Concrètement, la construction des blocs et leur proposition sont désormais des rôles distincts. Les builders assemblent les payloads de transactions. Les validateurs se concentrent sur la proposition et la confirmation dans le système de preuve d’enjeu.
Cette séparation améliore l’efficacité et réduit certains risques de centralisation. Mais elle a aussi créé une zone grise dans le traitement des dépôts pendant la transition. Lorsque des dépôts de builder et de validateur partageaient la même clé publique, la logique initiale ne distinguait pas clairement les deux. Les credentials de retrait, qui déterminent les adresses autorisées à retirer les fonds, n’étaient pas suffisamment pris en compte pour séparer les enregistrements.
Avsetsin a exploré l’exposition potentielle de protocoles comme Lido, Origin ou Rocket Pool via une analyse préliminaire du code. Ses conclusions restaient conditionnelles : tout dépendait de la façon dont chaque protocole gérait concrètement les dépôts. Aucune exploitation n’a été démontrée. Le rapport servait avant tout d’alerte sur un chemin d’attaque théorique, mais crédible.
Le danger n’était pas une faille déjà exploitable sur le mainnet, mais une faille dans les règles futures qui aurait pu devenir réelle une fois Glamsterdam activé.
Le rebondissement : rejet puis acceptation de la correction
Le 19 octobre, Justin Traglia ferme la pull request. « Il n’y avait pas assez de soutien de la part des clients pour effectuer ce changement à ce stade », écrit-il. Les discussions entre développeurs de clients consensus n’avaient pas convaincu une majorité suffisante.
Quatre jours plus tard, le 23 octobre, la proposition est rouverte. Une nouvelle revue a changé la donne. Le reviewer potuz approuve l’approche, mais demande des tests supplémentaires pour des combinaisons spécifiques de dépôts. Avsetsin ajoute ces tests le même jour. Ils couvrent les cas où builder et validateur partagent une clé publique tout en nécessitant un traitement séparé.
Le 26 octobre, la correction est finalement fusionnée dans les spécifications de consensus. Désormais, les dépôts de validateur valides sont dirigés vers la file d’attente des validateurs. Les dépôts légitimes de builders s’enregistrent ou alimentent un builder existant. La distinction se fait via les withdrawal credentials. Même si la même clé publique apparaît dans les deux rôles, les enregistrements restent séparés.
Cette capacité à reconsidérer une décision technique sous la pression d’arguments supplémentaires montre une certaine maturité du processus de développement. Les clients doivent encore implémenter et tester le nouveau comportement, mais la spécification est désormais claire.
Hoodi reporté : un autre problème ralentit le calendrier
Pendant que cette correction prenait forme, un autre sujet bloquait le calendrier. L’activation de Glamsterdam sur le testnet Hoodi, prévue initialement autour du 26 octobre, a été reportée. La raison : des risques de compatibilité liés à l’EIP-8037.
Cette proposition augmentait la limite de gas à 200 millions. Or, certains smart contracts reposent sur des hypothèses précises concernant le gas restant pendant l’exécution. Toni Wahrstätter a identifié des cas où la comptabilisation du gas pouvait faire échouer une transaction de façon inattendue ou ouvrir un chemin d’exécution que les développeurs pensaient inaccessible.
Le report a retiré à la fois les changements d’exécution Amsterdam et les changements de consensus Gloas du calendrier Hoodi d’octobre. Ce problème de compatibilité contractuelle est distinct de la faille des dépôts. Les deux concernent Glamsterdam, mais les causes et les solutions n’ont rien à voir.
Glamsterdam a déjà été activé sur Sepolia le 6 octobre. Les développeurs y ont testé les nouvelles mécaniques de construction de blocs et la capacité de traitement accrue. Hoodi, qui devait servir de répétition plus poussée, n’a plus de date confirmée. L’activation sur le mainnet reste, elle aussi, sans échéance officielle.
Ce que change concrètement la nouvelle logique de dépôt
Avant la correction, le traitement des dépôts en attente pendant le fork pouvait fusionner ou mal attribuer des soldes. Après, les règles sont explicites :
• Un dépôt de validateur valide entre dans la file d’attente des validateurs.
• Un dépôt de builder légitime s’enregistre ou augmente le solde d’un builder existant.
• Les withdrawal credentials servent de critère de distinction principal.
• Même clé publique ne signifie plus même enregistrement.
Cette séparation protège les protocoles de liquid staking et les opérateurs qui utilisent des flux de dépôts complexes. Elle évite qu’un acteur puisse s’interposer entre un protocole et son futur validateur simplement en s’enregistrant plus tôt comme builder.
Les tests de régression ajoutés couvrent précisément ces cas limites. Ils devront être exécutés par chaque équipe de client consensus avant qu’une future activation puisse se faire en toute confiance.
Pourquoi cette histoire compte au-delà de la technique
Les upgrades Ethereum sont de plus en plus complexes. Chaque nouvelle fonctionnalité – enshrined PBS, augmentation de gas limit, changements de règles de dépôt – introduit des interactions imprévues. La découverte d’avsetsin rappelle qu’une analyse approfondie des chemins d’exécution pendant les transitions de fork reste indispensable.
Le fait que la correction ait d’abord été rejetée puis acceptée illustre aussi la dynamique des discussions entre mainteneurs de spécifications et équipes de clients. Le soutien des clients n’est pas automatique. Il faut des arguments solides, des tests concrets et parfois plusieurs allers-retours.
Pour les utilisateurs et les protocoles de staking, l’épisode est plutôt rassurant. Une faille potentielle a été identifiée tôt, discutée publiquement, testée et corrigée dans les spécifications avant toute activation critique. C’est le fonctionnement normal d’un protocole ouvert et scrutinisé.
Points clés à retenir
• Faille identifiée le 12 octobre dans le traitement des dépôts pendant Gloas
• Correction d’abord rejetée le 19, puis fusionnée le 26 octobre
• Distinction désormais claire via les withdrawal credentials
• Hoodi reporté à cause d’un autre problème (EIP-8037)
• Clients doivent encore implémenter et tester la nouvelle logique
Les prochaines étapes pour les équipes de clients
La spécification est mise à jour. Reste le travail d’implémentation. Chaque client consensus – Lighthouse, Prysm, Teku, Nimbus, Lodestar et les autres – doit intégrer le nouveau comportement de classification des dépôts. Les tests de régression fournis dans la correction devront passer avec succès.
Ce n’est qu’après ces étapes que la logique corrigée pourra être activée lors d’une future transition de réseau. En parallèle, les développeurs continuent d’étudier les interactions de l’EIP-8037 avec les contrats existants. Tant que cette question n’est pas clarifiée, le calendrier Hoodi reste en suspens.
Sepolia a déjà servi de terrain d’essai pour les mécaniques de construction de blocs. Hoodi devait offrir une validation supplémentaire dans un environnement plus proche des conditions réelles. Son report donne du temps, mais il allonge aussi l’attente avant une éventuelle activation sur le mainnet.
Un rappel sur la vigilance nécessaire autour du staking
Les protocoles de liquid staking gèrent des volumes importants de dépôts. Ils s’appuient sur des flux automatisés et des preuves pour créer et récupérer des validateurs. Toute ambiguïté dans les règles de dépôt pendant une transition de fork peut créer des frictions opérationnelles, voire des pertes si un acteur malveillant s’engouffre dans la brèche.
Dans le scénario décrit, le validateur n’était jamais créé. Le protocole se retrouvait alors sans la preuve attendue pour poursuivre ses procédures habituelles de dépôt et de recovery. Même sans intention malveillante, une mauvaise attribution de fonds aurait pu générer des complications importantes.
La correction via les withdrawal credentials apporte une solution élégante. Elle préserve la possibilité d’utiliser la même clé publique dans des rôles différents tout en garantissant que les soldes et les droits de retrait restent distincts. C’est une amélioration de robustesse sans sacrifier la flexibilité.
Glamsterdam : où en est vraiment l’upgrade ?
Glamsterdam combine des changements d’exécution (Amsterdam) et de consensus (Gloas). L’objectif est d’améliorer la capacité de traitement des transactions et d’introduire des mécanismes plus sophistiqués de séparation des rôles dans la production de blocs.
Sepolia a reçu l’upgrade le 6 octobre. Les observations y ont porté sur la construction de blocs et la montée en charge. Hoodi, prévu ensuite, a été retiré du calendrier d’octobre. Aucune nouvelle date n’a été annoncée. Le mainnet, de son côté, attend que les problèmes identifiés – compatibilité EIP-8037 et désormais implémentation de la correction de dépôt – soient pleinement résolus et testés.
Ce rythme prudent n’est pas nouveau. Les développeurs Ethereum privilégient depuis longtemps la sécurité et la stabilité aux délais annoncés trop tôt. Chaque report ou correction supplémentaire renforce, à terme, la confiance dans le processus.
Ce que révèle cet épisode sur la gouvernance technique d’Ethereum
La discussion autour de cette pull request a été publique. Le rapport initial, la fermeture, la réouverture, l’ajout de tests et la fusion finale sont tous documentés. Cette transparence permet à la communauté de suivre les arbitrages et de comprendre pourquoi certaines décisions sont prises, puis parfois révisées.
Le rôle des clients est déterminant. Même si une correction semble pertinente sur le plan logique, elle n’entre dans les spécifications que si les équipes qui devront l’implémenter y trouvent un soutien suffisant. Les tests supplémentaires demandés par potuz ont clairement joué un rôle dans le retournement de situation.
On voit aussi l’importance des chercheurs indépendants. Avsetsin a non seulement identifié le problème, mais a fourni un scénario concret et a ensuite enrichi la correction avec les tests demandés. Ce type de contribution reste essentiel pour un protocole aussi complexe.
Au final, Ethereum a corrigé une faille avant qu’elle ne devienne réelle. Le chemin a été un peu chaotique – rejet puis acceptation –, mais le résultat est là. Les spécifications sont plus robustes, les clients ont une feuille de route claire, et les protocoles de staking disposent d’une protection supplémentaire pour les transitions futures.
La suite dépendra de la résolution du dossier EIP-8037 et de la capacité des équipes clients à intégrer et valider rapidement la nouvelle logique de dépôt. En attendant, Glamsterdam reste une upgrade en construction, plus prudente, et désormais un peu plus sûre grâce à ce rebondissement d’octobre.
