Кроссчейн мосты: критические риски безопасности для DeFi

Кроссчейн-мосты: критические риски безопасности для DeFi

Для контекста: на мосты приходилось 69% всех средств, украденных из криптовалютных сервисов с начала 2022 года по состоянию на 2 августа 2022 года, по оценке Chainalysis.

Это не случайный перекос статистики. Мосты стоят на пересечении двух уязвимых зон: крупных резервов и сложной логики подтверждения событий в разных блокчейнах. Они либо хранят активы в исходной сети, либо управляют выпуском токенов-представителей, либо координируют ликвидность между несколькими цепочками. Ошибка в одной части системы может превратить корректный перевод в неконтролируемый выпуск активов.

Поэтому кроссчейн-мосты и риски безопасности для пользователей нельзя оценивать только по размеру комиссии или скорости транзакции. Важнее понять, кто подтверждает перевод, где находятся резервы, каким образом выпускается актив в сети назначения и что произойдёт, если один из элементов перестанет работать штатно.

Механика работы мостов: почему смарт-контракты становятся «медовыми ловушками»

В базовой модели мост блокирует актив в сети-источнике и обеспечивает получение эквивалентной ликвидности в сети-назначении. Пользователь отправляет актив в контракт или на контролируемый мостом адрес. После подтверждения операции система создаёт токен-представитель в другой сети либо перечисляет пользователю актив из заранее сформированного пула ликвидности.

При обратном переводе токен в сети назначения может быть сожжён, после чего актив в исходной сети разблокируется. В другой архитектуре пользователь возвращает токен в ликвидностный пул, а мост или его операторы проводят встречную операцию в исходной сети. С точки зрения пользователя это выглядит как один маршрут, но с точки зрения безопасности перед нами несколько независимых механизмов: блокировка, подтверждение, выпуск, погашение и расчёт между сетями.

Контракт моста в этой схеме — не просто проводник. Это резерв, точка эмиссии и набор правил, по которым система решает, имеет ли право пользователь получить актив. На его адресах или под контролем связанных с ним операторов могут находиться средства десятков тысяч пользователей.

В отличие от DEX, где ликвидность распределена по пулам и зависит от конфигурации торговых пар, мост часто концентрирует капитал в одном или нескольких контрактах с относительно фиксированной логикой доступа. Для атакующего это удобная цель: не нужно искать множество отдельных пользователей или взламывать десятки кошельков. Достаточно добиться разблокировки резерва, подделать сообщение о депозите или получить возможность выпускать токены без соответствующего обеспечения.

TVL популярных мостов может исчисляться сотнями миллионов долларов. Это не абстрактная метрика для рейтингов DeFi, а карта приоритетов для эксплойтера: чем больше активов сосредоточено в контракте, тем выше потенциальная выгода атаки при сопоставимых затратах на поиск уязвимости. Экономика взлома моста напоминает экономику спортивных ставок на крупных турнирах — спортивные события с высоким призовым фондом привлекают не только легитимных участников, но и попытки манипуляций: чем больше денег в системе, тем острее вопрос контроля.

Где именно возникает доверие

Пользователь может считать, что перевод защищён самим блокчейном. Но мосту обычно нужно доказать событие в одной сети другой сети. Ethereum не «видит» состояние Solana, а Arbitrum не принимает автоматически каждое событие из BNB Chain. Между ними появляется слой верификации.

Он может быть построен по-разному:

• группа валидаторов подписывает сообщение о том, что депозит состоялся;
• оракульная сеть передаёт данные о событии в целевую цепочку;
• лайт-клиент проверяет криптографическое доказательство состояния исходного блокчейна;
• ликвидностные посредники исполняют перевод, а расчёт между ними происходит отдельно;
• специальный механизм консенсуса подтверждает, что сообщение действительно было сформировано допустимым участником.

Каждая модель меняет профиль риска. В первом случае нужно защищать ключи валидаторов. Во втором — оракулы и правила агрегации данных. В третьем — код проверки доказательств и корректность финальности исходной сети. В ликвидностной модели добавляется риск неплатёжеспособности или нехватки средств у посредников.

