Кроссчейн мосты: сравнительный анализ безопасности протоколов
Когда ломается один из ключевых элементов, потери измеряются уже не комиссиями за бридж.
С 2022 года ущерб от атак на мосты превысил 2,8 млрд долларов. Для тех, кто выбирает кроссчейн-мосты для передачи активов, сравнение безопасности поэтому начинается не с интерфейса и скорости, а с главного вопроса: кто подтверждает перевод и что именно протокол проверяет перед выпуском средств в целевой сети.
Почему мосты стали приоритетной целью
Мосты управляют потоками ликвидности между блокчейнами. В одной сети они могут блокировать исходный актив, а в другой выпускать его обёрнутую версию; альтернативная схема использует пул ликвидности, из которого пользователь получает актив уже на стороне назначения. В обоих случаях протокол должен достоверно установить, что исходное действие действительно произошло.
Проблема в том, что две сети не обязаны доверять друг другу и не всегда могут напрямую проверить состояние соседней цепочки. Мост добавляет слой, который передаёт сообщение и удостоверяет его подлинность. Если этот слой ошибается или его участники скомпрометированы, контракт назначения может выпустить активы под фальшивое подтверждение.
По опубликованным оценкам, доля атак на мосты составляет от 40% до 69% совокупных потерь DeFi за рассматриваемые периоды. Диапазон широкий: аналитики используют разные временные рамки и способы классификации инцидентов. Но общий сигнал однозначный — мосты концентрируют значительные объёмы активов и одновременно зависят от сложной межсетевой логики.
Сравнение мостов в DeFi не сводится к числу аудитов или громкости бренда. Для оценки нужно разложить систему на несколько частей:
- Подтверждение события: кто удостоверяет, что депозит или сжигание токенов состоялись в исходной сети.
- Порог принятия решения: сколько участников должны согласиться, чтобы сообщение прошло.
- Проверка на принимающей стороне: как контракт проверяет подпись, доказательство или набор данных.
- Управление ключами и обновлениями: кто может менять параметры, контракты и полномочия валидаторов.
- Поведение при сбое: останавливается ли перевод, если подтверждения нет или участники расходятся во мнениях.
Это не рейтинг, где можно набрать баллы и получить гарантированно безопасный вариант. Архитектура снижает одни риски, но может создавать другие: мультисиг упрощает координацию, однако делает критичными закрытые ключи; проверка криптографического доказательства уменьшает доверие к посредникам, но оставляет риск ошибки в реализации самой проверки.
У моста есть две точки, которые нельзя терять из виду: кто подписывает сообщение и кто проверяет эту подпись в контракте назначения.
Как устроена поверхность атаки
В типичном межсетевом переводе пользователь взаимодействует с контрактом в исходной сети. Далее протокол фиксирует событие и передаёт сообщение. На принимающей стороне контракт проверяет доказательство и выполняет действие: выпускает токен, разблокирует средства или выдаёт актив из пула.
В этой цепочке атакующему не всегда нужно ломать криптографию. Часто достаточно заставить систему принять ложное сообщение либо получить контроль над теми, кто имеет право его подписывать. Практический анализ уязвимостей мостов блокчейна должен различать по меньшей мере два класса угроз.
Первый — компрометация ключей и прав доступа. Валидаторы, подписанты или административные роли могут обладать полномочиями, достаточными для подтверждения перевода, обновления контракта или изменения конфигурации. Если атакующий получает нужный набор ключей, корректно написанный контракт всё равно исполнит команды, которые ему подписали. По данным фактуры, компрометация ключей и доступов объясняет примерно 38–56% потерь в рассмотренных атаках на мосты; в отдельных сводках эта доля достигает 56%.
Второй класс — ошибки логики и проверки доказательств. Контракт может неверно валидировать подпись, некорректно обрабатывать доказательство включения события в дерево Меркла или неправильно разбирать входные данные. Здесь протокол формально проверяет сообщение, но проверяет его с дефектом. Ошибка может быть небольшой на уровне кода и огромной по последствиям, если после неё контракт разрешает выпускать активы без реального депозита.
Есть и менее заметные места, где риск накапливается:
- порог подписей устроен разумно, но ключи хранятся и администрируются в одном организационном контуре;
- обновление контракта меняет предположения, на которых строились аудит и мониторинг;
- роли управления могут приостанавливать операции, но полномочия распределены неясно;
- интерфейс показывает успешное подтверждение одного этапа, хотя полный межсетевой цикл ещё не завершён;
- лимиты на объём и скорость выпуска токенов отсутствуют или не ограничивают масштаб ущерба.
Поэтому фраза «контракт прошёл аудит» отвечает лишь на часть вопросов. Аудит может найти дефекты кода, но сам по себе не гарантирует защиту ключей, корректную настройку ролей или безопасность последующих обновлений. Для пользователя это означает простую вещь: безопасность кроссчейн-протоколов зависит не от одной проверки, а от всей цепочки доверия.
Три атаки, три разных отказа
Крупные инциденты показывают, насколько разными путями мост может прийти к одному результату — выпуску или потере активов без надёжного основания.
| Протокол и дата | Ущерб | Уязвимое звено |
|---|---|---|
| Ronin Bridge, март 2022 года | около $625 млн | Компрометация 5 из 9 ключей валидаторов |
| Wormhole, февраль 2022 года | около $325 млн | Обход проверки подписи в контракте Solana |
| BNB Bridge, октябрь 2022 года | около $586 млн | Ошибка проверки доказательства IAVL Merkle |
Ronin: доверие к набору подписантов
В случае Ronin атакующим удалось получить контроль над пятью из девяти ключей валидаторов. Этого оказалось достаточно для прохождения порога подтверждения. Инцидент связывали с социальной инженерией: критическая точка была не только в программном коде, но и в доступе к ключам.
Для архитектурного сравнения здесь важен сам механизм. Пороговая схема 5 из 9 означает, что протокол продолжает работать, пока недоступны или не согласны несколько участников, но компрометация требуемого количества подписантов превращает этот запас устойчивости в точку отказа. Цифра участников сама по себе мало говорит о независимости: если ключи контролируются связанными командами или их операционная защита похожа, фактическое разнообразие доверия может быть ниже, чем в таблице.
Wormhole: проверка подписи в контракте
В феврале 2022 года Wormhole потерял около $325 млн из-за обхода проверки подписи в контракте сети Solana. В этой архитектуре использовалась Guardian Network: 19 валидирующих узлов, кворум — 13 из 19.
Кворум нужен, чтобы отдельный узел не мог единолично подтвердить сообщение. Но порог подписей не исправляет дефект в коде, который проверяет сами подписи. Если принимающий контракт неверно устанавливает, что подтверждение действительно, схема голосования может работать штатно, а проверка на последнем шаге — нет.
Этот кейс хорошо показывает, почему вопрос «сколько валидаторов?» недостаточен. Нужно понимать, как контракт проверяет кворум, каким образом формируется сообщение, какие поля подписываются и что произойдёт при некорректных данных.
BNB Bridge: доказательство принято неправильно
Атака на BNB Bridge в октябре 2022 года была связана с ошибкой проверки IAVL Merkle proof. Доказательство должно было подтверждать, что событие включено в состояние исходной системы. Уязвимость позволила пройти проверке некорректному доказательству и привела к ущербу около $586 млн.
Здесь не требовалось завладевать ключами валидаторов в смысле схемы Ronin или обходить именно ту проверку подписи, что пострадала в Wormhole. Уязвимым оказалось правило, по которому контракт оценивал криптографическое доказательство. Для читателя, сравнивающего риски использования кроссчейн-мостов, это важное различие: похожая пользовательская операция может зависеть от совершенно разных механизмов доверия.
Три крупных взлома показывают три разных слабых места: ключи, подписи и доказательства. Универсального аудита, который автоматически закрывает все три класса риска, нет.
Guardian Network и DPoS: что именно сравнивать
В Wormhole используется Guardian Network с 19 узлами и порогом 13 подписей. Axelar, согласно имеющимся данным, опирается на DPoS-модель с 75 активными валидаторами. Эти цифры позволяют сравнить устройство подтверждения, но не дают основания объявить одну систему безусловно безопаснее другой.
| Параметр | Wormhole | Axelar |
|---|---|---|
| Механизм подтверждения | Guardian Network | DPoS |
| Указанный состав | 19 валидирующих узлов | 75 активных валидаторов |
| Порог в доступных данных | 13 из 19 | Не указан в фактуре |
| Что можно заключить | Для сообщения требуется кворум Guardian | Подтверждение опирается на набор активных валидаторов |
| Чего эти числа не доказывают | Независимость операторов и безопасность ключей | Устойчивость к сговору или компрометации |
Число валидаторов — только верхний слой сравнения. Для оценки модели важны распределение контроля, процедура выбора участников, ротация, стоимость атаки и полномочия при остановке или обновлении системы. Если у нескольких операторов есть общий инфраструктурный или организационный риск, формально большой набор не обязательно даёт пропорционально большую безопасность.
У Wormhole обозначен конкретный кворум: 13 подписей из 19. Это помогает понять, какое число участников должно подтвердить сообщение, однако не отвечает на вопросы о хранении ключей, независимости операторов и защите контракта, который принимает подписи. История взлома как раз напоминает, что проверка кворума и проверка подписи — разные участки одной цепочки.
Для Axelar указано количество активных валидаторов, но в доступной фактуре нет порога согласия. Без него сравнение было бы неполным: нельзя корректно вывести, сколько участников должны быть недоступны или скомпрометированы, чтобы остановить либо подделать подтверждение. Не стоит заполнять пробел догадкой или превращать число валидаторов в условный рейтинг.
Когда выбираете маршрут, смотрите на практические свойства конкретной версии протокола и сети назначения. Мост может использовать разные контракты, активы и ограничения на разных направлениях. Общая репутация бренда не заменяет понимания того, какой именно механизм будет удостоверять ваш перевод.
Аудит, децентрализация и другие удобные иллюзии
Аудит полезен как проверка кода в заданном состоянии и с заданными предположениями. Он способен выявить часть логических ошибок, проблему в обработке входных данных или некорректную проверку доказательства. Но аудит не превращает мост в систему без риска: после проверки код могут обновить, роли могут быть настроены иначе, а ключи валидаторов могут утечь или оказаться под давлением социальной инженерии.
Децентрализация тоже не работает как магический защитный слой. Несколько подписантов — лучше, чем один, только если их контроль действительно разделён и компрометация одного узла не тянет за собой остальные. Случай Ronin показывает, что мультисиг с порогом 5 из 9 не спасает, когда атакующий получает пять ключей.
Есть и психологическая ловушка: пользователи часто оценивают мост по успешным переводам и знакомому интерфейсу. Пока операции проходят, архитектурные допущения остаются невидимыми. Но большой TVL, длительная работа и аккуратный UI не доказывают, что механизм подтверждения устойчив к новому типу атаки. На рынке DeFi спокойствие интерфейса иногда просто означает, что критический риск пока не материализовался.
Для первичного сравнения полезно задавать протоколу и его документации конкретные вопросы:
- кто подтверждает событие и сколько независимых участников нужно для кворума;
- где хранятся ключи и какие действия они разрешают;
- проверяет ли контракт подписи, криптографическое доказательство или оба механизма;
- кто может обновить контракт и как ограничены административные полномочия;
- существуют ли лимиты на выпуск и возможность остановить перевод при аномалии;
- распространяется ли аудит на актуальную версию контракта и выбранную сеть.
Если ответ на часть вопросов не опубликован или сформулирован расплывчато, это не автоматическое доказательство эксплойта. Но это неопределённость, которую нельзя списывать на маркетинговое описание. Для крупного перевода она имеет прямую цену: пользователь принимает на себя риск системы, которую не может полностью оценить.
Как выбирать маршрут без обещаний безопасности
При выборе моста полезно отделять качество механики от удобства. Скорость, комиссия и поддержка нужного токена важны, однако они не компенсируют непонятную схему подтверждения. Сначала определите, какой именно мост обслуживает выбранную пару сетей и какой контракт принимает сообщение на целевой стороне. Затем разберитесь, зависит ли маршрут от мультисига, набора валидаторов, проверяемого доказательства или сочетания этих механизмов.
Для небольшого перевода разумно проверить путь на ограниченной сумме и убедиться, что актив зачислен именно в ожидаемой сети и в нужной форме. Такой тест подтверждает работоспособность интерфейса и маршрута в данный момент; он не доказывает долгосрочную безопасность протокола. При большом объёме имеет смысл учитывать лимиты, делить операцию на части и не держать в мосте больше ликвидности, чем требуется для конкретной задачи.
Отдельно проверяйте токен на стороне назначения. Обёрнутая версия актива может зависеть от обязательств моста: даже если базовый токен в исходной сети существует, его представление в другой сети несёт риск механизма, который обеспечивает погашение или разблокировку. Это уже не только вопрос того, дошло ли сообщение, но и вопрос того, можно ли обменять полученный актив обратно.
Мой практический вывод для сравнения безопасности простой: сначала оценивайте модель доверия и поверхность управления, затем — качество проверки сообщений, и только после этого удобство маршрута. У Wormhole известны размер Guardian Network и порог 13 из 19; у Axelar известен состав из 75 активных валидаторов, но этих данных недостаточно для полного сравнения порога. В обоих случаях число участников — начало анализа, а не финальный вердикт.
Кроссчейн-мост остаётся критической инфраструктурой с риском на уровне ключей, контрактов и межсетевых доказательств. Выбирать его стоит по конкретной архитектуре и конкретному направлению перевода, сохраняя запас осторожности: аудит и децентрализация снижают отдельные риски, но не отменяют возможности эксплойта или компрометации доступа.
