---
title: "Канонический мост"
description: "Ориентированное на проверку руководство по назначенным протоколом мостам, обеспечению активов, состояниям междоменных сообщений, выводам с доказательствами ошибок и валидности, управлению обновлениями, комиссиям и сравнению с быстрыми мостами."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Канонический мост
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Канонический мост — маршрут активов или сообщений, назначенный конкретной экосистемой rollup или сети. Обычно он связывает контракты, которые блокируют или сжигают актив в одной сети, передают признанное протоколом сообщение и выпускают, разблокируют либо возвращают соответствующий актив в другой. Слово «канонический» — метка экосистемы, а не универсальный стандарт, криптографическая гарантия или доказательство подлинности сайта и адреса.
Его безопасность нельзя выразить аддитивной формулой. Она совместно зависит от финальности исходной сети, доступности данных, проверки состояния или сообщения, учёта моста, исполнения в целевой сети, защиты от повтора, полномочий обновления и паузы и работоспособного пути выхода. Быстрый мост может раньше выплатить пользователю средства из ликвидности и позднее рассчитаться по каноническому маршруту, но при этом добавляет допущения о поставщике ликвидности, исполнителе, верификаторе и исполнении, а не бесплатно ускоряет ту же машину состояний.
## Как это работает
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.
- Быстрый мост — тот же канонический мост с настройкой скорости.
## Связанные темы
- [Межсетевой мост](/ru/crypto/cross-chain-bridge/)
- [Rollup](/ru/crypto/rollup/)
- [Аварийный выход из rollup](/ru/crypto/rollup-escape-hatch/)
## Источники
- [Bridges](https://ethereum.org/developers/docs/bridges/) - Ethereum.org (дата обращения: 2026-08-12)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (дата обращения: 2026-08-12)
- [Withdrawals](https://specs.optimism.io/protocol/withdrawals.html) - OP Stack Specification (дата обращения: 2026-08-12)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (дата обращения: 2026-08-12)
- [L1 to L2 messaging](https://docs.starknet.io/learn/protocol/messaging) - Starknet Documentation (дата обращения: 2026-08-12)
- [StarkGate](https://docs.starknet.io/learn/protocol/starkgate) - Starknet Documentation (дата обращения: 2026-08-12)
- [Bridging assets](https://docs.zksync.io/zksync-protocol/rollup/bridging-assets) - ZKsync Docs (дата обращения: 2026-08-12)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (дата обращения: 2026-08-12)
Source: https://wiki.fcontext.com/ru/crypto/canonical-bridge/index.mdx