Инцидент на мосту Dusk с прошлой недели на самом деле является неплохим окном в то, как DuskDS, DuskVM и DuskEVM разделены на практике, а не только на бумаге.

16 августа команда Dusk отметила подозрительную активность в кошельке, управляемом командой и используемом для операций моста, отключила затронутые адреса и приостановила сервисы моста, координируясь с Binance после того, как часть потока затронула биржу. Что заставило меня копнуть глубже: собственное уведомление команды об инциденте было прямым и четким, что проблема в ключе кошелька, а не в сбое протокола DuskDS. Это важное архитектурное различие: мост как операционный уровень расположен поверх расчетного слоя DuskDS, отдельно от консенсусной и исполняющей логики, которую на самом деле запускают DuskVM и DuskEVM.

Проверив последовательность, видно, что пауза выглядит скорее как реакция, а не как автоматизированное действие: это было ручное сдерживание, вызванное мониторинговым оповещением, а не схемой аварийного отключения (circuit-breaker), встроенной в протокол. Это стоит отметить тем, кто предполагает, что безопасность моста здесь обеспечивается на базовом уровне.

Что я не могу подтвердить: точное количество или объем транзакций в период инцидента, а также то, были ли «переработанные» адреса контролируемыми multisig. В уведомлении Dusk сказано, что средства пользователей не пострадали, но я не видел независимого ончейн-подтверждения этого заявления.

Кто-нибудь отслеживает, выполнены ли операции моста Dusk как multisig по дизайну, или это настройка с одним ключом?

@Dusk_Foundation $DUSK #dusk