Кроссчейн мост: какой протокол выбрать под ваши задачи

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

Ошибочный выбор обычно начинается с сортировки по комиссии. Это слабый фильтр. Разница в несколько долларов по fee не компенсирует экспозицию к bridge contract, мультисигу, оракулу, RPC-инфраструктуре или стороннему роутеру. Кроссчейн мост нужно выбирать от задачи и типа актива, а не от позиции в выдаче агрегатора.

Четыре модели: что именно происходит с активом

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

Lock-and-mint: максимальная распространённость, максимальная цена ошибки

Lock-and-mint — классическая мостовая архитектура. Пользователь депонирует ETH, USDC или иной актив в контракте сети A. После подтверждения события в сети B появляется wrapped-версия. Для обратного перевода wrapped-токен сжигается, а исходный актив разблокируется.

Так работает значительная часть ранней мостовой инфраструктуры, включая маршруты, использующие модель Wormhole. Преимущество очевидно: система может соединять сети с разной архитектурой и не требует, чтобы оригинальный эмитент токена поддерживал каждую из них.

Недостаток измеряется концентрацией риска. Контракт в исходной сети становится хранилищем. Чем больше TVL, тем выше экономический стимул атаковать верификационный контур. В 2022 году взлом Wormhole привёл к выпуску необеспеченного эквивалента 120 000 wETH. Это не сбой интерфейса и не «неудачная транзакция». Это пример того, как ошибка в доказательстве или валидации превращается в дефицит обеспечения.

У wrapped-актива есть отдельный риск ликвидности. Формально 1 wETH может быть привязан к ETH. Практически его цена зависит от возможности погашения, состояния моста, глубины пулов и готовности маркетмейкеров держать экспозицию. В момент bridge-инцидента спред между оригиналом и обёрткой способен расширяться быстрее, чем пользователь успевает завершить обратный маршрут.

Burn-and-mint: меньше обёрток, но не нулевой риск

В модели burn-and-mint токен не лежит в lockbox. Он уничтожается в одной сети и создаётся в другой. Для стейблкоинов эта логика выглядит чище: пользователь получает не мостовую обёртку USDC, а нативный USDC, выпущенный по механизму эмитента.

Типовой пример — Circle CCTP. Для маршрутов USDC это снижает несколько классов риска:

• нет отдельного wrapped-USDC с собственной ликвидностью и peg-риском;
• нет постоянного пула заблокированного USDC, который становится единственной целью атаки;
• унифицируется актив в нескольких сетях, что сокращает фрагментацию ликвидности.

Но перенос доверия не равен устранению доверия. Пользователь зависит от системы attestation, корректности сжигания, выпуска и операционной доступности эмитента. Финальность операции также определяется не только блокчейном: есть задержки на подтверждения и обработку сообщений.

Burn-and-mint рационален, когда задача узкая: перевести поддерживаемый нативный актив между поддерживаемыми сетями. Для произвольного ERC-20 этот подход обычно неприменим. Универсальность здесь ниже, чем у lock-and-mint, а поверхность риска — уже.

Нативный актив в целевой сети снижает риск обёртки. Он не отменяет риск канала сообщения между сетями.

Liquidity network: быстрый обмен вместо буквального переноса

Сети ликвидности — это Stargate, Celer cBridge и аналогичные конструкции. Пользователь отправляет актив в контракт или пул в сети A. В сети B он получает ликвидность из другого пула. Экономически это ближе к кроссчейн-расчёту, чем к перемещению одного и того же токена через границу.

Преимущество — UX. В удачных маршрутах пользователь получает актив быстро, без серии промежуточных wrapped-токенов. На ликвидных направлениях это часто уменьшает итоговый проскальзывающий расход по сравнению со связкой bridge + swap.

Однако «быстро» не равно «безопасно». Здесь добавляются новые переменные:

• объём доступной ликвидности в сети назначения;
• дисбаланс пулов и стоимость ребалансировки;
• риск контракта пула;
• риск сети верификаторов или State Guardian Network;
• девиация фактического курса от заявленного из-за price impact и комиссий.

