Les développeurs du cœur d’Ethereum ont décidé de ne pas modifier une règle de la mise à jour Glamsterdam qui peut, dans des conditions étroites, créditer des ETH destinés à un nouveau validateur de staking sur le solde d’un « builder » (constructeur de blocs) contrôlé par un opérateur de nœud. Le problème a été déposé le 12 octobre sous la forme de l’issue n° 5735 du dépôt consensus-specs, par un développeur qui poste sous le pseudonyme avsetsin sur GitHub. Le mainteneur des spécifications, Justin Traglia, l’a fermée le 19 octobre avec le motif « not planned » (non prévu), faute de soutien des équipes de clients. Aucun exploit et aucune perte n’ont été signalés. Le risque lié aux dépôts de staking sur Glamsterdam ne concerne que les dépôts encore en file d’attente à l’activation du fork, et seulement les protocoles qui financent des validateurs exploités par un tiers.
Dmitry (Dima) Gusakov, qui indique sur GitHub être responsable de l’ingénierie (head of engineering) chez Lido, le titre que reprend aussi Crypto Briefing, avait demandé le 14 octobre que le sujet soit examiné lors de la réunion des développeurs de la couche de consensus (ACDC n° 189) du lendemain. blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il est revenu à l’ordre du jour de la réunion consacrée aux tests (ACDT n° 101) du 19 octobre. La spécification reste donc telle qu’elle est écrite, et les protocoles de staking doivent se prémunir eux-mêmes dans leurs propres contrats. Glamsterdam arrive sur le testnet Hoodi le 26 octobre. Le mainnet n’a pas encore de date.
Les développeurs ont refermé le correctif le 19 octobre, trois jours après s’y être dits favorables
Justin Traglia a fermé le correctif associé, la pull request n° 5736, à 16 h 02 UTC le 19 octobre, puis l’issue trois minutes plus tard. Sa note de clôture indique que le sujet a été discuté lors des deux réunions et qu’il n’y avait « pas assez de soutien de la part des clients pour faire ce changement pour le moment ». Il a posté les mêmes mots sur la pull request.
C’est un revirement. Le 16 octobre, dans le fil d’ordre du jour de la réunion du 19, Traglia écrivait qu’il était « légèrement favorable » au changement. Son plan excluait Hoodi, demandait aux clients de réaliser un prototype, fusionnait le changement après Hoodi, le testait sur un devnet éphémère et ne retardait pas le mainnet. Il ajoutait que cela éviterait à « tous les autres systèmes DVT » d’avoir à intégrer leur propre correctif (DVT, pour distributed validator technology, répartit la clé d’un validateur entre plusieurs machines ou opérateurs).
Qui s’est opposé au changement pendant les réunions, et pourquoi, n’est pas public. Lors de notre vérification, aucune note écrite des réunions des 15 et 19 octobre n’avait été publiée, et aucune équipe de client ni aucun membre de la Fondation Ethereum ne s’était exprimé sur ce risque. La seule autre trace publique d’un développeur de client est une question de Michael Sproul, de Lighthouse, le 13 octobre : le correctif était-il compatible avec le fork de Sepolia, déjà passé ? Nico Flaig, de Lodestar, a répondu que Sepolia n’avait jamais testé l’intégration des builders, car le contrat de dépôt y exige un jeton particulier.
Builders, dépôts et ePBS : ce qu’il faut savoir pour comprendre
Pour staker sur Ethereum, on envoie des ETH au contrat de dépôt avec deux données essentielles : la clé publique du validateur et ses identifiants de retrait (withdrawal credentials). Ces identifiants disent où part l’ETH quand il quitte le staking. Ceux qui commencent par 0x01 pointent vers une adresse Ethereum ordinaire ; 0x02 fait de même mais permet de composer les récompenses, avec un solde pouvant atteindre 2 048 ETH par validateur.
Un dépôt ne compte pas immédiatement. Il rejoint une file de dépôts en attente que la chaîne traite à un rythme plafonné. Le 19 octobre, cette file contenait environ 1,2 million d’ETH et demandait quelque 21 jours pour se vider, comme nous l’avons relaté dans notre article sur la file d’entrée du staking. Avec une file aussi longue, des dépôts envoyés plusieurs semaines avant un fork peuvent encore être en attente au moment où il survient.
Les builders forment l’autre moitié de l’histoire. Gloas, la moitié « consensus » de Glamsterdam, introduit la séparation proposeur-constructeur intégrée au protocole (ePBS, EIP-7732, inscrite comme prévue pour la mise à jour dans la méta-EIP de Glamsterdam), que nous avons expliquée lors du passage de Glamsterdam en direct sur Sepolia. Une conséquence compte ici : les builders disposent de leur propre solde sur la Beacon Chain. Un builder s’enregistre par un dépôt effectué via le même contrat de dépôt, avec des identifiants de retrait qui commencent par 0xB0.
Le fork a donc un travail de tri à faire. À l’activation de Gloas, la chaîne doit décider quels dépôts en attente concernent des validateurs et lesquels créent ou alimentent des builders. C’est dans cette règle de tri que se situe le problème.
Risque dépôt staking Glamsterdam : comment un dépôt de validateur atterrit sur le solde d’un builder
La règle se trouve dans une fonction de transition du fork nommée onboard_builders_from_pending_deposits, et elle trie les dépôts en attente par clé publique. Dès qu’un dépôt en attente enregistre un builder pour une clé, tous les dépôts en attente suivants pour cette même clé alimentent le builder, quels que soient leurs identifiants de retrait.
L’issue décrit un protocole de staking qui travaille avec des opérateurs de nœuds extérieurs. Le protocole finance le premier dépôt de l’opérateur pour un validateur, puis attend la preuve que le validateur existe avec les identifiants de retrait du protocole avant d’envoyer le reste. Supposons que l’opérateur mette d’abord en file un dépôt de builder valide (0xB0, pointant vers sa propre adresse) pour une clé neuve, et que le dépôt de validateur 0x02 du protocole pour cette clé soit lui aussi en attente au moment du fork. Selon l’issue, « les deux montants vont au builder. L’opérateur peut retirer les fonds du protocole ».
Aucun validateur n’est créé. Le protocole ne reçoit pas la preuve qu’il attendait, peut ne pas être en mesure de démontrer ce qui s’est passé, et peut se retrouver avec une comptabilité faussée ou des fonds bloqués, d’après l’issue.
Deux limites comptent. Le danger ne vise que les dépôts en attente de part et d’autre de la frontière du fork ; après Gloas, les dépôts de builders et de validateurs suivent des chemins distincts. Et il diffère du front-running auquel Lido a fait face en 2021 (voir plus bas) : ici, les identifiants de retrait du protocole sont bien enregistrés avec son dépôt, et c’est le tri ponctuel du fork qui les ignore.
Qui pourrait être exposé, selon une liste que son auteur juge non vérifiée
Le scénario suppose un financeur qui n’est pas le détenteur de la clé, un opérateur capable de soumettre un dépôt de builder pour la même clé, et un financement par étapes où un petit dépôt précède le reste. Quelqu’un qui stake avec ses propres fonds et contrôle sa propre clé n’entre pas dans ce cadre.
Dans un second commentaire sur l’issue, le même auteur cite trois protocoles qui pourraient être touchés. Ce commentaire se présente comme une « recherche rapide par IA » qui « peut contenir des erreurs ». Il qualifie ses conclusions de lectures conditionnelles du code, non d’exploits réels confirmés, et précise que des gels permanents ne sont pas établis. Coindaro n’a pas vérifié ces affirmations, et aucun des trois protocoles ne les avait confirmées publiquement lors de notre vérification. Le tableau ci-dessous reprend ce que dit le commentaire, rien de plus.
| Protocole et produit | Ce que le commentaire assisté par IA affirme possible | Piste de récupération qu’il suggère |
|---|---|---|
| Lido, Predeposit Guarantee utilisé par les stVaults | Le vault perd son prédépôt de 1 ETH ; la garantie de 1 ETH de l’opérateur reste bloquée ; 31 ETH restent en attente | Rejouer le prédépôt signé après le fork, ou déconnecter le vault et changer de déposant |
| Origin, stratégie de staking natif d’OETH | Le dépôt manquant bloque les vérifications de solde, alors que le vault compte toujours l’ETH perdu | Rejouer le dépôt signé |
| Rocket Pool, megapools de Saturn | Le validateur manquant empêche une dissolution rapide ; les 31 ETH restants attendent l’expiration d’un délai | Le capital des utilisateurs est remboursé en premier, le manque devient une dette de l’opérateur |
Le même commentaire indique que les contrats vérificateurs des trois protocoles doivent de toute façon être mis à jour pour Gloas, et pour l’EIP-7688, qui change l’organisation des structures de données du consensus. Pour le contexte sur les deux protocoles qui ont une page Coindaro, voir nos fiches sur Lido et sur Rocket Pool et sa mise à niveau Saturn.
Le circuit principal de stETH chez Lido, celui des modules d’opérateurs sélectionnés, n’est pas nommé dans l’issue. Crypto Briefing désigne le Deposit Security Module de Lido et son comité de gardiens comme la défense existante, et laisse ouverte la question de leur couverture des dépôts de builders. C’est une interrogation du média, pas une conclusion, et Lido n’avait fait aucune déclaration au-delà des commentaires de Gusakov lors de notre vérification. Personne n’a chiffré le montant d’ETH en jeu.
Lido a déjà connu une course aux dépôts en 2021
Le nouveau cas ressemble à un ancien. Le 5 octobre 2021, un signalement via le programme de bug bounty de Lido a montré qu’un opérateur de nœud pouvait devancer (front-run) les dépôts du protocole. À l’époque, le premier dépôt pour une clé fixait définitivement ses identifiants de retrait : un opérateur qui déposait en premier avec ses propres identifiants pouvait capter ce que Lido envoyait ensuite. Lido a suspendu les dépôts depuis son tampon et, le 14 octobre 2021, a publié la LIP-5, selon laquelle un comité de gardiens valide les données de dépôt avant que les ETH ne bougent.
Parmi les options listées alors figurait un changement de long terme au niveau de la couche de consensus. La première option de cette liste de 2021 était le prédépôt : l’opérateur dépose 1 ETH avec les identifiants de retrait du protocole, le protocole vérifie, puis envoie le reste. Cinq ans plus tard, c’est ce contrôle par prédépôt sur lequel on demande de nouveau aux protocoles de s’appuyer.
Les contrôles de prédépôt font désormais office de défense, avec un correctif côté client
Le commentaire de suivi de l’auteur nomme la réponse côté protocole : « Des contrôles de prédépôt qui rejettent un dépôt de builder antérieur peuvent empêcher ce scénario. » Concrètement, un protocole chercherait un dépôt 0xB0 antérieur sur la clé avant de financer le reste.
Une partie de la presse a écrit que le correctif rejeté aurait « ajouté des contrôles de prédépôt ». Ce n’est pas ce que fait la pull request n° 5736. Elle aurait changé le tri au moment du fork, en s’appuyant sur les identifiants de retrait plutôt que sur la seule clé :
- les dépôts de validateurs restent dans la file des validateurs même si un builder utilise la même clé ;
- un dépôt de builder valide enregistre ou alimente un builder même si un validateur utilise la clé ;
- un dépôt de builder pour un builder existant l’alimente quelle que soit sa signature ;
- un dépôt de builder invalide sans builder derrière lui reste en file seulement si un validateur avec cette clé existe ou si un dépôt de validateur valide antérieur est en file, et il est écarté dans le cas contraire.
Le travail côté clients avait commencé avant la clôture. Nico Flaig a ouvert le 17 octobre la pull request n° 10428 de Lodestar pour trier les dépôts en attente selon les identifiants de retrait au moment du fork ; elle était encore ouverte lors de notre vérification. Tous les clients doivent calculer le même état au fork, si bien qu’un changement de ce type ne fonctionne que si tous l’adoptent via la spécification. Flaig a aussi ouvert, le 12 octobre, une pull request sur sa copie personnelle du code de Lido pour compenser les prédépôts absorbés par des builders. Ce n’est pas une décision de Lido.
Hoodi bifurque le 26 octobre, la date du mainnet reste ouverte
Le fork Glamsterdam sur le testnet Hoodi est fixé au 26 octobre à 17 h 42 min 48 s UTC, à l’epoch 132 352, d’après l’annonce de la Fondation Ethereum du 16 octobre. La limite de gas passe à 200 millions au fork. Les règles de Hoodi sont figées : à propos du correctif, Traglia écrivait le 16 octobre que « ce bateau a déjà quitté le port » pour ce testnet. L’intégration des builders au fork n’a pas été testée lors du fork de Sepolia le 6 octobre, selon Flaig, et Gusakov a indiqué que Lido veut du temps pour tester avec de vrais builders sur Hoodi.
Pour le mainnet, la Fondation écrit que la date d’activation « n’a pas encore été décidée ». Dans le fil d’ordre du jour de la réunion du 15 octobre, Barnabas Busa, de la Fondation Ethereum, a proposé deux créneaux, en supposant que Hoodi se passe bien : le 1er décembre 2026 à 20 h 38 min 47 s UTC, ou le 8 décembre à 16 h 29 min 11 s UTC. Gusakov a soutenu le plus tardif dans l’après-midi : « Nous avons encore beaucoup de tests à faire avec de vrais builders sur Hoodi. Donc le 8 décembre convient très bien à Lido. » On ignore si l’une des dates a été retenue ; toutes deux restent des propositions.
La prochaine réunion de la couche de consensus, ACDC n° 190, a lieu le 29 octobre à 14 h UTC, trois jours après Hoodi. Busa a aussi apporté à la réunion du 15 octobre une autre question de dépôt : selon l’EIP-8365, prévue pour la mise à jour ultérieure Hegotá, les nouveaux dépôts vers d’anciens identifiants 0x00 seraient ignorés et les ETH brûlés. C’est un problème différent du tri des builders.
Ce que cela change pour les détenteurs de stETH, de rETH et les services de staking
Pour les personnes qui détiennent des jetons de staking liquide ou utilisent un service de staking, rien ne s’est produit. Aucun fonds n’a bougé, et le risque décrit tient à la manière dont quelques protocoles financent de nouveaux validateurs pendant une fenêtre précise autour du fork. Les protocoles concernés ont jusqu’à la date du mainnet pour ajouter des contrôles ou ajuster leurs contrats, et l’issue leur donne la méthode.
Pour un lecteur français, aucun volet réglementaire n’est signalé à ce stade : ni l’AMF ni l’ACPR ne se sont exprimées, et aucune action au titre du règlement MiCA n’a été rapportée. Les services de staking proposés par des prestataires agréés reposent toutefois sur ce type de circuits techniques.
Lido, Origin et Rocket Pool n’avaient pas dit publiquement s’ils étaient concernés lors de notre vérification. Les prochains repères sont le fork de Hoodi le 26 octobre et la réunion du 29 octobre, où une date de mainnet pourrait être choisie.