#dusk $DUSK @Dusk
J’ai consulté l’avis d’incident de Dusk en m’attendant au langage habituellement vague « nous enquêtons ». À la place, j’ai trouvé une distinction qui mérite qu’on s’y attarde.
Lorsque Dusk a détecté une activité anormale du pont liée à une équipe gérant une wallet opérationnelle, elle a mis en pause les services du pont, recyclé les adresses concernées et déployé une liste de blocage de Web Wallet qui avertit les utilisateurs avant qu’ils n’envoient des fonds vers des destinations connues comme malveillantes ou sanctionnées.
C’est la partie intéressante.
Une liste de blocage est un garde-fou d’interface. Elle protège les utilisateurs avant qu’une transaction ne soit signée. Ce n’est pas quelque chose que DuskDS applique au niveau du protocole.
L’équipe a aussi été on ne peut plus claire : l’incident ne relevait pas d’une défaillance au niveau du protocole. Le consensus continuait de fonctionner normalement ; la compromission existait entièrement dans l’infrastructure opérationnelle entourant le pont.
Un détail a particulièrement retenu mon attention : les services du pont sont restés en pause jusqu’à ce qu’ils puissent être réintroduits avec DuskEVM. Ainsi, la reprise et le renforcement de l’infrastructure ont été regroupés en un seul déploiement plutôt que de rouvrir d’abord puis de corriger plus tard.
Si le protocole n’a jamais échoué, mais que la protection avec laquelle les utilisateurs interagissent réellement est un système d’avertissement au niveau de la wallet, que cela dit-il sur l’endroit où la sécurité est vraiment ressentie : dans le protocole, ou à l’interface entre les utilisateurs et le protocole ?
J’ai consulté l’avis d’incident de Dusk en m’attendant au langage habituellement vague « nous enquêtons ». À la place, j’ai trouvé une distinction qui mérite qu’on s’y attarde.
Lorsque Dusk a détecté une activité anormale du pont liée à une équipe gérant une wallet opérationnelle, elle a mis en pause les services du pont, recyclé les adresses concernées et déployé une liste de blocage de Web Wallet qui avertit les utilisateurs avant qu’ils n’envoient des fonds vers des destinations connues comme malveillantes ou sanctionnées.
C’est la partie intéressante.
Une liste de blocage est un garde-fou d’interface. Elle protège les utilisateurs avant qu’une transaction ne soit signée. Ce n’est pas quelque chose que DuskDS applique au niveau du protocole.
L’équipe a aussi été on ne peut plus claire : l’incident ne relevait pas d’une défaillance au niveau du protocole. Le consensus continuait de fonctionner normalement ; la compromission existait entièrement dans l’infrastructure opérationnelle entourant le pont.
Un détail a particulièrement retenu mon attention : les services du pont sont restés en pause jusqu’à ce qu’ils puissent être réintroduits avec DuskEVM. Ainsi, la reprise et le renforcement de l’infrastructure ont été regroupés en un seul déploiement plutôt que de rouvrir d’abord puis de corriger plus tard.
Si le protocole n’a jamais échoué, mais que la protection avec laquelle les utilisateurs interagissent réellement est un système d’avertissement au niveau de la wallet, que cela dit-il sur l’endroit où la sécurité est vraiment ressentie : dans le protocole, ou à l’interface entre les utilisateurs et le protocole ?
