L’incident du pont de Dusk de la semaine dernière est en fait une fenêtre décente sur la manière dont DuskDS, DuskVM et DuskEVM sont séparés en pratique, et pas seulement sur le papier.
Le 16 août, l’équipe Dusk a signalé une activité suspecte sur un portefeuille géré par l’équipe utilisé pour les opérations de pont, a désactivé les adresses concernées et a mis en pause les services de pont tout en coordonnant avec Binance après qu’une partie du flux a touché la bourse. Ce qui m’a poussé à creuser : l’avis d’incident de l’équipe indiquait explicitement qu’il s’agissait d’un problème de clé de portefeuille, et non d’une défaillance du protocole DuskDS. C’est une distinction importante d’un point de vue architectural : le pont se situe comme une couche opérationnelle au-dessus du règlement de DuskDS, distincte de la logique de consensus et d’exécution que DuskVM et DuskEVM exécutent réellement.
En examinant la chronologie, la mise en pause semble réactive plutôt qu’automatisée : une alerte de surveillance a déclenché une action de confinement manuel, pas un coupe-circuit intégré au protocole. Cela vaut la peine d’être noté pour quiconque suppose que la sécurité du pont est imposée au niveau de base ici.
Ce que je ne peux pas confirmer : le nombre exact ou la valeur des transactions pendant la fenêtre d’incident, ou si les adresses recyclées étaient contrôlées par un multisig. L’annonce de Dusk indique qu’aucun fonds utilisateur n’a été affecté, mais je n’ai pas vu de confirmation on-chain indépendante de cette affirmation.
Quelqu’un suit-il si les opérations de pont de Dusk sont conçues avec un multisig, ou si c’est une configuration à clé unique ?
@Dusk_Foundation $DUSK #dusk
Le 16 août, l’équipe Dusk a signalé une activité suspecte sur un portefeuille géré par l’équipe utilisé pour les opérations de pont, a désactivé les adresses concernées et a mis en pause les services de pont tout en coordonnant avec Binance après qu’une partie du flux a touché la bourse. Ce qui m’a poussé à creuser : l’avis d’incident de l’équipe indiquait explicitement qu’il s’agissait d’un problème de clé de portefeuille, et non d’une défaillance du protocole DuskDS. C’est une distinction importante d’un point de vue architectural : le pont se situe comme une couche opérationnelle au-dessus du règlement de DuskDS, distincte de la logique de consensus et d’exécution que DuskVM et DuskEVM exécutent réellement.
En examinant la chronologie, la mise en pause semble réactive plutôt qu’automatisée : une alerte de surveillance a déclenché une action de confinement manuel, pas un coupe-circuit intégré au protocole. Cela vaut la peine d’être noté pour quiconque suppose que la sécurité du pont est imposée au niveau de base ici.
Ce que je ne peux pas confirmer : le nombre exact ou la valeur des transactions pendant la fenêtre d’incident, ou si les adresses recyclées étaient contrôlées par un multisig. L’annonce de Dusk indique qu’aucun fonds utilisateur n’a été affecté, mais je n’ai pas vu de confirmation on-chain indépendante de cette affirmation.
Quelqu’un suit-il si les opérations de pont de Dusk sont conçues avec un multisig, ou si c’est une configuration à clé unique ?
@Dusk_Foundation $DUSK #dusk