Если в пуле назначения недостаточно USDT или ETH, транзакция может стать дорогой, задержаться либо получить неэффективный маршрут. В интерфейсе это иногда маскируется одной строкой «estimated received». Для крупного объёма этой оценки недостаточно: нужен расчёт итогового исполнения после protocol fee, LP fee, gas и возможного swap на стороне destination chain.

Stargate после приобретения LayerZero Labs за $110 млн в августе 2025 года остаётся важным элементом инфраструктуры ликвидности. Но корпоративная или продуктовая интеграция не является гарантийным сертификатом. При выборе маршрута анализируется текущая архитектура, а не бренд и не история сделки.

Intent-based: пользователь фиксирует результат, исполнение отдаёт рынку solver'ов

Intent-based мосты — Across, deBridge, Relay и близкие по логике решения — меняют порядок процесса. Пользователь не строит маршрут вручную. Он формулирует условия: какой актив, в какой сети, какой минимальный объём получить, какой deadline допустим. Solver или relayer исполняет intent и затем получает компенсацию через settlement layer.

Это эффективная модель для розничных и средних переводов, особенно если нужна не только доставка актива, но и swap в конечной сети. Вместо пяти транзакций пользователь получает одну заявку. Вместо ручного выбора между bridge, DEX и gas-token — единое исполнение.

Плата за сокращение действий — рост значимости исполнения. Нужно различать:

1. Риск протокола settlement. Кто и как подтверждает, что solver действительно исполнил обязательство.

2. Риск котировки. Minimum received защищает от худшего исхода, но не делает quoted price рыночным.

3. Риск solver. Конкуренция между исполнителями может сужать спред, но не исключает задержку при перегрузке или дефиците ликвидности.

4. Риск зависимостей. Intent-протокол часто опирается на оракулы, мостовой слой, внешние контракты и сеть relayer'ов.

Для пользователя intent-based модель обычно даёт лучший UX. Для аналитика она требует больше декомпозиции. Нельзя оценить безопасность только по названию фронтенда: нужно видеть, какой settlement layer, какой bridge и какой источник ликвидности скрыты за маршрутом.

Почему мосты остаются главной целью для эксплойтов

Мост соединяет два независимых консенсуса. Это его функция и его уязвимость. Внутри одной сети валидность транзакции проверяет базовый протокол. Между сетями появляется внешний слой, который должен доказать: событие в chain A действительно произошло, оно финально и его можно отразить в chain B.

Если этот слой ошибается, атакующий получает возможность создать актив без эквивалентного обеспечения или разблокировать депозит без корректного погашения. Экономика атаки проста: TVL моста концентрирован, а успешный exploit не ограничен балансом одного пользователя.

Основные классы отказа выглядят так:

Мосты с консенсусной моделью зависят от порога честных участников. У Wormhole это сеть Guardians. У Celer cBridge — State Guardian Network. Децентрализация набора не должна оцениваться по числу логотипов. Значимы threshold, распределение ключей, независимость операторов, процедура ротации, публичность подписей и возможность аварийной остановки.

Мультисиг 1-of-1 не является децентрализацией. Это одиночный ключ с интерфейсом моста. Даже если вокруг него построена сложная маркетинговая схема.

Инциденты 2026 года: три разных точки отказа

Серия атак 2026 года полезна не суммами, а разнообразием причин. Один и тот же итог — утрата обеспечения — возникал на разных уровнях стека.

18 апреля Kelp DAO потерял около $292 млн, или 116 500 rsETH. Вектором стала компрометация инфраструктуры RPC-узлов и конфигурация с одним верификатором в связке с LayerZero. Здесь критична не абстрактная формула «мост взломан», а конкретная цепочка: инфраструктурная зависимость плюс 1-of-1 верификация создали единичную точку отказа.

