Un ingénieur de Lido alerte sur le risque de détournement de dépôts de staking pendant la transition Glamsterdam d'Ethereum

2026/10/21 14:09:00

Pourquoi les développeurs d'Ethereum ont rejeté la correction au niveau du protocole

La prochaine mise à jour majeure du réseau Ethereum vise à mettre à l’échelle la couche de base grâce à une séparation institutionnalisée entre proposeur et constructeur, ainsi qu’à des limites de gaz plus élevées, mais une vulnérabilité spécifique au moment du déploiement a attiré une nouvelle attention de la part d’un des plus grands fournisseurs de staking liquide. Le 20 octobre 2026, Dima Gusakov, responsable de l’ingénierie chez Lido Finance, a publiquement détaillé comment la transition vers Glamsterdam pourrait permettre à un opérateur de nœud malveillant de devancer le dépôt du validateur d’un staker. L’attaque utiliserait des dépôts de constructeurs portant des identifiants de retrait préfixés par 0xB0 qui partagent temporairement la file d’attente des dépôts, ce qui pourrait créditer les ETH sur un compte de constructeur au lieu d’activer le validateur prévu. La fenêtre d’exploitation est limitée à la transition elle-même du hard-fork. Après la mise à jour, les dépôts de constructeurs seront acheminés vers un chemin de contrat distinct.

Une correction proposée au niveau du protocole dans les spécifications de consensus a été fermée comme « non prévue », transférant la charge défensive sur les protocoles de staking. Cet article examine les mécanismes techniques du risque, les choix de conception de la mise à jour qui ont créé le chevauchement temporaire, les raisons pour lesquelles les développeurs principaux ont refusé un correctif de protocole, les étapes pratiques que les fournisseurs de staking liquide doivent entreprendre, le calendrier de testnet qui ne laisse aux opérateurs que quelques jours pour se préparer, et les leçons plus larges pour la sécurité du staking délégué alors qu’Ethereum avance sur sa feuille de route d’extension. L’analyse s’appuie exclusivement sur des rapports et des déclarations primaires des 30 derniers jours, en se concentrant sur des détails vérifiés plutôt que sur des spéculations.

Le chef du département ingénierie de Lido détaille le vecteur de front-running sur X et lors des appels développeurs

Dima Gusakov a émis l'avertissement le 20 octobre 2026, s'adressant directement aux protocoles de staking et aux stakers délégués. Il a expliqué qu'un opérateur de nœud pouvait soumettre un dépôt de constructeur en utilisant la même clé publique avant que la transaction de dépôt du validateur légitime ne soit validée. Puisque Glamsterdam introduit des dépôts de constructeur qui reposent sur des crédits de retrait préfixés par 0xB0, et que ces dépôts partagent la file d'attente des dépôts de validateur pendant la transition, le premier dépôt valide peut revendiquer les fonds. Le résultat est que le validateur du staker n'apparaît jamais sur la chaîne de balise, tandis que les ETH sont crédités sur le compte constructeur de l'attaquant. Gusakov a souligné que l'attaque n'est possible qu'au moment du fork. Avant Glamsterdam, les dépôts de constructeur passent par la file d'attente existante des dépôts de validateur ; après, ils sont acheminés via un contrat dédié. La durée limitée, a-t-il noté, rend la mitigation possible pour les protocoles préparés.

La même préoccupation a été soulevée lors de l'appel de consensus All Core Devs (ACDC #189). Gusakov a souligné que le mécanisme d'intégration unique de Glamsterdam peut interférer avec les modèles de protection des dépôts sur lesquels les protocoles de staking s'appuient depuis longtemps. Selon les règles actuelles, le premier dépôt valide pour une clé publique fixe définitivement les informations de retrait. Les protocoles déposent souvent un petit montant en premier, confirment que les informations attendues apparaissent, puis complètent uniquement le solde restant. Pendant la transition de fork, le chemin d'intégration spécial peut produire un troisième résultat : aucun validateur ne s'active, et le dépôt complet est attribué à un constructeur. Les développeurs principaux ont rejeté un changement tardif de spécification qui aurait préservé la distinction entre les dépôts de validateur et de constructeur pendant l'intégration unique, en citant le fait que Sepolia avait déjà été activée selon les règles existantes et que les versions du client Hoodi étaient déjà en préparation. Modifier le comportement à ce stade aurait exigé un nouveau déploiement de Sepolia et des cycles de test supplémentaires.

