Уязвимости мостов блокчейн: вектор атак на кроссчейн-ликвидность
Как может исчезнуть ликвидность из кроссчейн-моста, если сам блокчейн продолжает работать штатно? Ответ часто связан не с одной ошибкой в смарт-контракте, а с тем, как мост проверяет сообщения между сетями, кто подтверждает перевод и где хранятся активы.
Именно сочетание этих элементов определяет, насколько уязвим межсетевой протокол.
Новичкам устройство мостов может казаться простой переправой: отправили токен в одной сети, получили его в другой. Но за этой операцией скрываются разные архитектуры и несколько уровней доверия. Давайте разберёмся вместе, откуда берутся уязвимости мостов блокчейн, как устроены атаки на ликвидность и на что стоит смотреть, оценивая безопасность кроссчейн-моста.
Как мост переносит ценность между сетями
Блокчейны не обмениваются сообщениями автоматически. У каждой сети собственное состояние: она отдельно учитывает адреса, балансы и исполненные транзакции. Мост связывает эти системы и сообщает одной сети, что определённое действие произошло в другой.
На практике распространены две архитектурные модели. В первой актив блокируют в исходной сети, а в целевой выпускают его эквивалент. Во второй используются пулы ликвидности: пользователь получает актив из резерва целевой сети, а мост затем согласует поступления и обязательства между сетями.
| Параметр | Lock-and-mint | Мост с пулами ликвидности |
|---|---|---|
| Что происходит с активом | Исходный токен блокируется, в другой сети выпускается эквивалент | Получатель получает токены из доступного пула в целевой сети |
| На чём держится обеспечение | На заблокированных активах и корректном выпуске соответствующих токенов | На ликвидности пулов и согласованном учёте переводов |
| Где возникает риск | В проверке блокировки, сообщения о переводе и разрешении на выпуск или возврат | В работе пулов, учёте сумм между сетями и доступности резервов |
| Что может почувствовать пользователь | Перевод может задержаться, если подтверждение не прошло | Перевод может стать недоступен, если в целевом пуле недостаточно ликвидности |
В модели lock-and-mint мост должен надёжно подтвердить, что актив действительно заблокирован. Если в целевой сети токены выпускаются без корректного подтверждения, их обеспечение оказывается под вопросом. Если же при возврате мост ошибочно принимает доказательство или событие, возникает другой риск: актив может быть разблокирован без соответствующего основания.
Пулы ликвидности решают задачу иначе. Мост выдаёт получателю актив, уже находящийся в сети назначения. Такая схема зависит от состояния резервов и правильного учёта переводов между сетями. Если суммы, подтверждения или обязательства обрабатываются несогласованно, пул может пострадать, даже когда исходная транзакция пользователя была исполнена.
Поэтому «мост» не обозначает одну и ту же техническую конструкцию. У двух сервисов, которые внешне переводят токены одинаково, могут различаться хранение активов, порядок проверки сообщений и круг участников, принимающих решение о переводе.
Перевод через мост держится на цепочке подтверждений: ошибка в любом звене может затронуть активы в другой сети.
Где возникают уязвимости мостов
Исследование атак на кроссчейн-мосты за период с июля 2021 по июль 2023 года рассмотрело 31 публично известный случай и выделило 12 потенциальных поверхностей атаки. Уязвимости сгруппированы в четыре категории: ошибки разрешений, логики, событий и интерфейса.
Это удобная карта для понимания проблемы. Разрешения отвечают на вопрос, кто вправе запускать важные действия. Логика определяет, при каких условиях мост считает перевод корректным. События сообщают протоколу о действиях в блокчейне. Интерфейс связывает компоненты системы, включая контракты и внешнюю инфраструктуру. Ошибка в любой части может нарушить обработку межсетевого сообщения.
Вот несколько сценариев, которые помогают увидеть, насколько широк этот набор рисков:
- Неверная обработка событий. Мост может неправильно распознать или учесть событие в исходной сети. Если на его основе выпускаются активы или меняется статус перевода, ошибка в интерпретации становится частью угрозы.
- Ошибки проверки доказательств. Протоколу нужно убедиться, что сообщение о выпуске или возврате токенов действительно подтверждено. Слабая проверка может дать возможность провести действие без надлежащего основания.
- Повторное использование доказательства вывода. Если подтверждение уже использовали, система должна распознать это и отклонить повтор. Иначе один и тот же факт может быть принят больше одного раза.
- Манипуляция ценовым оракулом. Оракул передаёт данные о цене. Если мост использует их для расчётов или оценки активов, недостоверные данные способны исказить результат.
- Компрометация валидаторов или серверов. Некоторые модели полагаются на внешних участников и инфраструктуру, которые подтверждают или передают сообщения. Их взлом способен обойти ожидания пользователя о надёжности блокчейна.
Этот перечень не означает, что каждый мост уязвим к каждому сценарию. Он показывает другое: безопасность кроссчейн-моста нельзя оценить только по коду одного смарт-контракта. Проверка контракта важна, но ответ на вопрос «кто подтверждает перевод?» иногда не менее важен.
Для пользователя эта разница проявляется просто. Если перевод требует внешнего подтверждения, надёжность зависит не только от сети-отправителя и сети-получателя, но и от тех механизмов, которые переносят сообщение между ними. Сам блокчейн может корректно записать транзакцию, а мост при этом неверно обработать её результат.
Почему внешние подтверждения имеют значение
Чтобы целевая сеть приняла сообщение из другой сети, мост должен каким-то образом удостовериться, что оно подлинное. В разных протоколах для этого используются разные схемы: проверка может опираться на внешних валидаторов, серверы или комбинацию подтверждений. Универсальной архитектуры нет.
Отчёт LayerZero об инциденте от 18 апреля 2026 года наглядно описывает, как конфигурация подтверждений влияет на риск. В рассматриваемом случае DVN, то есть децентрализованные сети проверки, должны были подтвердить сообщение. При конфигурации 2-of-2 для подделки пакета требовалась компрометация двух DVN одновременно. При конфигурации 1-of-1 в этом конкретном примере было достаточно компрометировать одну.
Эти обозначения нельзя переносить на все мосты как общий рейтинг. Они описывают конкретную конфигурацию LayerZero и конкретную логику проверки. В том же отчёте механизм принятия сообщения устроен так, что все обязательные DVN должны его подтвердить, а число согласных необязательных DVN должно достичь установленного порога.
Для пользователя здесь важна не аббревиатура сама по себе, а устройство доверия. Нужно понимать, кто подтверждает межсетевое сообщение, сколько подтверждений требуется и что произойдёт, если один из участников станет недоступен или будет скомпрометирован. Большое число участников может выглядеть успокаивающе, но без понимания их ролей это число мало что говорит.
Внешняя инфраструктура тоже имеет значение. Серверы могут передавать сообщения или участвовать в их обработке. Их компрометация создаёт отдельный путь атаки, не сводящийся к уязвимости блокчейна. Поэтому фраза «сеть децентрализована» сама по себе не раскрывает, насколько децентрализован именно мост и как он переживает отказ отдельных компонентов.
Как атака затрагивает ликвидность
Уязвимость превращается в финансовый ущерб, когда злоумышленник получает возможность воздействовать на активы, которые обеспечивают работу моста. Резервы могут находиться в смарт-контракте или у централизованного хранителя. В обоих случаях место хранения становится целью: если контроль над ним утрачен, последствия могут затронуть средства, обеспечивающие выпуск bridged-токенов, то есть токенов-представлений актива в другой сети.
Историческую оценку масштаба таких инцидентов публиковала Chainalysis 2 августа 2022 года: тогда компания оценивала совокупные потери в 13 атаках на кроссчейн-мосты в 2 млрд долларов и указывала, что на мосты приходилось 69% средств, похищенных в 2022 году. Эти цифры относятся к оценке, опубликованной в 2022 году. Их нельзя читать как актуальную статистику за 2026 год: единой подтверждённой суммы потерь от всех атак на мосты на сегодняшний день в имеющихся данных нет.
У разных архитектур последствия могут выглядеть по-разному. В lock-and-mint уязвимость проверки способна привести к выпуску токенов без достаточного основания или к некорректному возврату заблокированных активов. В модели с пулами нарушение учёта может сказаться на резервах и доступности ликвидности в конкретной сети. При этом нельзя приписывать истощение пулов каждой атаке на мост: причины и результаты инцидентов различаются.
Для пользователя важно и то, что видимая операция не всегда показывает состояние всей системы. Транзакция может быть подтверждена в исходной сети, но мост ещё должен обработать сообщение, а целевая сеть — принять результат. Если один из этапов задерживается, это не обязательно означает взлом, однако отменять или повторять перевод наугад тоже не стоит: повторная операция может создать отдельную путаницу с суммами и статусами.
Практически полезно смотреть на несколько вещей, не превращая это в попытку самостоятельно провести аудит:
- Как именно мост обеспечивает перевод: блокирует актив и выпускает эквивалент или использует пулы ликвидности.
- Кто подтверждает сообщения между сетями и требуется ли согласие нескольких независимых участников.
- Где находятся активы, поддерживающие выпуск токенов в целевой сети.
- Как протокол сообщает о задержках и статусах переводов, а также что советует делать при незавершённой операции.
Эти вопросы не дают гарантии безопасности и не заменяют техническую проверку. Они помогают заметить разницу между мостами, которую интерфейс перевода обычно не показывает.
Почему у мостов нет универсальной оценки безопасности
Сравнивать мосты одним числом или ярлыком сложно. У них различаются способы хранения активов, модели подтверждения сообщений и архитектура взаимодействия сетей. Один протокол может больше зависеть от смарт-контрактов, другой — от внешних валидаторов или серверной инфраструктуры. Поэтому рейтинг, который не объясняет, что именно проверялось, легко вводит в заблуждение.
При оценке конкретного моста я бы разделял три вопроса. Первый: как система узнаёт, что событие действительно произошло в исходной сети? Второй: кто и по каким правилам подтверждает это сообщение? Третий: где находятся активы, которые должны быть доступны в случае перевода или возврата? Если на эти вопросы нет понятного ответа, это уже повод изучить устройство протокола внимательнее.
Для новичка такой разбор может звучать технически, но начать можно с простого. Посмотрите документацию моста и найдите описание модели перевода, проверки сообщений и хранения резервов. Если там используются сокращения вроде DVN, ищите пояснение их роли: само название участника не раскрывает, сколько подтверждений нужно и какие права он имеет.
Уязвимости мостов блокчейн возникают на пересечении нескольких систем: контрактов, сообщений, внешних участников и резервов. Поэтому атака на межсетевой протокол не всегда начинается с ошибки в коде, а взломы мостов в DeFi нельзя объяснить одной причиной. Спокойный разбор архитектуры помогает понять, где именно находится доверие и какие последствия может иметь отказ отдельного элемента.
Не переживайте, если с первого раза эта схема кажется запутанной: мосты действительно сложнее обычного перевода внутри одной сети. Начните с трёх вещей — модели перевода, механизма подтверждений и места хранения активов. Если у вас остались вопросы о конкретном протоколе или терминах, задавайте их: разбирать такую тему по шагам гораздо легче, чем пытаться охватить всё сразу.