30 мая Gravity Bridge потерял $5,4 млн, включая $4,3 млн USDC и 274 ETH. Причина — компрометация приватного ключа подписи. Сумма меньше Kelp DAO почти на два порядка, но модель риска та же: приватный ключ обладает экономической властью над активами, превышающей стоимость его защиты.

В июне Syscoin Bridge потерял около $10 млн из-за уязвимости в валидации SPV-доказательств. Это другой класс дефекта. Ключ не нужно было красть, инфраструктуру — компрометировать. Достаточно, чтобы контракт неверно интерпретировал криптографическое доказательство.

Из этих трёх кейсов следует жёсткий вывод. Аудит кода не покрывает операционный риск ключей. Мультисиг не покрывает ошибку в proof verification. Репутация протокола не покрывает слабую конфигурацию конкретной интеграции.

Мост — это не один смарт-контракт. Это граф зависимостей: код, ключи, валидаторы, RPC, оракулы, пулы и процедура обновления.

Агрегатор выбирает цену, но не принимает риск вместо пользователя

Jumper на базе LI.FI, Bungee через Socket и другие агрегаторы полезны как слой маршрутизации. Они сопоставляют доступные мосты, DEX и сети, показывают estimated time, комиссию и ожидаемый объём на выходе. Для мелких и средних переводов это сокращает число ручных операций и уменьшает вероятность пользовательской ошибки.

Но агрегатор не создаёт отдельный защищённый канал. Если маршрут проложен через базовый bridge с риском валидаторского кворума, экспозиция сохраняется. Если агрегатор добавляет swap, появляется риск DEX-пула и price impact. Если маршрут разбит на несколько hops, итоговая надёжность снижается с каждым дополнительным контрактом.

Каждый лишний hop — это ещё один смарт-контракт, ещё одна зависимость от внешнего оракула или relayer'а, ещё одна точка, где что-то может пойти не так. Сложность растёт быстрее, чем длина цепочки: чем больше этапов, тем больше связей между ними, тем выше риск коррелированного отказа. Если несколько маршрутов делят общий messaging layer или один settlement contract, диверсификация, которую обещает интерфейс агрегатора, оказывается иллюзией — за разными логотипами стоит одна и та же зависимость.

При сравнении маршрутов агрегатора я смотрю не на первую строку с fee, а на следующие параметры:

• какой именно bridge исполняет перевод и какая у него модель: mint, liquidity или intent;
• получает ли адресат нативный актив или wrapped-представление;
• сколько контрактов участвует в маршруте, включая DEX-swap;
• есть ли approval на неограниченную сумму и можно ли заменить его точным лимитом;
• какой minimum received зафиксирован до подписи;
• есть ли зависимость от внешнего solver или централизованного relayer;
• что произойдёт, если destination-транзакция не будет доставлена в ожидаемое время.

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

Как выбрать кроссчейн мост под сумму и сценарий

Рациональная стратегия начинается с разделения переводов на операционные и капитальные. Операционный перевод — пополнение L2 для торговли, оплата gas, вход в dApp, ребалансировка небольшой позиции. Капитальный — перевод стейблкоинов, ETH, LST или collateral, где потеря или зависание заметно меняют риск-профиль портфеля.

Для первого сценария допустима оптимизация UX. Для второго приоритет меняется: меньше посредников, более прозрачная модель доверия, дробление суммы и проверка маршрута тестовой транзакцией.

Если переводится нативный USDC

Сначала нужно установить, поддерживает ли выбранная пара сетей burn-and-mint через CCTP или аналогичный механизм нативного выпуска. Если поддерживает, эта схема обычно снижает риск bridge-wrapped токена и упрощает дальнейшую работу в DeFi.

Дальше оцениваются задержка, итоговая стоимость и необходимость промежуточного swap. Если агрегатор предлагает на $2 дешевле маршрут через несколько контрактов с обёрнутым USDC, экономия должна быть сопоставлена с дополнительной сложностью. Для крупной суммы этот trade-off обычно решается не в пользу самого дешёвого пути.

