Ethereum : le correctif de Glamsterdam sur les dépôts de staking finalement fusionné

Encyclopédie du Coin Améliorez vos connaissances sur les cryptos

Le vent a tourné avec le calendrier. Le report de Glamsterdam sur le testnet Hoodi a offert aux équipes le temps qui leur manquait pour corriger une règle de dépôt. Elle aurait permis à un opérateur de récupérer l’ETH destiné aux validateurs de protocoles comme Lido ou Rocket Pool.

Tous les bonus Gate EU du moment réunis au même endroit, cumulables avec le Rewards Hub (10 000+ USDC) Profiter des bonus Gate EU Lien commercial

Tout part de l’ ePBS (EIP-7732), la séparation entre proposeur et constructeur de blocs que Glamsterdam inscrit dans le protocole. Les builders, ces acteurs spécialisés qui assemblent les blocs, y disposent de leur propre compte. On l’alimente par un dépôt d’ETH, exactement comme on lance un validateur.

Le problème surgit au moment de la bascule. Les dépôts encore en file d’attente quand le fork s’active doivent être répartis entre validateurs et builders. Or le brouillon des spécifications prévoyait une règle très simple. Dès qu’un dépôt avait enregistré un builder pour une clé publique, tous les dépôts suivants sur cette clé partaient chez lui.

Le 12 octobre , George Avsetsin, architecte protocole en chef de Lido, a décrit le scénario dans un ticket GitHub. 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 même clé.

Si les deux dépôts sont encore en attente au moment du fork, les deux montants atterrissent chez le builder. « L’opérateur peut retirer les fonds du protocole », résume Avsetsin.

Et le piège se referme. Aucun validateur n’étant créé, le protocole lésé ne peut pas produire la preuve qui lui permettrait de récupérer sa mise.

Avsetsin a passé au crible les contrats de Lido, Rocket Pool et Origin grâce à ce qu’il appelle une « recherche rapide par IA ». Il prend soin de parler de « résultats conditionnels » et non d’exploits confirmés. Des contrôles déjà en place, qui rejettent un dépôt de builder antérieur, pourraient même bloquer l’attaque.

La parade tient en une phrase. Avec la pull request #5736 , chaque dépôt en attente est trié selon ses identifiants de retrait (withdrawal credentials). Un dépôt destiné à un validateur reste au validateur, même si un builder utilise la même clé.

Mais toucher à la logique des dépôts à quelques semaines d’un fork donne des sueurs froides. Après deux appels de développeurs, Justin Traglia , qui tient les spécifications de consensus, a refermé le dossier le 19 octobre. « Il n’y avait pas assez de soutien de la part des clients pour faire ce changement maintenant », a-t-il écrit.