Un changement de spécification fusionné le 26 octobre corrige une faille dans le traitement des dépôts d'Ethereum qui aurait pu permettre aux opérateurs de nœuds de rediriger les dépôts des stakers en file d'attente vers des soldes sous leur propre contrôle une fois la mise à niveau Glamsterdam du réseau activée. La correction a été intégrée au dépôt consensus-specs — les règles de référence implémentées par les équipes clientes d'Ethereum — deux semaines après que la faille a été signalée sur GitHub. Seuls les dépôts encore en attente dans la file au moment de l'activation du fork auraient pu être mal acheminés, et comme Glamsterdam n'a pas atteint le mainnet, aucun fonds n'a été perdu.

Comment un opérateur aurait pu s'emparer du dépôt d'un staker

Les protocoles de staking mutualisé répartissent généralement le travail d'exécution d'un validateur. Le protocole fournit l'ETH, tandis qu'un opérateur de nœud externe détient la clé de signature du validateur. Ethereum sépare la signature et les retraits, de sorte qu'un opérateur peut faire fonctionner un validateur sans pouvoir retirer la mise du protocole.

Glamsterdam associe des changements de la couche d'exécution à une mise à niveau de la couche de consensus appelée Gloas et ajoute les builders comme un nouveau type de participant dans le cadre de la séparation Proposer-Builder intégrée au protocole. Les builders assemblent la partie dess portant les transactions et détiennent leurs propres soldes. Au moment du fork, Ethereum convertit les dépôts éligibles encore en attente dans la file en comptes de builders.

C'est dans cette conversion que résidait la faille. Selon l'ancienne règle, dès qu'un dépôt en attente enregistrait un builder pour une clé, tout dépôt ultérieur pour cette clé alimentait le builder, quel que soit l'endroit vers lequel pointaient ses identifiants de retrait. Un opérateur pouvait mettre en file un dépôt de builder pour une nouvelle clé depuis une adresse qu'il contrôlait. Si un protocole de staking finançait ensuite un dépôt de validateur pour la même clé, et que les deux étaient encore en attente au moment du fork, l'ETH du protocole aurait été crédité au solde de builder de l'opérateur, que l'opérateur aurait alors pu retirer. Aucun validateur n'aurait non plus été créé. Certains protocoles ne libèrent le reste d'une mise qu'après la preuve qu'un nouveau validateur porte leurs identifiants de retrait, et cette preuve ne serait jamais arrivée.

Dans un commentaire de suivi, l'auteur du signalement a listé les designs que le bug aurait pu perturber : la garantie de pré-dépôt de Lido, l'OETH d'Origin et Saturn de Rocket Pool, tout en signalant cette liste comme une recherche rapide assistée par IA pouvant contenir des erreurs. Dans chaque cas, l'exposition aurait porté sur un premier dépôt — 1 ETH dans les exemples de Lido et Rocket Pool — le reste de la mise restant bloqué jusqu'à l'exécution des étapes de récupération. L'auteur a décrit ces éléments comme des constats conditionnels dans le code, et non comme des exploitations en cours.

Rejeté le 19 octobre, fusionné une semaine plus tard

La correction a été proposée le 12 octobre. Après des discussions lors de deux appels de développeurs core, elle a été fermée le 19 octobre faute de support des clients, et l'appel de test avait évoqué un prototypage après la mise à niveau du testnet Hoodi plutôt que de perturber le calendrier.

Trois jours plus tard, la Fondation Ethereum a reporté l'activation de Glamsterdam sur Hoodi pour étudier comment l'EIP-8037 interagit avec les smart contracts existants, un problème sans lien avec les dépôts. Ce temps supplémentaire a relancé le débat. Un commentaire du 23 octobre sur l'ordre du jour du prochain appel de test a lié le changement sur les dépôts au calendrier révisé, l'auteur a ajouté le jour même des tests d'ordre des dépôts, et le changement a été fusionné le 26 octobre.

Ce que fait la nouvelle règle

Après le fork, les dépôts de builders et de validateurs empruntent déjà des chemins distincts en vertu de l'EIP-82. La correction applique la même logique à la file d'attente au moment du fork : les identifiants de retrait, et non la clé publique, déterminent la destination de chaque dépôt en attente.

La réutilisation d'une même clé pour un validateur et un builder reste autorisée ; la finalité déclarée dans chaque dépôt détermine désormais le compte qu'il alimente.

Ce qui reste à faire avant le fork

La fusion de la spécification n'est que la première étape ; les équipes clientes doivent désormais implémenter la même règle. Un changement Teku ouvert le 27 octobre était toujours en revue, et l'équivalent Lodestar restait ouvert.

Un changement tardif doit également être intégré de manière identique dans chaque client. Les anciens tests de référence encodent le routage précédent, de sorte qu'un client suivant la nouvelle règle les échoue. L'auteur de Teku indique avoir réussi les tests générés à partir de la spécification mise à jour, qui n'a pas encore été empaquetée dans une version de la spécification. Si les clients atteignaient le fork en appliquant des règles différentes à la même file d'attente, ils calculeraient des soldes différents et seraient en désaccord sur l'état de la chaîne.

La Fondation n'a pas fixé de nouvelle date pour Hoodi ni pour le mainnet de Glamsterdam. Les protocoles de staking qui s'appuient sur des preuves de dépôt disposent aussi de leur propre ligne de défense : selon l'auteur du signalement, des vérifications de pré-dépôt rejetant une clé portant déjà un dépôt de builder peuvent prévenir ce scénario. Les indicateurs à surveiller désormais sont les deux pull requests clients encore ouvertes, une version de la spécification empaquetant les tests mis à jour, et de nouvelles dates pour Hoodi et le mainnet.