Мост становится «медовой ловушкой» не потому, что любой его контракт обязательно написан плохо. Проблема в сочетании масштаба и сложности: значительный резерв, несколько блокчейнов, асинхронное подтверждение, возможность обновления кода и набор административных ключей. Достаточно одного сбоя на этом маршруте, чтобы система либо выпустила лишние токены, либо разблокировала чужие средства.

Статистика атак: масштаб потерь и уроки взломов Ronin и Wormhole

Ключевые инциденты показывают, что у мостов нет единственного «типового» взлома. В одном случае атакующий получает ключи операторов, в другом — обходит проверку сообщения, в третьем — использует уязвимость в логике управления или в процедуре обновления.

Взлом Ronin — один из наиболее наглядных примеров компрометации валидаторов. Сеть использовала мост с девятью валидаторами, а для подтверждения транзакции требовалось пять подписей. Атакующий получил контроль над пятью приватными ключами: четыре принадлежали валидаторам Sky Mavis, пятый — стороннему валидатору Axie DAO. После этого система получила формально достаточное количество подписей для проведения вывода.

Здесь важно различать две проблемы. Первая — кража ключей. Вторая — отсутствие ограничений, которые могли бы остановить необычную операцию даже при наличии нужного числа подписей. Лимиты на размер вывода, задержка исполнения, независимый мониторинг и ручное подтверждение крупной транзакции не устраняют компрометацию, но способны ограничить её последствия.

Wormhole продемонстрировал другой класс сбоя. Уязвимость в логике проверки позволила сформировать сообщение, которое система приняла как доказательство блокировки средств в исходной сети. В результате в сети назначения были выпущены wETH без соответствующего депозита в Ethereum. Это не просто «ошибка минтинга»: проблема возникла на границе между событием в одной цепочке и его интерпретацией в другой.

69% всех криптовалютных краж с начала 2022 года по состоянию на 2 августа 2022 года пришлись на атаки на мосты. Небольшое число протоколов сконцентрировало подавляющую часть потерь индустрии.

После подобных инцидентов рынок сталкивается не только с прямым ущербом. Нужно определить, какие токены действительно обеспечены, какие операции можно откатить, какие резервы остаются под контролем протокола и кто будет принимать решение о восстановлении работы. Даже если команда компенсирует часть потерь, это не возвращает прежнюю ликвидность автоматически.

Технические уязвимости: от ошибок логики mint/burn до компрометации ключей

Кроссчейн-протоколы уязвимы сразу на нескольких уровнях. Ошибка в пользовательском интерфейсе может привести к потере средств конкретного отправителя. Ошибка в смарт-контракте — к выпуску активов для атакующего. Компрометация ключей — к легитимному с точки зрения контракта, но мошенническому выводу средств.

Ошибки в логике выпуска и погашения

Модель lock-and-mint требует, чтобы объём выпущенных токенов соответствовал объёму активов, заблокированных в исходной сети. На практике это соответствие может нарушаться из-за:

• повторной обработки одного и того же сообщения;
• отсутствия уникального идентификатора операции;
• ошибки в проверке chain ID или адреса контракта-источника;
• несовпадения формата токена в разных сетях;
• неправильного порядка действий при mint и burn;
• возможности вызвать административную функцию обычным пользовательским сообщением;
• сбоя при обработке частично подтверждённого перевода.

Критическая деталь — уникальность сообщения. Мост должен понимать, что конкретный депозит уже был использован для выпуска актива и не может быть предъявлен повторно. Для этого применяются nonce, хэши сообщений, идентификаторы исходной транзакции и отметки об исполнении. Но наличие такого поля само по себе ничего не гарантирует: его нужно проверять в правильном контексте и хранить так, чтобы разные сети или разные версии контракта не могли интерпретировать один и тот же пакет как новую операцию.

Ошибки проверки сообщений

Сообщение о переводе должно подтверждать не только факт существования транзакции. Необходимо проверить, что:

• транзакция произошла в нужной сети;
• событие было создано нужным контрактом;
• актив и количество соответствуют заявленным;
• получатель и сеть назначения не были подменены;
• транзакция достигла требуемой финальности;
• сообщение ещё не исполнялось;
• подписи или криптографическое доказательство относятся именно к этому сообщению.

Неполная проверка любого из этих элементов создаёт пространство для подделки. Особенно опасны ситуации, когда контракт доверяет внешнему релееру больше, чем должен, или принимает подпись без проверки полного набора параметров. В кроссчейн-системах нельзя проверять только «похожесть» сообщения: нужно удостовериться, что его содержание и контекст совпадают с тем, что произошло в исходной сети.

Прокси и обновление логики

Upgradeable-контракты позволяют исправлять ошибки без полной миграции ликвидности. Это полезно, но добавляет административный риск. Адрес, который может обновить логику моста, фактически контролирует правила работы системы. Если такой ключ украден, его владелец может заменить код на версию, разрешающую вывод резервов или выпуск неограниченного количества токенов.

Timelock даёт пользователям и мониторинговым системам время заметить изменение. Он не делает обновление безопасным автоматически. Нужно также понимать, кто управляет правом обновления, можно ли обойти задержку, есть ли экстренный режим и кто имеет право приостановить операции.

Компрометация ключей валидаторов

В доверенных или гибридных мостах подписи валидаторов часто заменяют проверку состояния исходного блокчейна. Тогда безопасность перевода зависит от того, как устроены ключи:

• хранятся ли они в аппаратных устройствах или на обычных серверах;
• разделены ли полномочия между операторами;
• используется ли MPC или классическая мультисигнатура;
• требуется ли несколько независимых подтверждений;
• меняется ли состав валидаторов через прозрачную процедуру;
• существуют ли лимиты на одну транзакцию и суточный вывод.

Порог 5 из 9 не является магическим числом безопасности. Если несколько ключей находятся у одной команды, в одной инфраструктуре или защищены одинаковыми средствами, формальная децентрализация может оказаться менее значимой, чем выглядит на схеме.

Доверенные против бездоверительных систем: иллюзия безопасности в DeFi

Ethereum.org классифицирует мосты по степени доверия. Это не бинарное деление, а спектр. На одном полюсе находятся решения, где пользователь фактически доверяет федерации или оператору. На другом — протоколы, которые стремятся проверять состояние исходной сети с минимальным числом внешних предположений.

Доверенные мосты используют внешних валидаторов, федерации, мультисигнатуры, MPC-кошельки или оракульные сети. Пользователь дополнительно полагается на то, что операторы:

• не потеряют и не раскроют ключи;
• не вступят в сговор;
• не изменят правила в одностороннем порядке;
• не остановят вывод средств;
• корректно обработают спорное или нестандартное сообщение.

Основные риски такой модели:

• компрометация приватных ключей;
• сговор участников, контролирующих порог подписей;
• цензура отдельных транзакций;
• зависимость от оператора при восстановлении после инцидента;
• непрозрачность резервов и внутренних процедур.

Бездоверительные, или trustless-мосты стараются опираться на доказательства, которые можно проверить средствами самого протокола или подключённого блокчейна. Это сокращает зависимость от конкретной группы операторов, но не отменяет риск кода. Ошибка в лайт-клиенте, неверная модель финальности или недостаточная защита от реорганизации способны привести к тому же результату — выпуску активов без достаточного основания.

У такой архитектуры есть и собственная граница применимости. Если исходная сеть подверглась атаке на консенсус или откатила состояние, мост может получить корректное с технической точки зрения, но уже неактуальное доказательство. Кроме того, безопасность протокола зависит от того, насколько правильно он понимает финальность подключённой сети.

Trustless-мост не значит «без риска». Он значит «без дополнительных предположений» — но корректность кода и безопасность подключённых блокчейнов по-прежнему на вашей стороне.

Разница между двумя моделями — в типе экспозиции, а не в её наличии. Доверенный мост добавляет контрагентный риск оператора. Бездоверительный концентрирует риски в коде, механизме доказательств и консенсусе подключённых цепочек. Поэтому сравнение безопасности популярных мостов должно начинаться не с рейтинга и не с рекламного определения trustless, а с вопроса: какие именно предположения делает система и что произойдёт при нарушении каждого из них.

