Я вижу одну вещь, которую стоит поставить рядом с инцидентом с bridge от 16/08, @Dusk — похоже, это не единичный сбой, а событие, произошедшее на фоне 2026 года, который стал худшим в истории по части bridge-exploit: по меньшей мере 328 млн USD было потеряно в рамках как минимум восьми крупных инцидентов к середине года, включая случай с bridge XRP, где резервы упали на 99,7% всего за 97 минут.
Если посмотреть на контекст, то то, как Dusk отреагировал на инцидент, выделяется в позитивную сторону: система мониторинга обнаружила аномальное поведение на рабочем кошельке, команда проактивно отключила адрес, приостановила bridge, внедрила blocklist и скоординировалась с Binance, когда потоки средств дошли до уровня «слива» — всё это было сделано до того, как наступил какой-либо ущерб. По сравнению со случаями полного списания активов всего за десятки минут, когда скорость превышает возможности ручного вмешательства.
Но что заставляет меня остановиться — тот же старый вопрос: механизм обнаружения и реакции полностью опирается на человеческий контроль и ручные права admin, а не на автоматическую криптографию DuskDS. Это как раз тот типовой образец, который в 2026 году снова и снова подчёркивают в отчётах по безопасности: риск в bridge в основном связан с управлением ключами и людьми, а не с уязвимостями алгоритмов; и стандартная рекомендация — сохранять рабочие меры вроде multisig с timelock, разделяющим роли.
Сам себе возражаю: на фоне того, как индустрия теряет сотни миллионов USD из‑за bridge, то, что у Dusk есть механизмы мониторинга, достаточно быстрые, чтобы остановить ситуацию до потери денег, — это операционный плюс, который не стоит недооценивать только потому, что «это всего лишь» ручной процесс.
Я жду, чтобы $DUSK опубликовал полный отчёт о результатах аудита безопасности bridge до повторного запуска сервиса, а DuskEVM, который скоро выйдет, будет ли сопровождаться иной моделью custody, отличной от текущего механизма.
#dusk $BTC $ETH
Если посмотреть на контекст, то то, как Dusk отреагировал на инцидент, выделяется в позитивную сторону: система мониторинга обнаружила аномальное поведение на рабочем кошельке, команда проактивно отключила адрес, приостановила bridge, внедрила blocklist и скоординировалась с Binance, когда потоки средств дошли до уровня «слива» — всё это было сделано до того, как наступил какой-либо ущерб. По сравнению со случаями полного списания активов всего за десятки минут, когда скорость превышает возможности ручного вмешательства.
Но что заставляет меня остановиться — тот же старый вопрос: механизм обнаружения и реакции полностью опирается на человеческий контроль и ручные права admin, а не на автоматическую криптографию DuskDS. Это как раз тот типовой образец, который в 2026 году снова и снова подчёркивают в отчётах по безопасности: риск в bridge в основном связан с управлением ключами и людьми, а не с уязвимостями алгоритмов; и стандартная рекомендация — сохранять рабочие меры вроде multisig с timelock, разделяющим роли.
Сам себе возражаю: на фоне того, как индустрия теряет сотни миллионов USD из‑за bridge, то, что у Dusk есть механизмы мониторинга, достаточно быстрые, чтобы остановить ситуацию до потери денег, — это операционный плюс, который не стоит недооценивать только потому, что «это всего лишь» ручной процесс.
Я жду, чтобы $DUSK опубликовал полный отчёт о результатах аудита безопасности bridge до повторного запуска сервиса, а DuskEVM, который скоро выйдет, будет ли сопровождаться иной моделью custody, отличной от текущего механизма.
#dusk $BTC $ETH