Comment les identifiants du constructeur 0xB0 interagissent avec la file d'attente de dépôt partagée

Glamsterdam introduit des dépôts de constructeurs dans le cadre de la transition vers une séparation constructeur-proposer inscrite dans le protocole. Ces dépôts comportent des informations de retrait commençant par le préfixe 0xB0, les distinguant des credentials habituels des validateurs. Pendant la période de transition, les deux types de dépôts partagent le même chemin de traitement dans la file d'attente. Un opérateur de nœud qui contrôle ou peut influencer l'ordre de soumission des dépôts peut donc insérer un dépôt avec credentials de constructeur correspondant à une clé publique de staker en attente. Une fois le premier dépôt accepté, le réseau considère la clé publique comme revendiquée sous les credentials du constructeur. Les dépôts ultérieurs sous la même clé sont soit ignorés pour l'activation du validateur, soit redirigés selon les nouvelles règles d'interprétation applicables autour de la limite du fork.

L'effet pratique est que le staker perd à la fois le validateur attendu et les ETH déposés, qui sont désormais sous le contrôle du constructeur. Les validateurs activés existants et les dépôts déjà traités restent inchangés. Le risque est limité aux nouveaux dépôts ou à ceux encore en file d'attente qui traversent l'époque d'activation. Étant donné que le comportement de la file partagée prend fin une fois le fork terminé et que les dépôts du constructeur sont transférés vers leur contrat dédié, l'exposition est temporaire. Ce caractère temporaire est la raison principale pour laquelle Gusakov a conseillé de ne pas paniquer, tout en exhortant chaque service de staking délégué à mettre en œuvre ou à renforcer la vérification préalable au dépôt avant l'activation du mainnet.

Les développeurs principaux ferment la proposition de spécifications de consensus comme non prévue

La discussion technique d'une solution au niveau du protocole est apparue dans le problème #5735 de consensus-specs. La proposition prévoyait des vérifications préalables au dépôt qui vérifient certaines conditions avant d'accepter un dépôt dans la file d'attente. Après examen, le problème a été fermé avec le statut « non planifié ». Cette décision laisse la responsabilité défensive au niveau de l'application plutôt que d'intégrer des vérifications supplémentaires dans le protocole de base. Les conseils publics de Gusakov se concentrent donc sur la validation préalable au dépôt effectuée par les protocoles de staking. Les contraintes temporelles ont fortement influencé le résultat. Sepolia avait déjà effectué un fork selon la spécification existante le 6 octobre 2026.

Les versions du client Hoodi avançaient vers l'activation du 26 octobre. Introduire un changement comportemental tardif risquait d'obliger à un nouveau déploiement sur Sepolia et à de nouveaux retards dans les tests. Les développeurs principaux ont jugé que la fenêtre limitée et la capacité des équipes de la couche application à ajouter des vérifications rendaient un correctif de protocole inutile à ce stade. Le résultat est un modèle de sécurité distribué dans lequel chaque fournisseur de liquid staking doit confirmer que son pipeline de dépôt distingue correctement ou bloque les dépôts préfixés 0xB0 qui tentent de revendiquer des clés publiques de validateur.

Les vérifications préalables au dépôt deviennent la première ligne de défense pour les services de staking liquide

Lido dispose d’un module de sécurité des dépôts et d’un comité de gardiens depuis que des vulnérabilités liées aux dépôts ont été révélées il y a plusieurs années. Les gardiens examinent les captures d’écran de la racine des dépôts avant que les lots ne soient traités, et un seul gardien honnête peut suspendre les dépôts. La question ouverte est de savoir si cette infrastructure existante prend déjà en charge le nouveau type d’identifiant 0xB0 et les dynamiques de file d’attente partagée temporaire, ou si une logique supplémentaire est nécessaire pour la transition Glamsterdam. D’autres protocoles qui ne disposent pas d’une supervision multipartite comparable doivent accomplir une tâche de préparation plus complexe.