Wrapped-активы: нативный ETH, локальный WETH и токены моста

Термины wrapped ETH часто создают ложное ощущение, будто любой ETH в другой сети является одним и тем же мостовым токеном. Это не так. Для оценки безопасности перевода активов между сетями нужно разделять как минимум три сущности.

Нативный ETH

В Ethereum нативный актив — ETH. Он не является ERC-20-токеном и используется, в частности, для оплаты комиссий. В Arbitrum ETH также выступает нативным активом сети и используется для газа. Если ETH перемещён в Arbitrum через официальный канонический механизм, на целевой сети пользователь получает нативный ETH Arbitrum, а не обязательно отдельный «wrapped ETH», выпущенный сторонним мостом.

Это важное различие. Нативный ETH Arbitrum не следует автоматически описывать как токен, который подтверждает наличие заблокированного ETH в конкретном контракте Ethereum. Его обращение и статус определяются архитектурой самого канонического моста и правилами Arbitrum.

Локальный WETH

WETH — это ERC-20-обёртка над нативным ETH внутри конкретной сети. На Arbitrum локальный WETH выпускается специальным контрактом этой сети в обмен на нативный ETH и может быть погашен обратно через тот же механизм. Его назначение — сделать ETH совместимым с приложениями, которые работают с токенами стандарта ERC-20.

Локальный WETH на Arbitrum не равен автоматически WETH в Ethereum и не является по определению мостовым активом. У каждой сети свой контракт WETH и своё состояние. Цена такого токена обычно поддерживается возможностью обмена на нативный ETH через локальный контракт, а не обязательством стороннего моста хранить резерв на Ethereum.

Мостовой wrapped-токен

Отдельные мосты выпускают собственные представления активов. Такой токен может называться wrapped ETH, bridged ETH, axlETH или иначе — название зависит от протокола. Его стоимость и возможность погашения зависят от конкретной архитектуры:

• актив может быть заблокирован в исходной сети, а токен выпущен в целевой;
• токен может быть создан против ликвидности, которую поставляют посредники;
• резерв может быть сформирован через пул, и тогда обеспечение зависит от дисциплины участников пула, а не от единственного контракта.

Здесь и возникает основной источник путаницы. Пользователь видит тикер ETH и считает, что любой такой токен взаимозаменяем с ETH на Ethereum. В действительности за каждым «обёрнутым» активом стоит конкретный мост, конкретный резерв и конкретная процедура погашения. При компрометации одного моста «его» wrapped-токен теряет обеспечение, тогда как нативный ETH или локальный WETH другой сети остаются нетронутыми.

Два актива с одинаковым тикером ETH могут иметь разных эмитентов, разные резервы и разный правовой статус в протоколе. Смешение этих сущностей — частая причина потерь при переводах между сетями.

Для практической оценки достаточно простого правила: прежде чем использовать мост, нужно понимать, какой именно токен появится на целевой сети и кто гарантирует его обеспечение. Если эту информацию нельзя получить из документации и проверенных источников протокола, использовать такой мост для значительных сумм не стоит.

Стандарты защиты: на что обращать внимание при выборе протокола

Безопасный мост не определяется одной метрикой — ни TVL, ни числом аудитов, ни словом trustless в описании. Защита складывается из сочетания архитектурных решений, операционной дисциплины и прозрачности для внешнего наблюдателя. Ниже — набор параметров, по которым имеет смысл оценивать протокол перевода активов.

Архитектура и модель доверия

Первый вопрос — какой именно механизм подтверждает событие в исходной сети. Если это группа валидаторов, важны их число, порог подписей и географическая и инфраструктурная распределённость. Если это оракулы — кто поставляет данные и как агрегируются расхождения. Если это лайт-клиент — насколько корректно описана модель финальности исходного блокчейна и что происходит при реорганизации. У каждой модели свои слабые места, и их нужно знать до того, как актив отправлен в контракт.

