В последние несколько дней я снова и снова возвращаюсь к @Dusk . Дело не в том, что легко цепляет внимание, а в том, что в проекте есть более тихая часть, которая продолжает заставлять меня задумываться.

Один момент, который я особенно ценю в инциденте от 16 августа, — это то, как быстро команда среагировала. Они действовали оперативно, чтобы остановить поток средств, заменить затронутые адреса и добавить адреса в блоклист веб-кошелька — довольно знакомый подход к работе с последствиями инцидента.

После инцидента, когда я посмотрел на новые адреса, обнаружилось кое-что довольно интересное. Вместо того чтобы видеть небольшие транзакции, используемые для проверки системы, почти всё оставалось полностью неподвижным. Никакой пыли, никакого тестирования, никаких признаков того, что кто-то проверяет, как система отреагирует. Более недели эти адреса хранили молчание, пока мост оставался офлайн.

Больше всего после эксплуатации меня впечатляет не столько сам факт уязвимости, сколько то, что #dusk выбрало сделать затем. Они могли бы быстро вернуть мост, чтобы удовлетворить спрос пользователей, но вместо этого держали всё на паузе. Новые адреса остались нетронутыми. Никто не заставлял их ждать, однако они всё равно выбрали менее удобный вариант ради ещё одного уровня безопасности.

Честно говоря, я до сих пор не хочу называть это ни хорошим управлением рисками, ни просто медленным процессом восстановления. Возможно, ответ находится где-то посередине. Что кажется более очевидным: после инцидента почти не было дополнительной активности в ончейне — и само это молчание действительно стоит наблюдать.

Интересно, отслеживает ли кто-то ещё эти данные: после инцидента как долго обычно каждый мост остаётся «молчаливым», прежде чем реально вернуться онлайн? Возможно, период молчания — один из самых ясных способов увидеть, как команда на практике подходит к управлению рисками.$DUSK $BMT $FOREST