Les vérifications préalables au dépôt peuvent prendre plusieurs formes concrètes. Un protocole peut refuser tout dépôt dont les informations de retrait commencent par 0xB0 lorsque l'intention est une activation standard de validateur. Il peut exiger une attestation en ligne ou hors ligne indiquant que la clé publique n'a pas déjà été revendiquée sous des identifiants de constructeur. Il peut suspendre les nouveaux dépôts pendant une courte fenêtre entourant l'époque d'activation jusqu'à la fin de la période de file d'attente partagée. Étant donné que la surface d'attaque n'existe que pendant le chevauchement des files d'attente, une suspension temporaire ou une surveillance accrue pendant cette période peut éliminer la plupart des expositions pratiques. Les services de staking plus petits ou plus récents qui n'ont pas encore mis en place des comités de type gardien devront agir rapidement s'ils souhaitent accepter des dépôts pendant la transition sur le mainnet.

Calendrier d'activation de Glamsterdam laisse peu de marge pour la préparation

La Fondation Ethereum a confirmé que Glamsterdam sera activé sur la testnet Hoodi à l'époque 132 352, slot 4 235 264, correspondant au 26 octobre 2026 à 17:42:48 UTC. À la même époque, la limite de gaz de Hoodi passe à 200 millions. Sepolia a déjà été activée le 6 octobre. La date d'activation sur le mainnet reste indécise, avec des dates candidates au début décembre en discussion, conditionnelles à un fork propre de Hoodi. Les opérateurs de nœuds et les équipes de staking ont donc seulement quelques jours après l'avertissement de Gusakov pour valider leurs pipelines de dépôt sur Hoodi.

Les équipes client ont publié des versions compatibles pour les couches de consensus et d'exécution. Les opérateurs doivent mettre à jour à la fois les nœuds de balise et le client de validateur, examiner toute modification apportée aux interfaces de constructeur introduites par la séparation proposer-builder inscrite dans le protocole, et confirmer que la logique de soumission des dépôts gère correctement le nouveau préfixe d'identifiant. La courte fenêtre entre l'avertissement public et la première activation publique sur testnet souligne la nécessité d'avoir des défenses au niveau de l'application prêtes avant l'ouverture de la fenêtre de transition sur mainnet.

Séparation institutionnalisée du proposer et du builder introduit le nouveau chemin de dépôt

Glamsterdam combine les modifications de la couche d'exécution d'Amsterdam avec les modifications de la couche de consensus de Gloas. Ses deux fonctionnalités principales sont la séparation enracinée du proposer et du builder (EIP-7732) et les listes d'accès au niveau du bloc. Sous ePBS, les builders s'enregistrent sur la chaîne avec leurs propres soldes et clés publiques, soumettent des enchères, puis révèlent plus tard les charges utiles d'exécution. Le protocole gère lui-même le paiement au proposer, réduisant ainsi la dépendance aux relais externes. Les dépôts et les retraits des builders deviennent des demandes d'exécution de première classe, ce qui explique la cheville d'overlap entre le préfixe d'identifiant 0xB0 et la file d'attente temporaire.

La conception améliore l'évolutivité en donnant aux validateurs plus de temps pour traiter des charges utiles plus importantes et en permettant des limites de gaz plus élevées. En même temps, elle crée un nouveau parcours d'intégration pour les constructeurs qui doit être soigneusement distingué des dépôts de validateurs ordinaires. Les mécanismes de transition ponctuelle sont à l'origine de l'ambiguïté temporaire. Une fois que le réseau a complètement basculé, les dépôts de constructeurs transitent par leur propre contrat, et le risque lié à la file d'attente partagée disparaît. La mise à niveau améliore donc l'architecture à long terme tout en exigeant une vigilance à court terme de la part de tout service qui soumet des dépôts au nom des utilisateurs.

L'expérience antérieure de Lido en matière de sécurité des dépôts informe la réponse actuelle

