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