Если нужен ETH, WBTC или произвольный ERC-20

Здесь выбор часто сводится к lock-and-mint, liquidity network или intent-based исполнению. Нельзя автоматически считать wrapped-версию эквивалентом оригинала. Нужно проверить, принимают ли её целевые dApps, есть ли ликвидные пулы, насколько стабилен peg и возможен ли обратный выкуп.

Для collateral в lending-протоколах особенно опасны активы с несколькими конкурирующими обёртками. Один и тот же тикер может обозначать разные контракты и разные мостовые риски. Ликвидность на DEX не компенсирует отсутствие канонического погашения.

Если задача — быстро получить актив в целевой сети

Intent-based и liquidity network обычно дают более короткий пользовательский путь. Но короткий UX не равен короткой технической цепочке. Перед подтверждением фиксируются:

1. Точный токен на выходе и его адрес контракта в destination chain.

2. Minimum received, а не только оптимистичный estimate.

3. Время исполнения и действие протокола при истечении deadline.

4. Наличие промежуточного swap и его допустимый slippage.

5. Размер approve: точный объём перевода вместо unlimited allowance.

Для тестового объёма допустим маршрут через агрегатор. Для крупной экспозиции сначала проводится минимальная транзакция, затем повторяется маршрут без изменения параметров. Это не защита от эксплойта. Это защита от ошибок сети, неверного токена, некорректного recipient и скрытого swap.

Если средства идут в DeFi-позицию

Здесь мост нельзя анализировать отдельно от конечного протокола. Перевод ETH в сеть назначения ради ликвидного стейкинга, lending или LP создаёт последовательную экспозицию: bridge risk + smart-contract risk целевого dApp + рыночный риск позиции.

Если актив после моста используется как залог, добавляется риск ликвидации. Если это LST или LRT — риск девиации к базовому ETH. Если маршрут проходит через кроссчейн swap — риск проскальзывания. Суммарный риск не складывается в интерфейсе, но складывается в балансе.

Поэтому для значимой DeFi-позиции перевод лучше разбивать на две фазы. Сначала актив доставляется в destination chain через минимально возможное число контрактов. Отдельно, уже после зачисления, оценивается целевой протокол: его аудиты, история эксплойтов, TVL, поведение в стрессовых условиях рынка и качество oracle-инфраструктуры. Связка «bridge + dApp» обычно надёжнее, когда каждое звено проверено по отдельности, а не когда доверие выдаётся сразу обеим системам только потому, что у них красивые лендинги.

Стратегия оценки безопасности перед переводом

Перед подтверждением транзакции я держусь простого внутреннего порядка. Сначала — тип актива и канонический адрес в каждой из сетей. Затем — модель моста и кто несёт финальную ответственность за верификацию: эмитент, набор валидаторов, оракул, relayer. Дальше — история инцидентов именно этого протокола, а не «команды» или «венчурных инвесторов». После этого — текущий TVL, давность последних аудитов и активность bug bounty.

Отдельно проверяются операционные мелочи: адрес контракта назначения в обозревателе destination chain, корректность сети в кошельке, отзыв старых approvals через revoke-сервис. Эти шаги выглядят рутинными, но именно они закрывают самый частый класс потерь — пользовательскую ошибку, а не смарт-контракт.

Финальный фильтр — размер суммы. Если перевод крупный, он дробится, маршрут сначала тестируется минимальной транзакцией, и только потом повторяется с рабочим объёмом. Это не панацея от эксплойта, но это способ отделить реальную техническую проблему маршрута от собственной опечатки в адресе.

Выбора «идеального» кроссчейн моста не существует. Существует набор осознанных компромиссов между нативностью актива, длиной цепочки доверия, прозрачностью settlement layer и стоимостью маршрута. Чем крупнее сумма и чем дольше актив будет находиться в целевой сети, тем жёстче должны быть эти компромиссы. Доллар разницы в комиссии перестаёт иметь значение, когда за ним стоит ключ от $300 млн.