Lido a rencontré des risques de front-running sur les dépôts au cours des dernières années et a réagi en formalisant le Module de Sécurité des Dépôts accompagné d'un comité de gardiens. Le comité approuve les captures d'écran des racines de dépôt ; un seul gardien peut déclencher une pause. Cette infrastructure s'est déjà révélée utile lors d'autres incidents opérationnels. L'affaire Glamsterdam teste si les mêmes contrôles reconnaissent correctement le nouveau type de credential et la courte période de partage de file d'attente.

Les protocoles qui ont adopté des modèles de signature multiple ou de gardien similaires après des incidents antérieurs sont mieux positionnés que ceux qui n'ont pas encore mis en œuvre des mesures de sécurité comparables. Le schéma plus large est familier : les mises à jour de protocole peuvent révéler des cas limites que les systèmes de couche application doivent absorber. Étant donné que les développeurs principaux ont refusé un changement de spécification en retard, l'industrie doit considérer la validation pré-dépôt comme une exigence permanente plutôt qu'une amélioration facultative. Les équipes qui surveillent déjà les racines de dépôt et peuvent interrompre rapidement auront un risque opérationnel plus faible pendant la transition.

Les opérateurs de nœuds et les stakeurs délégués sont exposés à une concentration de risque pendant la fenêtre

L'attaque nécessite un opérateur de nœud malveillant ou compromis capable de soumettre une transaction de dépôt qui passe avant la légitime. Les simples stakers qui se contentent de déposer dans un protocole de staking liquide ne peuvent pas eux-mêmes exécuter le front-run ; le risque repose sur l'opérateur qui signe ou soumet finalement le dépôt sur chaîne. Les validateurs activés existants et les dépôts déjà confirmés restent en dehors de la surface d'attaque. Seules les clés publiques ayant encore des dépôts en attente ou nouvellement soumis pendant l'époque de transition sont exposées.

Les stakers délégués doivent donc confirmer que le protocole choisi a publié des consignes sur la gestion des dépôts autour de l'activation de Glamsterdam. Les opérateurs eux-mêmes doivent auditer soigneusement l'ordre de soumission, les limites de débit ou la séquence des dépôts, et vérifier qu'aucun dépôt préfixé 0xB0 ne peut revendiquer une clé destinée à un validateur standard. Étant donné que la fenêtre est courte, une réduction temporaire du débit des nouveaux dépôts ou une surveillance renforcée peut fermer la plupart des voies d'attaque pratiques sans perturber durablement les opérations de staking.

Hoodi propose le premier environnement en direct pour le test du pipeline de dépôt

L'activation de Hoodi du 26 octobre offre la première opportunité publique pour les équipes de staking d'observer le comportement de la file partagée dans des conditions réalistes. Les protocoles peuvent soumettre des dépôts de test avec des identifiants ordinaires et 0xB0, mesurer les résultats d'ordre et confirmer que leurs filtres pré-dépôt rejettent ou mettent en quarantaine le chemin indésirable. Les équipes client ont déjà déployé des versions compatibles avec Hoodi ; les opérateurs doivent s'assurer que les clients d'exécution et de consensus sont à jour et que tous les outils externes de construction ont été revus pour les nouvelles interfaces.

Un test réussi sur Hoodi donnera à l'industrie une confiance accrue avant l'ouverture de la fenêtre mainnet. Les échecs ou les cas limites inattendus découverts sur la testnet peuvent encore être résolus par des modifications au niveau de l'application ou de courtes pauses, sans nécessiter une refonte du protocole. Le calendrier réduit entre l'avertissement public et l'activation de Hoodi rend les tests coordonnés essentiels.

La responsabilité de la mitigation repose désormais sur chaque protocole de staking

En fermant le problème des spécifications de consensus comme non planifié, les développeurs principaux ont indiqué que le risque temporaire est mieux géré au niveau de la couche application. Les fournisseurs de liquid staking, les plateformes d'opérateurs individuels et tout service qui soumet des dépôts pour le compte des utilisateurs doivent donc mettre en œuvre leurs propres vérifications. Les fournisseurs qui maintiennent déjà des comités de gardiens ou des processus d'attestation de racine de dépôt peuvent étendre ces processus pour couvrir le préfixe 0xB0. Les fournisseurs sans telle infrastructure ont un délai plus court pour ajouter des contrôles équivalents.

