Мосты между блокчейнами: почему соединять сети так трудно

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

Содержание

1. Раздельные состояния
2. Модель lock и mint
3. Проверка сообщения
4. Финальность и replay
5. Наборы подписантов
6. Классы атак
7. Альтернативы и компромиссы

Раздельные состояния

Ethereum, Bitcoin и другие сети ведут независимые реестры и достигают согласия своими способами. Адрес и баланс в одной цепи сами по себе ничего не доказывают другой цепи. Если контракт в сети B собирается выпустить токен после блокировки актива в сети A, ему нужно получить надёжное свидетельство о событии в A: какой контракт его зафиксировал, на каком блоке, не была ли транзакция отменена реорганизацией и не обрабатывали ли это сообщение раньше.

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

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

Модель lock и mint

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

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

Не все мосты используют lock-and-mint. Пул ликвидности может заранее держать активы на обеих сетях и оплачивать получателю перевод локальным токеном; затем участники балансируют позиции между сетями. Такой подход может быть быстрее и удобнее, но ограничен глубиной ликвидности и не всегда поддерживает сложные сообщения. Атомарные обмены пытаются связать действия в разных доменах так, чтобы обе части состоялись или ни одна не состоялась, однако их применимость также зависит от возможностей сетей и времени блоков.

Проверка сообщения

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

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

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

Финальность и повторная обработка

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

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

Сложнее всего обобщённые мосты, которые передают не только актив, но и команду исполнить произвольное действие в целевой сети. Тогда безопасность зависит от того, как сообщение кодируется, кто подтверждает его и какие полномочия имеет принимающий контракт. Если ошибочное сообщение вызывает только перевод токена, ущерб ограничен этим активом; если оно управляет протоколом, последствия могут затронуть более широкую систему. Именно поэтому удобство «одним кликом вызвать приложение в другой сети» скрывает многоуровневую цепочку доверия.

Наборы подписантов

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

Порог подписей описывает лишь часть модели. Нужно знать, кто может менять программу, приостанавливать переводы, обновлять адреса или отзывать средства. В некоторых системах есть guardian, администратор или аварийная кнопка. Это может помочь при обнаружении атаки, но одновременно формирует привилегированный контроль. Пользователь должен понимать, является ли такой контроль временным, прозрачным и ограниченным правилами.

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

Данные о мостовом переводе также должны связывать конкретную транзакцию с конкретным событием. Проверяется ли контракт-источник? Достаточно ли подтверждений блока? Может ли сеть выполнить реорганизацию? Есть ли защита от повторного предъявления? Если эти вопросы не прописаны в пользовательском интерфейсе, человек видит простой маршрут, а сложность риска остаётся скрыта за кнопкой.

Классы атак

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

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

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

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

Альтернативы и компромиссы

Не существует одного моста, который одновременно обеспечивает мгновенность, любую сетевую связь, минимальную цену, полную проверяемость и отсутствие дополнительных предположений. Ethereum.org описывает важные измерения: безопасность, удобство, связность, способность передавать сложные сообщения и стоимость. Внешний набор проверяющих может подключать много сетей и работать быстро, но пользователь должен учитывать его ключи и управление. Light client может опираться на консенсус другой цепи, но ограничить поддерживаемые сети и увеличить сложность. Optimistic-механизм может задерживать вывод ради периода оспаривания.

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

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

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

Как выбирать между моделями

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

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

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

Источники

1. Japan Financial Services Agency, Multilateral Joint Research: Ronin Bridge incident, 2022.
2. Binance announcement on Ronin bridge breach and reimbursement, 6 April 2022.
3. Nomad, Bridge Hack: Root Cause Analysis, 5 August 2022.
4. Mandiant, Dissecting the Nomad Bridge Hack, 29 November 2022.
5. SoK: Not Quite Water Under the Bridge: Review of Cross-Chain Bridge Hacks, 28 October 2022.
6. X. Wang et al., zkBridge, ACM CCS 2022.