THORChain подтверждает атаку на хранилище Asgard, убытки оцениваются примерно в $10,7 млн.
THORChain подтверждает атаку на хранилище Asgard, убытки оцениваются примерно в $10,7 млн.
15 мая 2026 года THORChain подтвердил, что одно из его хранилищ Asgard было скомпрометировано, что привело к предполагаемым убыткам в размере около 10,7 млн долларов США и временной остановке торговой активности, пока команда и операторы узлов проводят расследование и внедряют меры по устранению последствий. Общедоступная информация указывает на то, что средства пользователей не были основным источником потерь; вместо этого, ранние данные свидетельствуют о том, что пострадали средства, принадлежащие протоколу, при этом автоматизированные механизмы безопасности ограничили дальнейший ущерб. Вы можете отслеживать основное освещение событий в сообщениях от Cointelegraph и The Block, а также в специализированных отчетах об инциденте от The Defiant.
Это событие имеет значение не только для одного протокола: THORChain находится на пересечении межсетевой ликвидности, безопасности, управляемой валидаторами, и инфраструктуры высокоценных хранилищ — области, которая продолжает привлекать как инновации, так и изощренные атаки.
Что произошло (краткая хронология)
На основе собственных сообщений THORChain об инциденте и мониторинга сообщества, ключевые моменты следующие:
- Одно из хранилищ Asgard показало признаки компрометации, и сеть быстро перешла в оборонительную позицию, приостановив торговлю и исходящее подписание, чтобы снизить риск дальнейшего перемещения средств. Отчеты указывают на то, что предполагается, что был затронут 1 из 6 хранилищ Asgard. См. обзор освещения от The Defiant и обзор рыночной информации от Cointelegraph.
- Сработали автоматические средства обнаружения и остановки. Архитектура THORChain поддерживает остановку сети и цепочек через параметры управления и безопасности, предназначенные для остановки исходящей активности при достижении пороговых значений риска (документация: Network Halts).
- Было активировано "слэшинг" для задействованных узлов из-за переводов, признанных неавторизованными согласно правилам протокола, что обеспечивает основное обещание безопасности THORChain: операторы узлов рискуют своим капиталом (залоговым RUNE), если они действуют недобросовестно. Механизмы "слэшинга" THORChain описаны в его технической документации по поведению хранилищ (см. Vault Behaviors).
На момент написания (15 мая 2026 г.) расследование продолжается, и детали могут измениться. Если вы полагаетесь на THORChain для обмена или предоставления ликвидности, рассматривайте это как активный инцидент и следите за официальными обновлениями статуса.
Почему инцидент с хранилищем Asgard — это серьезно
THORChain лучше всего понимать как межсетевую сеть хранилищ и расчетов. Вместо оборачивания активов или использования единого ключа хранителя, THORChain использует хранилища Threshold Signature Scheme (TSS), управляемые вращающимся набором валидаторов. Эта конструкция задокументирована в объяснениях архитектуры THORChain, включая Bifrost, TSS and Vaults, а также в деталях о том, как хранилища шардируются и управляются с течением времени в Vault Behaviors.
Хранилища Asgard являются центральными, поскольку они хранят ликвидность, используемую для выполнения межсетевых обменов. Когда что-то идет не так на уровне хранилища, радиус поражения может охватить несколько цепочек — именно тот тип «многоцепочечной поверхности», который предпочитают злоумышленники.
Встроенные «автоматы безопасности», которые помогли сдержать ущерб
Одним из наиболее важных выводов является не только сам факт эксплуатации, но и то, что сеть отреагировала остановкой исходящей активности.
THORChain явно поддерживает механизмы для остановки подписания и исходящих переводов при определенных условиях, в том числе при превышении установленных пороговых значений для событий «слэшинга». Намерение ясно: когда сеть обнаруживает поведение, похожее на неправильное перемещение средств, она должна безопасно завершить работу, а не остаться в открытом состоянии. THORChain описывает эти элементы управления в своей документации для разработчиков по Network Halts и свою более широкую модель безопасности в Network Security and Governance.
С точки зрения безопасности DeFi, эти «автоматы безопасности» важны, потому что межсетевые системы не имеют роскоши «отката» цепочки. Ваши лучшие средства защиты — это часто:
- быстрое обнаружение аномалий,
- возможность приостановить более рискованные пути (исходящие расчеты),
- и четкие, заранее согласованные стимулы, наказывающие злонамеренных или небрежных операторов.
Средства пользователя против средств, принадлежащих протоколу: как интерпретировать различие
Первоначальные заявления THORChain и ранние отчеты предполагают, что затронутая стоимость принадлежала протоколу, в то время как обычные торговые потоки пользователей не были существенно затронуты. Это осмысленное различие, но пользователи должны интерпретировать его осторожно:
- В межсетевых протоколах «средства пользователей в безопасности» часто означает, что балансы пользователей не были напрямую выведены из личных кошельков, и система считает, что затронутое распределение хранилища не было в первую очередь связано с переводами, инициированными пользователями.
- Однако, даже когда убытки классифицируются как принадлежащие протоколу, инцидент все равно может создать вторичный риск для пользователей из-за простоя, задержек в расчетах, сбоев маршрутизации или более широкого влияния на рынок.
Если вы инициировали обмен незадолго до окна остановки, вашим приоритетом должно быть подтверждение финальности в исходной цепочке и проверка, была ли завершена исходящая часть, — особенно в сценариях межсетевой маршрутизации.
Почему был приостановлен «churn» и что это сигнализирует об операционной деятельности
THORChain использует процесс, называемый «churn», для ротации наборов валидаторов и членов хранилищ. При нормальных условиях «churn» со временем улучшает безопасность, ограничивая время, в течение которого фиксированная группа контролирует мощность подписи. Документация по операциям узлов THORChain описывает обычную периодичность «churn» и концепции жизненного цикла валидатора (см. Node Operations).
Во время инцидента приостановка «churn» является рациональным шагом, поскольку:
- «churn» изменяет состав хранилища и динамику подписания,
- это может усложнить криминалистический анализ,
- и это увеличивает операционную нагрузку в самый неподходящий момент.
Коротко: стабильность прежде всего, затем восстановление.
Угол ответственности валидаторов: залог и «слэшинг» все еще имеют значение
Межсетевая безопасность в конечном итоге зависит от стоимости атаки на систему. Модель THORChain полагается на то, что узлы закладывают RUNE, а затем сталкиваются со штрафами, если они подписывают или разрешают недействительные переводы.
Если «слэшинг» применяется правильно, он служит двум целям:
- Он помогает сдерживать злонамеренное поведение, делая атаки дорогостоящими.
- Он снижает моральный риск, наказывая за плохую оперативную безопасность (например, скомпрометированную инфраструктуру или небезопасные практики управления ключами).
THORChain документирует взаимосвязь между поведением хранилища и «слэшингом» в Vault Behaviors, а также описывает предположения безопасности сети и стимулы в Network Security and Governance.
Почему это соответствует более широкой тенденции 2025–2026 годов: «налог на безопасность» для межсетевой ликвидности
Даже по мере улучшения пользовательского опыта межсетевого взаимодействия, индустрия по-прежнему платит растущий «налог на безопасность». Панели данных, такие как база данных взломов DeFiLlama, затрудняют игнорирование этой закономерности: злоумышленники концентрируются на системах, где одна уязвимость может разблокировать ценность в нескольких цепочках.
Именно поэтому пост-инцидентные повествования, как правило, фокусируются на:
- управлении ключами и операционной безопасности,
- принудительном исполнении политики подписания,
- риске зависимостей в сложных межсетевых стеках,
- и на том, были ли правильно откалиброваны триггеры мониторинга и остановки.
Для исторического контекста по месяцам с большими убытками, отчеты, такие как сводки убытков индустрии от Immunefi, помогают оценить, насколько быстро может возрасти риск (см. отчет Immunefi: Crypto Losses February 2025).
Практические рекомендации для пользователей прямо сейчас
Пока THORChain и операторы узлов работают над расследованием и исправлениями, рассмотрите следующее:
-
Избегайте поспешных транзакций во время частичных сбоев Если торговля или подписание приостановлены, пользовательские интерфейсы могут показывать несогласованные состояния. Дождитесь четкого подтверждения возобновления исходящей активности.
-
Проверяйте результаты в блокчейне, а не только в UI Для любого межсетевого обмена независимо подтвердите транзакцию в исходной цепочке и получение в цепочке назначения.
-
Относитесь к сообщениям «поддержка восстановления» по умолчанию как к враждебным После взломов значительно увеличиваются фишинговые атаки. Не подключайте кошельки к неизвестным «возвратным» сайтам и не подписывайте произвольные сообщения.
-
Повторно проверьте одобрения и разрешения (пользователи EVM) Если вы недавно использовали маршрутизаторы или смарт-контракты, просмотрите одобрения токенов и отзовите все ненужные с помощью надежных инструментов.
Где аппаратный кошелек, такой как OneKey, вписывается в этот разговор
Этот инцидент, по-видимому, укоренен в операциях хранилища/безопасности на стороне протокола, а не в компрометации закрытых ключей конечных пользователей. Тем не менее, это подкрепляет вечное правило: пользователи должны контролировать ключи с помощью надежной, офлайн-безопасности — особенно при взаимодействии с DeFi и межсетевыми приложениями, где сложность транзакций высока.
Аппаратный кошелек, такой как OneKey, может помочь, сохраняя ваши закрытые ключи изолированными от потенциально скомпрометированных устройств и предоставляя вам более четкий и осознанный процесс подписания для действий с высоким риском (одобрения, взаимодействие с контрактами и крупные переводы). В периоды волатильных инцидентов — когда мошенники активны, а состояния пользовательского интерфейса могут быть запутанными — более медленное подписание с предварительной проверкой является функцией, а не ошибкой.
По мере того, как THORChain публикует более глубокие технические результаты и детали исправления, наиболее важными сигналами, за которыми стоит следить, будут: подтвержденная первопричина, снижает ли исправление системный вектор атаки, и насколько эффективно «слэшинг» и операционные требования выравнивают стимулы для обеспечения безопасности узлов в будущем.