Le modèle distribué présente à la fois des avantages et des inconvénients. Il permet des réponses rapides et adaptées sans attendre un changement de fork généralisé du réseau. Il signifie également que la sécurité du dépôt de chaque staker dépend des pratiques spécifiques du protocole qu'il a choisi. Une transparence concernant les procédures de gestion des dépôts autour de l'époque d'activation aidera les utilisateurs à évaluer le risque résiduel.

Les objectifs d'évolution et les cas limites temporaires restent liés dans les mises à jour d'ethereum

Glamsterdam fait progresser la feuille de route d'évolution de la couche 1 d'Ethereum en augmentant la limite de gaz pratique vers 200 millions, en permettant le traitement parallèle des transactions grâce à des listes d'accès au niveau des blocs, et en éliminant les relais externes du chemin critique de la production de blocs. Ces améliorations exigent de nouvelles primitives sur chaîne pour les constructeurs, ce qui crée à son tour un chevauchement temporaire de la file d'attente de dépôt. Ce schéma est caractéristique des mises à jour majeures : les améliorations architecturales à long terme peuvent révéler des cas limites de courte durée que les équipes d'applications doivent gérer.

La capacité de l'industrie à absorber ces cas limites sans perte de fonds utilisateurs influencera la confiance dans les mises à jour suivantes. La validation préalable aux dépôts, les pauses temporaires de dépôt et une communication claire de l'opérateur sont les outils pratiques disponibles dans le cas présent. Étant donné que le risque est limité à une période connue et courte, le coût de la préparation est fini, et le bénéfice est la préservation des dépôts utilisateurs pendant la transition.

Les dépôts en attente nécessitent une surveillance accrue jusqu'à la fin de la transition

Toute clé publique qui possède encore un dépôt non traité au moment où les règles Glamsterdam entrent en vigueur se trouve dans la fenêtre d'attaque potentielle. Les protocoles peuvent atténuer cela en vidant ou en accélérant leurs files d'attente de dépôts avant l'époque, en rejetant les identifiants 0xB0 pour les intentions de validateur, ou en suspendant brièvement les nouvelles soumissions autour de l'activation. Une surveillance continue des changements de racine de dépôt et de l'état des revendications de clés publiques pendant les heures critiques permettra une réponse rapide en cas d'activité anormale.

Une fois le fork terminé et que les dépôts de constructeurs sont redirigés vers leur chemin de contrat séparé, le vecteur de file partagée se ferme. La charge de surveillance a donc une date de fin claire. Les équipes qui traitent la transition comme une période opérationnelle nécessitant une attention particulière, plutôt que comme une mise à jour routinière, seront mieux placées pour protéger les fonds des stakers.

🔥 Au-delà des titres : ce que KuCoin 5.0 signifie pour vous

Les nouvelles du marché évoluent rapidement — mais où vous agissez dessus compte tout autant. Ce octobre, KuCoin lance KuCoin 5.0, transformant KuCoin en une plateforme entièrement重构. Voici ce qui change réellement pour vous :