Аудит и история инцидентов

Наличие аудита само по себе не гарантирует безопасности. Важнее полнота охвата: проверялись ли именно те компоненты, через которые проходит пользовательский перевод, и менялся ли код после публикации отчёта. Отдельного внимания заслуживает реакция команды на прошлые инциденты: был ли проведён разбор причин, выплачены ли компенсации, изменилась ли архитектура после обнаруженной уязвимости. История ошибок показывает зрелость процессов не хуже, чем отсутствие взломов.

Контроль обновлений и timelock

Многие мосты остаются upgradeable. Это значит, что код, под управлением которого находятся средства, может быть заменён. Безопасная модель требует не только timelock, но и понятной процедуры обновления: кто инициирует изменение, какие подписи нужны для его одобрения, есть ли публичный мониторинг ожидающих обновлений. Если правила обновления непрозрачны или допускают короткие задержки для крупных изменений, административный риск приближается к риску централизованного кастодиана.

Лимиты, паузы и мониторинг

Механизмы защиты в реальном времени снижают ущерб даже при успешной атаке. Лимиты на размер одной транзакции, суточные лимиты, задержки для крупных операций, возможность приостановки вывода при аномальной активности — всё это не отменяет необходимости аудита, но ограничивает последствия компрометации. Важно также, чтобы эти механизмы были активны по умолчанию, а не только после инцидента.

Резервы и прозрачность

Для мостов с моделью lock-and-mint критична возможность проверить, что заблокированные в исходной сети активы соответствуют объёму выпущенных токенов. Доказательства резервов, публичные адреса казначейства, регулярные отчёты — признаки зрелой операционной дисциплины. Если протокол не предоставляет таких данных, остаётся только верить публичным заявлениям команды.

Состав валидаторов и инфраструктура

В системах с подписями качество децентрализации измеряется не формальным порогом, а тем, как устроены ключи. Находятся ли они у независимых операторов с разной инфраструктурой, используется ли MPC или HSM, есть ли процедура ротации и реагирования на компрометацию. Когда большая часть ключей сосредоточена в одной команде или на одной облачной платформе, заявленная децентрализация становится декоративной.

Операционные риски вне кода

Атаки на мосты не исчерпываются уязвимостями смарт-контрактов. Социальная инженерия против операторов, компрометация интерфейса через DNS или фронтенд, фишинговые подписи в кошельках пользователей — всё это также относится к рискам переводов между сетями. Поэтому оценка протокола должна включать и его фронтенд: как реализована подпись сообщений, проверяется ли домен, доступен ли пользователю способ верифицировать адрес назначения до отправки.

Совокупность этих параметров формирует профиль риска конкретного моста. Два протокола с похожим TVL и числом аудитов могут радикально отличаться по реальной уязвимости, если у одного timelock короче, валидаторы сосредоточены в одной структуре, а интерфейс не проверяет домен перед подписью.

Позиция автора

Кроссчейн-переводы остаются одной из самых уязвимых точек DeFi. Не потому, что разработчики мостов некомпетентны, а потому что задача объективно сложна: нужно согласовать состояние разных блокчейнов, защитить крупные резервы и одновременно сохранить скорость и удобство для пользователя. Любое из этих требований можно выполнить отдельно, но их сочетание создаёт пространство для атак.

С практической точки зрения это означает, что перевод крупных сумм через мост должен рассматриваться как осознанный выбор с измеримым риском. Для небольших переводов между основными сетями канонические механизмы уровня Arbitrum или Optimism обычно достаточно безопасны, поскольку опираются на проверенную архитектуру и ограниченный набор доверенных ролей. Для новых, малоизвестных или обещающих особенно выгодные условия мостов порог осторожности должен быть выше.

Главный вопрос, который стоит задавать перед каждым переводом: что именно окажется на целевой сети, кто гарантирует его обеспечение и при каких условиях эта гарантия перестаёт работать. Если ответы расплывчаты, лучше либо отложить перевод, либо разбить сумму на несколько транзакций, либо вовсе отказаться от использования конкретного протокола.