Depuis quelques jours, je me surprends à revenir sans cesse à @Dusk encore et encore. Non pas à cause des choses qui attirent facilement l’attention, mais parce qu’il y a une partie plus discrète du projet qui continue de me faire réfléchir.
Un point que j’apprécie dans l’incident du 16 août, c’est la rapidité avec laquelle l’équipe a réagi. Ils ont agi vite pour stopper le flux de fonds, remplacer les adresses concernées et ajouter ces adresses à la liste de blocage du portefeuille web—une approche assez classique pour gérer les conséquences d’un incident.
En regardant les nouvelles adresses après l’incident, j’ai trouvé quelque chose de vraiment intéressant. Au lieu de voir de petites transactions utilisées pour sonder le système, presque tout était resté totalement immobile. Pas de poussière, pas de tests, aucun signe que quelqu’un vérifiait comment le système réagirait. Pendant plus d’une semaine, ces adresses sont restées silencieuses tandis que le pont restait hors ligne.
Ce qui ressort le plus pour moi après l’exploitation, ce n’est pas nécessairement que la vulnérabilité se soit produite, mais ce que #dusk a choisi de faire ensuite. Ils auraient pu remettre le pont en ligne rapidement pour répondre à la demande des utilisateurs, mais à la place, ils ont tout laissé en pause. Les nouvelles adresses n’ont pas été touchées. Personne ne les obligeait à attendre, et pourtant ils ont choisi l’option la moins pratique en échange d’une autre couche de sécurité.
Honnêtement, je ne veux toujours pas qualifier cela soit de bonne gestion des risques, soit d’un simple processus de rétablissement lent. Peut-être que la réponse se situe quelque part entre les deux. Ce qui semble le plus certain, c’est qu’après l’incident, il y a eu presque aucune activité supplémentaire on-chain—et ce silence en lui-même vaut la peine d’être observé.
Je me demande si quelqu’un d’autre suit ces données : après un incident, combien de temps chaque pont reste généralement « silencieux » avant de revenir réellement en ligne ? Peut-être que cette période de silence est l’une des façons les plus claires de voir comment une équipe aborde concrètement la gestion des risques.$DUSK $BMT $FOREST
Un point que j’apprécie dans l’incident du 16 août, c’est la rapidité avec laquelle l’équipe a réagi. Ils ont agi vite pour stopper le flux de fonds, remplacer les adresses concernées et ajouter ces adresses à la liste de blocage du portefeuille web—une approche assez classique pour gérer les conséquences d’un incident.
En regardant les nouvelles adresses après l’incident, j’ai trouvé quelque chose de vraiment intéressant. Au lieu de voir de petites transactions utilisées pour sonder le système, presque tout était resté totalement immobile. Pas de poussière, pas de tests, aucun signe que quelqu’un vérifiait comment le système réagirait. Pendant plus d’une semaine, ces adresses sont restées silencieuses tandis que le pont restait hors ligne.
Ce qui ressort le plus pour moi après l’exploitation, ce n’est pas nécessairement que la vulnérabilité se soit produite, mais ce que #dusk a choisi de faire ensuite. Ils auraient pu remettre le pont en ligne rapidement pour répondre à la demande des utilisateurs, mais à la place, ils ont tout laissé en pause. Les nouvelles adresses n’ont pas été touchées. Personne ne les obligeait à attendre, et pourtant ils ont choisi l’option la moins pratique en échange d’une autre couche de sécurité.
Honnêtement, je ne veux toujours pas qualifier cela soit de bonne gestion des risques, soit d’un simple processus de rétablissement lent. Peut-être que la réponse se situe quelque part entre les deux. Ce qui semble le plus certain, c’est qu’après l’incident, il y a eu presque aucune activité supplémentaire on-chain—et ce silence en lui-même vaut la peine d’être observé.
Je me demande si quelqu’un d’autre suit ces données : après un incident, combien de temps chaque pont reste généralement « silencieux » avant de revenir réellement en ligne ? Peut-être que cette période de silence est l’une des façons les plus claires de voir comment une équipe aborde concrètement la gestion des risques.$DUSK $BMT $FOREST
Infrastructure 🔧
0%
Privacy 🔐
100%
Scaling ⚡
0%
1 Votes • Vote fermé