Un seul compte pour tout. Les anciennes plateformes répartissaient votre argent entre des comptes séparés « spot », « marge » et « futures » et s’attendaient à ce que vous compreniez pourquoi. Le compte unifié de KuCoin 5.0 élimine entièrement cela — déposez une seule fois, et tout est simplement disponible (actuellement uniquement disponible pour les VIP).
Actions, indices et matières premières. KuCoin 5.0 s'étend au-delà du crypto vers les marchés mondiaux. Lorsque le crypto stagne et que les actions progressent (ou l'inverse), vous effectuez une rotation en quelques minutes au lieu d'ouvrir un compte de courtage et d'attendre des jours pour les voies monétaires.
Actifs du monde réel (RWA). Une exposition tokenisée à des actifs traditionnels comme les matières premières, directement dans votre compte crypto. L’un des segments à la croissance la plus rapide de la finance mondiale n’est plus réservé aux institutions — vous y accédez depuis le même solde que celui que vous utilisez pour trader.
Gagnez tout en apprenant. Pas prêt à trader ? KCUSD permet à vos stablecoins de générer des intérêts quotidiens, avec un auto-compound. La méthode la moins stressante pour faire travailler vos dépôts inactifs avec un rendement de 4 %.
Un assistant IA en langage simple. Posez des questions, obtenez du contexte sur le marché, comprenez ce que vous voyez — intégré à la plateforme, aucun jargon requis.
Une application qui ne submerge pas. Plus rapide, plus propre et cohérente — intuitive dès le premier toucher, sans besoin de tutoriel.
Sécurité que vous pouvez vérifier, et non seulement confier. Une entité européenne sous licence MiCAR, Proof of Reserves que vous pouvez vérifier vous-même, et une sécurité certifiée au niveau international (SOC 2 Type II, ISO 27001:2022).

Créez votre compte en quelques minutes — et commencez sur la plateforme conçue pour où va la crypto, pas où elle en est venue.

FAQ

Qu'est-ce que la mise à niveau Glamsterdam et pourquoi est-elle importante pour le staking ?

Glamsterdam est le nom combiné des modifications de la couche d'exécution d'Amsterdam et de la couche de consensus Gloas. Ses objectifs principaux sont la séparation enracinée du proposer et du builder, ainsi que les listes d'accès au niveau du bloc qui permettent des limites de gaz plus élevées et un traitement des blocs plus efficace. Pour le staking, l'introduction de l'enregistrement des builders sur la chaîne et le chemin de dépôt associé crée le comportement temporaire de partage de file d'attente qui sous-tend le risque de front-running.

Combien de temps dure la fenêtre de détournement de dépôt ?

La fenêtre existe uniquement tant que les dépôts de builder traversent encore la file d'attente des dépôts de validateur. Cette condition est valable pendant la transition elle-même du hard-fork. Une fois la mise à niveau terminée, les dépôts de builder sont traités via un contrat distinct, fermant ainsi le chemin de la file d'attente partagée. La durée pratique est donc mesurée en heures autour de l'époque d'activation, et non en jours ou semaines.

Le risque affecte-t-il les validateurs déjà activés ou les ETH déjà mis en staking ?

Non. L'attaque cible les dépôts nouveaux ou encore en file d'attente pour les clés publiques qui n'ont pas encore produit un validateur actif. Les validateurs existants et leurs soldes restent sous leurs credentials de retrait établis et sont en dehors de la surface d'attaque décrite.

Que peuvent faire les simples stakers pour se protéger ?

Les stakers qui déposent via un protocole de staking liquide doivent vérifier que le protocole a publié des instructions spécifiques sur la gestion des dépôts autour de l'activation de Glamsterdam. Choisir un fournisseur qui utilise déjà une sécurité de dépôt multipartite ou une supervision de type guardian réduit le risque résiduel. Les stakers qui exécutent leurs propres validateurs doivent s'assurer que leur logique de soumission de dépôt n'autorise pas un dépôt concurrent 0xB0 à revendiquer la même clé publique.

Pourquoi les développeurs principaux ont-ils refusé une correction au niveau du protocole ?

La proposition de vérifications préalables au dépôt a été close car non prévue, principalement en raison de la pression sur le calendrier. Sepolia avait déjà été activée selon les règles existantes, et les versions du client Hoodi progressaient. Un changement comportemental tardif aurait risqué de provoquer de nouveaux déploiements et retards sur la testnet. Les développeurs ont jugé que les mesures d'atténuation au niveau application étaient suffisantes compte tenu de la durée limitée de l'exposition.

Avertissement : Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil en investissement. Les investissements dans les cryptomonnaies comportent des risques. Veuillez effectuer vos propres recherches (DYOR).

Avertissement : Pour votre confort, cette page a été traduite à l'aide de la technologie IA. Pour obtenir les informations à la source, consultez la version anglaise originale.