Перейти к содержанию
Financial Context Wiki

Канонический мост

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

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

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

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

1
Заблокировать или сжечь

Контракт цепочки источников депонирует или уничтожает представление источника.

Как это работает

  1. Зафиксируйте снимок маршрута: chainId источника и назначения, направление, стек и версию rollup, адреса моста, портала, мессенджера, inbox или gateway, адреса токенов, получателя, сумму, ссылки на блоки и официальную документацию. Не полагайтесь только на результат поиска или слово «официальный».
  2. Определите модель безопасности и управления. Запишите правила optimistic fault proof или validity proof, режим доступности данных, секвенсор и принудительный путь, реализацию прокси, администратора или совет безопасности, timelock, состояние паузы, лимиты и задержку обновления. Канонический не значит неизменяемый.
  3. Классифицируйте реестр актива. Отличайте нативную стоимость от ERC-20 и определите схему: блокировка и выпуск, сжигание и возврат либо сжигание и выпуск. Проверьте зарегистрированную пару токенов, сырые единицы, десятичность, специальный gateway и поддержку токенов с комиссией за перевод, ребейзингом или denylist.
  4. Постройте зависящую от направления машину состояний сообщения. Депозит может пройти разрешение, блокировку или сжигание в источнике, финальность источника, derivation или relay и выпуск либо разблокировку в назначении. Вывод может требовать сжигания или блокировки в назначении, включения сообщения, обязательства состояния, доказательства, оспаривания или принятия доказательства, финализации и возврата в источнике.
  5. Отслеживайте три времени отдельно: включение транзакции, расчёт протокола или финальность состояния и доступность актива для использования либо вывода. Запишите хеш исходной транзакции, хеш сообщения или вывода, ссылку на output или proof и каждую транзакцию relay, prove, finalize, claim, retry или refund.
  6. Постройте экономический реестр. Разделите переводимый номинал, gas источника и назначения, gas доказательства или финализации, комиссию протокола или ретранслятора, комиссию поставщика ликвидности, проскальзывание и альтернативную стоимость ожидания. Сравнивайте быстрый и канонический маршруты как разные требования и модели доверия.
  7. Сверьте завершённый маршрут с квитанциями, событиями, балансом эскроу, предложением представления, ожидающими требованиями, балансом получателя и остаточными разрешениями. Дождитесь требуемой финальности, сохраните gas на экстренный случай, протестируйте permissionless или forced path, где они предусмотрены, и не повторяйте депозит с непонятным состоянием сообщения.

Разобранные примеры

  • Реестр депозита нативного актива. Пользователь начинает с 5.0000 ETH, вносит 2.5000 ETH и платит 0.0042 ETH gas в исходной сети. Исходный кошелёк заканчивает с 5.0000 - 2.5000 - 0.0042 = 2.4958 ETH; эскроу увеличивается на 2.5000 ETH; после успешного relay один к одному представление в назначении растёт на 2.5000 ETH. Коэффициент обеспечения равен 2.5000 / 2.5000 = 100%. Эскроу и представление — обеспечение и требование, а не 5 ETH новой экономической стоимости.
  • Сырые единицы и соответствие токенов. Пользователь вносит 1,250.000000 USDC. Проверенный исходный контракт использует 6 decimals, поэтому сырая сумма равна 1,250 * 10^6 = 1,250,000,000. При проверенном соответствии один к одному без комиссии токена эскроу источника и выпуск назначения изменяются на 1,250,000,000 raw units, отображая 1,250.000000 USDC удалённо. Токен с тем же символом по другому адресу не является равноценным доказательством.
  • Временные этапы вывода различаются. Пусть система регистрирует вывод в 2026-08-01 12:00:00 UTC и применяет период оспаривания 604,800-second = 7-day от определённого протоколом начала. Временной порог наступит в 2026-08-08 12:00:00 UTC; транзакция prove или finalize, gas и выбранная политика подтверждений источника могут добавить время. Этот параметризованный пример не утверждает, что любой мост ждёт семь дней; финальность транзакции назначения сама не освобождает средства источника.
  • Котировка быстрого маршрута и стоимость ожидания. Для 10,000 USDC быстрый мост берёт 0.08% плюс 3 USDC, без учёта gas и проскальзывания. Стоимость равна 10,000 * 0.0008 + 3 = 11 USDC, немедленное поступление — 9,989 USDC. Относительно гипотетического канонического ожидания 7-day простая годовая цена раннего доступа равна (11 / 9,989) * (365 / 7) = 5.7420305193%. Это не доходность и не безрисковая ставка; сравнение исключает риски исполнителя, ликвидности, дефолта и расчётов.

Риски

  • Фишинговый интерфейс или непроверенный домен документации.
  • Неверная исходная или целевая сеть и chainId.
  • Отправка поддельному мосту, порталу, мессенджеру, gateway или получателю.
  • Токен с тем же символом, но неверным зарегистрированным соответствием.
  • Ошибка в десятичности, сырых единицах или нестандартном поведении токена.
  • Смешение нативного актива, обёрнутого gas-токена и мостового представления.
  • Избыточное разрешение или одобрение неверного spender.
  • Обновление прокси, компрометация администратора, решение совета или изменение timelock.
  • Пауза, denylist, rate limit или замороженный маршрут вывода.
  • Принятие квитанции источника за доказательство исполнения в назначении.
  • Недостаток gas для исполнения, retry, prove, claim или refund.
  • Истечение retry, неверный refund или aliasing адреса.
  • Реорганизация исходной сети или недостаточная финальность.
  • Цензурирующий либо недоступный секвенсор без работающего forced path.
  • Недоступность данных, необходимых для доказательства, восстановления или выхода.
  • Неверный корень состояния, proof сообщения, nullifier или условие повтора.
  • Недоступные proposer, prover, challenger или permissioned finalizer.
  • Неверное прочтение challenge, maturity или proof-acceptance после обновления.
  • Неплатёжеспособность эскроу, ошибка учёта, depeg или неликвидность назначения.
  • Риски fast bridge, агрегатора, верификатора, LP, solver, проскальзывания, налогов и санкций.

Распространённые заблуждения

  • Канонический — универсальный стандарт и автоматически означает отсутствие доверия или риска.
  • Успешная исходная транзакция или баланс в интерфейсе доказывает окончательный расчёт.
  • Любой вывод из rollup имеет одинаковое семидневное ожидание.
  • Эскроу источника и представления назначения можно складывать как независимый TVL.
  • Быстрый мост — тот же канонический мост с настройкой скорости.

Связанные темы

Источники

Навигация

Поиск по вики...