#dusk $DUSK За эти два дня я пересмотрел безопасные маршруты @Dusk и понял, что предметом настоящего обсуждения является не то, были ли у проекта проблемы, а то, как он разделяет безопасность протокола, безопасность приложения и безопасность хранения активов. Многие, увидев инцидент с кроссчейн-мостом, в первую очередь списывают все риски на основную сеть; другие, услышав, что консенсус не был взломан, считают, что событие не связано с Dusk. Обе оценки слишком упрощённые. Для пользователей достаточно, чтобы во входе активов, в службе подписи или на кроссчейн-выходе обнаружилась уязвимость — и экономический ущерб становится реальным, его нельзя игнорировать только потому, что нижележащий протокол работает нормально.
В текущей ситуации Dusk должна иметь дело с многоуровневой системой: консенсус отвечает за состояние сети, виртуальная машина — за выполнение логики, Phoenix — за приватные транзакции, мосты и кошельки — за внешнюю передачу активов. Если ошибку будут допущены в граничных условиях любого слоя, это может повлиять на доверие пользователей ко всей сети. Поэтому исправление конкретной уязвимости — лишь первый шаг; важнее убедиться, что подобные проблемы того же типа не существуют в других компонентах, а также проверить, что исправленная версия охватывает узлы, кошельки и связанные сервисы.
Меня особенно интересует, превратит ли команда проекта внутреннюю проверку в устойчивый механизм, а не будет ждать до выхода крупного релиза, чтобы собранно проводить проверки. Нулевые доказательства, проверка подписи и десериализация относятся к базовым элементам, которые обычным пользователям сложно заметить; даже одна обновлённая версия с новым кодом может снова открыть старые риски. Внешние аудиты дают независимый взгляд, но не могут заменить работающий мониторинг, лимиты и механизм аварийной приостановки.$SPCXB
Поэтому, оценивая безопасность DUSK, нельзя опираться только на число аудитов и нельзя полагаться только на разовое объявление после инцидента. Более значимые показатели — это скорость исправления уязвимостей, доля обновлённых узлов, лимиты горячих кошельков, разделение полномочий по ключам и результаты последующих повторных проверок. Безопасность — это не обещание, что ошибок никогда не будет, а обеспечение того, чтобы ошибки было трудно разрастить и чтобы их можно было быстро обнаружить и контролировать.#dusk @Dusk $SNDKB