---
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.
# Межсетевой мост
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Межсетевой мост — система, в которой наблюдаемый в одном домене исполнения перевод актива или сообщение приводит к авторизованному результату в другом. Независимые сети не доверяют состоянию друг друга автоматически. Поэтому маршруту нужны модель верификации и правила исполнения в сети назначения, а для актива также модель выпуска, хранения или ликвидности.
Эти измерения следует разделять. Актив может идти по схеме блокировки и выпуска, сжигания и разблокировки, сжигания и выпуска эмитентом или доставки поставщиком ликвидности. Сообщение может приниматься по лёгкому клиенту или доказательству корректности, после оптимистического периода оспаривания, по аттестации или порогу валидаторов либо специальным верификатором приложения. У каждой комбинации свои риски финальности, повтора, обновления, доступности и платёжеспособности. Транзакция источника, аттестация, баланс назначения и экономическое погашение — разные состояния.
## Как это работает
1. Зафиксируйте снимок маршрута: протокол и версию, `chainId` или домен источника и назначения, адреса шлюза, маршрутизатора, мессенджера или адаптера, пару токенов, получателя, сумму, десятичность, срок, ссылки на блоки и официальную документацию. Название, значок или метка агрегатора не являются идентификатором.
2. Классифицируйте два независимых измерения. Укажите, использует ли актив блокировку и выпуск, сжигание и разблокировку, сжигание и выпуск эмитентом либо доставку ликвидности; а сообщение — доказательство консенсуса, лёгкий клиент, оптимистическую проверку, аттестацию, порог валидаторов или иной верификатор.
3. Составьте карту корней доверия и управления: финальность источника, доступность данных, допущения доказательства или аттестатора, исполнитель назначения, защита от повтора, реализация прокси, администратор или совет безопасности, задержка обновления, пауза и лимиты. Слова «канонический», «официальный», «аудированный» или «основанный на доказательстве» сами по себе не определяют риск.
4. Постройте направленный автомат состояний сообщения: отправка в источнике, включение и требуемая финальность; ID сообщения, nonce или sequence; доказательство или аттестация; ретрансляция; исполнение в назначении; подтверждение; повторная попытка, тайм-аут, возврат или получение. Пути депозита и вывода могут быть асимметричны.
5. Постройте реестры актива и сообщения в сырых единицах. Сверьте допустимый эскроу, обращающееся представление, заблокированные, но ещё не выпущенные требования, сожжённые, но ещё не разблокированные требования, выпуски и сжигания эмитента, использованные ID сообщений и оставшиеся разрешения. Не считайте эскроу и его представление двумя независимыми активами.
6. Постройте исполнимый экономический реестр. Отделяйте основной объём токена и комиссию протокола от газа источника и назначения, комиссии ретранслятора или поставщика ликвидности, заявленной ёмкости, минимального выхода, проскальзывания, влияния на цену и стоимости ожидания. Котировка не равна исполнению, а газ в нативном токене не вычитается автоматически из результата в переводимом токене.
7. Сверьте маршрут по фактическим доказательствам: квитанции источника и финальному блоку, состоянию сообщения или пакета, результату верификатора, квитанции назначения и изменениям состояния, точному контракту полученного токена, балансу, погашаемости и ликвидности. Отзовите лишние полномочия, сохраните газ для восстановления и не повторяйте необъяснимый перевод.
## Примеры с расчётами
- **Обеспечение с требованиями в пути.** Допустимый эскроу равен `10,000 units`; обращающееся представление в сети назначения — `9,700 units`; заблокированные, но не выпущенные требования — `200 units`; сожжённые, но не разблокированные — `100 units`. Экономические требования равны `9,700 + 200 + 100 = 10,000 units`, поэтому скорректированное покрытие — `10,000 / 10,000 = 100.0000000000%`. Деление только на обращающийся объём ложно показывает `10,000 / 9,700 = 103.0927835052%`. Покрытие не доказывает безопасность контрактов или мгновенную ликвидность.
- **Выход токена и экономическая стоимость.** Пользователь отправляет `5,000 USDC`; удерживается комиссия протокола `5 USDC`, поэтому баланс назначения увеличивается на `4,995 USDC`. Газ источника — `0.003 ETH`, газ получения в назначении — `0.001 ETH`; при явно заданных `2,000 USD/ETH` отдельные денежные потоки стоят `$6` и `$2`. Общая экономическая стоимость — `$5 + $6 + $2 = $13`, чистое полученное состояние — `$4,987`, но баланс назначения остаётся `4,995 USDC`.
- **Компрометация порога и дефицит резерва.** У гипотетического аттестационного моста `3-of-5` есть эскроу `$5,000,000` и `5,000,000` законных обёрнутых единиц. Если три уполномоченных ключа подделают необеспеченный выпуск `1,000,000-unit`, предложение станет `6,000,000`, дефицит — `$1,000,000`, а пропорциональное покрытие — `5,000,000 / 6,000,000 = 83.3333333333%`, или `$0.8333333333` резерва на токен. Это бухгалтерский результат, а не гарантированная рыночная цена или цена восстановления.
- **Ёмкость маршрута ликвидности.** Запрос равен `100,000 units`. У маршрута A ёмкость `60,000` и комиссия `0.20%`, поэтому он доставляет `60,000 * (1 - 0.002) = 59,880 units`. Независимый маршрут B обрабатывает `40,000` с комиссией `0.35%` плюс `20 units`, доставляя `40,000 * (1 - 0.0035) - 20 = 39,840 units`. Общий выход — `99,720 units`, стоимость — `280 units`, или `280 / 100,000 = 0.2800000000%`. Допущения безопасности у маршрутов разные, а частичное исполнение существует лишь тогда, когда его допускает реальный протокол и подтверждают квитанции.
## Риски
- Выбор неправильного источника, назначения, `chainId` или домена.
- Использование фишингового интерфейса, сайта документации или агрегатора.
- Отправка через поддельный шлюз, маршрутизатор, мессенджер или адаптер.
- Выбор неверной пары токенов, получателя или одноимённого представления.
- Ошибка в десятичности, сырых единицах, комиссии при переводе или ребейзинге.
- Сохранение избыточного approval, permit или полномочий оператора.
- Опора на исходную транзакцию до достаточной финальности или после реорганизации.
- Доверие скомпрометированным ключам, валидаторам, аттестаторам или членам порога.
- Принятие дефектного лёгкого клиента, верификатора доказательств или споров.
- Допущение повтора, двойного выпуска, ошибок sequence, порядка или идемпотентности.
- Восприятие успеха источника как доказательства исполнения назначения.
- Недостаток газа для исполнения, повторной попытки, получения или возврата.
- Зависимость от недоступного ретранслятора, доказателя, аттестатора или исполнителя.
- Потеря доступности из-за цензуры секвенсора или недоступности данных.
- Пропуск обновления, смены администратора, паузы, лимита или обхода задержки.
- Игнорирование неплатёжеспособности эскроу, общих резервов или дрейфа учёта.
- Предположение о совместимости нестандартных хуков токена с мостом.
- Превышение ёмкости ликвидности или опора на устаревшую котировку и ребалансировку.
- Депег, проскальзывание, MEV или непригодный маршрут погашения.
- Неверное понимание тайм-аута, возврата, восстановления, налогов, санкций или хранения.
## Распространённые заблуждения
- Одна и та же монета физически перемещается между блокчейнами.
- Канонический, официальный, аудированный или основанный на доказательстве мост автоматически лишён риска.
- Успешная исходная транзакция гарантирует зачисление и финальный расчёт в назначении.
- Обеспечение один к одному гарантирует немедленное погашение и рыночную ликвидность один к одному.
- Быстрый мост — это тот же расчётный маршрут, работающий быстрее.
## Связанные темы
- [Канонический мост](/ru/crypto/canonical-bridge/)
- [Проверка токена после моста](/ru/crypto/bridge-token-verification/)
- [Риск доступности межсетевого ретранслятора](/ru/crypto/bridge-relayer-liveness-risk/)
## Источники
- [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)
- [Messengers](https://specs.optimism.io/protocol/messengers.html) - OP Stack Specification (дата обращения: 2026-08-12)
- [CCTP technical guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Docs (дата обращения: 2026-08-12)
- [ICS-4: Channel and Packet Semantics](https://github.com/cosmos/ibc/blob/main/spec/core/ics-004-channel-and-packet-semantics/README.md) - Inter-Blockchain Communication Protocol (дата обращения: 2026-08-12)
- [ERC-5164: Cross-Chain Execution](https://eips.ethereum.org/EIPS/eip-5164) - Ethereum Improvement Proposals (дата обращения: 2026-08-12)
- [ERC-7786: Cross-Chain Messaging Gateway](https://eips.ethereum.org/EIPS/eip-7786) - Ethereum Improvement Proposals (дата обращения: 2026-08-12)
- [CCIP Concepts](https://docs.chain.link/ccip/concepts) - Chainlink Documentation (дата обращения: 2026-08-12)
Source: https://wiki.fcontext.com/ru/crypto/cross-chain-bridge/index.mdx