Мосту недостаточно увидеть, что пользователь нажал кнопку в одной сети. Контракт назначения должен получить сообщение и решить, можно ли считать событие исходной сети настоящим и окончательным. Light-client bridge и multisig bridge отвечают на этот вопрос по-разному: первый проверяет заголовки и доказательства по правилам консенсуса, второй принимает подписи заранее выбранной группы участников.
Разница относится прежде всего к проверке межсетевого сообщения. Выпуск обёрнутого токена, разблокировка резерва и расчёт комиссии происходят отдельными слоями. Поэтому одинаковый интерфейс перевода может скрывать совершенно разные допущения доверия. Общую связь сообщений и активов объясняет материал о межсетевых сообщениях и token bridge.
Что именно должен доказать мост
Представим депозит токена в сети A. Контракт блокирует актив и записывает событие: кто внёс средства, сколько, в какой сети и кому их выдать. Чтобы исполнить соответствующее действие в сети B, мост должен подтвердить несколько фактов. Транзакция действительно вошла в блок, блок принадлежит принятой цепочке, состояние достигло требуемой финальности, а переданное сообщение совпадает с записанными данными.
На последнем шаге контракт назначения обычно проверяет доказательство включения сообщения в состояние исходной сети. Но сам корень этого состояния тоже нужно признать достоверным. Именно здесь расходятся модели. Light client выводит доверие из проверяемых правил исходного консенсуса. Multisig заменяет сложную onchain-проверку пороговым свидетельством операторов.
Ни одна схема автоматически не делает правильным контракт, который выпускает токены. Ошибка в обработке nonce, повторное исполнение сообщения, неверный decimal или уязвимое обновление способны привести к потере средств при корректной проверке исходной сети. Аудит модели моста должен охватывать и верификатор, и конечное приложение.
Как работает light-client bridge
Light client хранит в целевой сети компактное представление состояния другой цепочки. Обновления передают заголовки блоков, подписи или иные данные консенсуса. Контракт проверяет их по формальным правилам протокола и обновляет доверенное состояние. После этого relayer может принести доказательство того, что нужное сообщение входит в конкретный подтверждённый корень.
Relayer в такой схеме доставляет данные, но не обязан быть доверенным судьёй. Если доказательство неверно, контракт должен его отклонить. Это позволяет любому участнику продолжить доставку сообщений, пока он способен сформировать корректный пакет. В IBC похожий принцип реализован через клиенты, которые отслеживают консенсусное состояние другой цепочки и проверяют доказательства относительно него.
Цена независимой проверки – сложность и расход gas. Целевая сеть должна уметь эффективно проверить подписи, комитет или правила финальности исходной сети. Изменение формата блоков либо механизма консенсуса требует совместимого обновления клиента. Если обновления состояния перестали поступать, мост может остановиться, хотя активы исходной сети остаются целы.
Light client также не устраняет риски самой исходной цепочки. Если её консенсус принял ошибочное состояние или необходимая доля валидаторов нарушила правила, клиент честно подтвердит то, что считает окончательным исходный протокол. Уязвимость в реализации клиента опасна не меньше компрометации внешнего комитета.
Как работает multisig bridge
В multisig-модели группа наблюдателей следит за исходными сетями вне целевого контракта. Участники подписывают сообщение о зафиксированном событии, а контракт назначения считает его действительным после достижения порога. Например, Wormhole формирует VAA – пакет сообщения с подписями Guardians, который затем проверяется принимающим контрактом.
Такая конструкция проще переносится между сетями с разными виртуальными машинами и консенсусом. Целевой контракт проверяет стандартные подписи и порог, вместо полной логики чужого протокола. Это может снизить стоимость сообщения и ускорить поддержку новых сетей.
Однако безопасность теперь зависит от состава подписантов, хранения ключей, независимости инфраструктуры и выбранного порога. Достаточная коалиция может подтвердить несуществующий депозит. Потеря или отключение слишком многих ключей остановит выпуск сообщений. Если те же лица управляют обновлением контрактов, набор доверенных полномочий становится ещё шире.
Слово multisig не описывает качество системы целиком. Нужно знать число подписантов, порог, географию и программное разнообразие узлов, процедуру замены ключей, timelock и возможность аварийной паузы. Для самостоятельной проверки пригодится руководство по владельцам и порогу multisig.
Главные различия моделей
- Источник истины. Light client опирается на правила консенсуса и проверяемые доказательства. Multisig опирается на согласие пороговой группы.
- Доставка. В light-client схеме relayer обычно не может подделать сообщение, но способен задержать доставку. В multisig подписи являются частью самого решения о достоверности.
- Стоимость. Проверка заголовков и криптографических доказательств может быть дорогой. Проверка набора обычных подписей часто проще, но переносит риск во внешний комитет.
- Обновления. Light client должен следовать изменениям исходного протокола. Multisig легче адаптировать, но обновляемость повышает значение admin-ключей.
- Отказ. У первой модели типичны устаревшее состояние и ошибка верификатора. У второй – сговор, компрометация ключей или потеря кворума.
Иногда мост сочетает механизмы: комитет ускоряет сообщение, light client или optimistic-проверка даёт окончательное подтверждение, а лимиты ограничивают ущерб. Гибрид нельзя оценивать по одному ярлыку. Следует выяснить, какой путь используется именно для выбранного актива и можно ли обойти более строгую проверку.
Как выбирать маршрут пользователю
Начните с того, какой контракт хранит резерв и кто может выпустить представление токена в другой сети. Затем найдите описание верификатора, порога финальности и аварийных полномочий. Если документация говорит только о скорости, но не объясняет, кто подтверждает сообщения, модель доверия остаётся непрозрачной.
Проверьте лимиты, паузы, timelock и историю обновлений. Инструкцию по таким ролям даёт статья о timelock и emergency pause. Для практического перевода дополнительно сверяйте официальный домен, сеть, токен и получателя по чек-листу безопасной работы с мостом.
Для небольшой суммы удобство и ликвидность могут быть важнее архитектурной чистоты. Для крупной позиции существенны максимальный возможный ущерб, концентрация подписантов, зрелость light client и время восстановления после сбоя. Разделяйте сумму между независимыми маршрутами только тогда, когда они действительно не используют один и тот же комитет или контракт.
Light-client bridge уменьшает необходимость доверять внешним наблюдателям, но требует сложной и корректной onchain-проверки чужого консенсуса. Multisig bridge делает проверку проще и универсальнее, но напрямую доверяет ключам и организационной устойчивости подписантов. Осмысленный выбор начинается не с названия моста, а с ответа на вопрос: какое доказательство заставит целевой контракт выдать активы.
