LayerZero против Chainlink, CCIP против Wormhole: чем на самом деле отличается межсетевая совместимость?

Представьте себе гипотетическое DeFi-приложение под названием Atlas Treasury. Этот пример вымышленный и используется только для упрощения понимания архитектуры. Atlas хранит залог на Ethereum, хочет запускать логику стратегии на другом блокчейне и иногда нуждается в перемещении представления токена вместе с сообщением. Его разработчики рассматривают три широко используемых стека взаимодействия: LayerZero, Chainlink CCIP и Wormhole.

На первый взгляд, все три протокола, кажется, решают одну и ту же проблему: передачу информации или активов из одного блокчейна в другой. На практике это описание слишком поверхностно. Межцепочечный протокол должен ответить на несколько разных вопросов: Кто отслеживает исходный блокчейн? Какие доказательства убеждают целевой блокчейн в действительности сообщения? Кто платит за доставку и выполнение сообщения? Как представлены переводы токенов? Что может настроить приложение, и какие предположения о безопасности остаются в силе?

Начните с проблемы, а не с названия протокола.

Для Atlas Treasury требование типа «поддержка нескольких цепочек» недостаточно конкретно. Команде следует сначала разделить свои потребности как минимум на три категории: произвольная отправка сообщений, перемещение токенов и исполнение транзакций в целевой цепочке.

Произвольная отправка сообщений может означать, например, что контракт Ethereum отправляет инструкцию типа «обновите лимит кредитования для счета X». Перемещение токенов происходит иначе: стоимость должна быть заблокирована, сожжена, выпущена, освобождена или иным образом учтена в разных блокчейнах. Исполнение добавляет еще один уровень, поскольку целевая транзакция требует газа, правил упорядочивания, обработки ошибок и четкого правила для определения того, кто имеет право вызывать принимающий контракт.

Это различие важно, потому что LayerZero, Chainlink CCIP и Wormhole — это не просто взаимозаменяемые мосты. Каждый из них представляет собой более широкую структуру взаимодействия с различной архитектурой проверки и доставки.

LayerZero: проверка и выполнение, настраиваемые приложением.

LayerZero V2 организует межсетевую связь на основе неизменяемых контрактов конечных точек, развернутых в поддерживаемых блокчейнах. Приложение отправляет сообщение через исходную конечную точку, а конечная точка назначения в конечном итоге доставляет проверенное сообщение принимающему приложению. В официальном обзоре протокола LayerZero V2 канал описывается с точки зрения отправителя, идентификатора исходной конечной точки, идентификатора конечной точки назначения и получателя.

Отличительной особенностью проектирования является разделение процессов верификации и выполнения. LayerZero называет свои независимые сервисы верификации децентрализованными сетями верификаторов (DVN). Приложение может настраивать необходимые и необязательные сети DVN, включая пороговые правила, в то время как исполнители обрабатывают доставку сообщения получателю после того, как оно соответствует требованиям верификации. В официальной архитектурной документации это описывается как модель верификации X-из-Y-из-N с подключаемыми библиотеками сообщений, сетями DVN и исполнителями.

Как это будет применяться к Atlas Treasury?

Предположим, Atlas хочет использовать разные политики безопасности для разных действий в рамках межсетевого взаимодействия. Для обновления статуса с низкой ценностью может потребоваться одна конфигурация, в то время как для сообщения, которое может привести к выпуску значительного залога, может потребоваться несколько независимых DVN. Эта гибкость является ключевой характеристикой LayerZero: приложение выбирает свой стек безопасности, а не наследует один универсальный набор верификаторов для каждого пути.

Гибкость также порождает ответственность. В документации LayerZero OApp указано, что в производственных развертываниях следует использовать несколько необходимых DVN от независимых операторов, поскольку конфигурация с одним DVN делает путь зависимым от одного верификатора. Поэтому Atlas не может рассматривать интеграцию протоколов как разовое решение по API; выбор DVN, узлов, библиотек сообщений, настроек исполнителя, права собственности и процедур обновления становятся частью его системы безопасности. Соответствующие рекомендации содержатся в документации LayerZero OApp .

Если Atlas требуется только перемещение взаимозаменяемых токенов, а не произвольная бизнес-логика, LayerZero также предоставляет свой стандарт взаимозаменяемых токенов Omnichain. Его следует оценивать отдельно от стандартной интеграции OApp, поскольку семантика передачи токенов и обмен сообщениями в приложении — это разные проблемы.

Chainlink CCIP: обмен сообщениями на основе DON с управлением по полосам движения.

Chainlink CCIP использует другую модель. В CCIP «полоса» — это однонаправленный путь от одного блокчейна к другому. Обратное направление — это отдельная полоса, и характеристики каждой полосы могут различаться. В ключевых концепциях CCIP от Chainlink объясняется, что окончательность имеет значение, поскольку конечная точка не должна реагировать на исходное событие, которое еще может быть реорганизовано.

Как описано в документации для текущей архитектуры CCIP v1.6, децентрализованная сеть оракулов (Role DON) запускает два плагина для внецепочечной отчетности. Процесс Commit OCR достигает консенсуса по сообщениям исходной цепочки и фиксирует корни Меркла в целевой цепочке. Затем процесс Executing OCR проверяет ожидающие выполнения и выполняет сообщения в целевой цепочке. Официальная страница архитектуры CCIP внецепочечной обработки данных подробно описывает этот процесс.

В документации 2026 года есть важное изменение, которое легко пропустить при чтении старых материалов. В настоящее время Chainlink заявляет, что автоматизированная роль сети управления рисками вне блокчейна больше не активна в текущих развертываниях CCIP и, как ожидается, вернется в качестве необязательного уровня валидации в будущих релизах. Контракт RMN в блокчейне остается в качестве аварийной защиты для определенных функций, в то время как другие средства контроля включают настраиваемые ограничения скорости, аттестацию токенов и мониторинг. Поэтому любая статья, описывающая старую сеть RMN вне блокчейна как постоянно активную независимую сеть валидации, будет устаревшей для текущих развертываний.

Как это будет применяться к Atlas Treasury?

В зависимости от поддерживаемой пары «источник-получатель» и интеграции, Atlas может использовать CCIP для отправки произвольных данных, токенов или программируемых токенов. Вместо выбора собственной композиции DVN, Atlas будет в первую очередь интегрироваться с контрактами CCIP и моделью безопасности, предоставляемой архитектурой CCIP DON, а затем применять проверки на уровне приложений в отношении доверенных цепочек, отправителей, маршрутизаторов и обработки сообщений.

Эти проверки не являются необязательными. В документации Chainlink по передовым методам CCIP EVM прямо рекомендуется проверять цепочки получателей перед отправкой, проверять цепочки отправителей и отправителей при получении, проверять адреса маршрутизаторов при необходимости, отделять прием сообщений от основной бизнес-логики, тестировать в неблагоприятных условиях и отслеживать аномальное поведение.

Для эмитентов токенов CCIP также предоставляет инфраструктуру для межсетевого обмена токенами, основанную на пулах токенов и правилах администрирования. Для пулов токенов можно настроить ограничения скорости, поэтому Atlas следует оценивать архитектуру токенов отдельно от простого произвольного обмена сообщениями, а не предполагать, что одна конфигурация подходит для обоих случаев.

Червоточина: аттестации Guardian производят портативные VAA

Система обмена сообщениями Wormhole основана на сети Стражей и подтверждаемых действиях (Verifiable Action Approvals, VAA). Исходный контракт отправляет сообщение через основной контракт Wormhole. Стражи наблюдают за ним и подписывают, и как только достигается необходимый кворум, полученное VAA может быть отправлено в целевую цепочку для проверки.

В текущей документации Wormhole Guardian описывается канонический набор из 19 Стражей и стандартная мультиподпись VAA из 13 из 19. В некоторых цепочках делегированное подмножество выполняет прямое наблюдение, но канонические Стражи ожидают заданного кворума делегатов, прежде чем создать ту же стандартную мультиподпись VAA из 13 из 19.

Доставка намеренно отделена от проверки действительности. В обзоре системы обмена сообщениями Wormhole поясняется, что VAA (Value Access Account — соглашение о предоставлении доступа) передается в пункт назначения и проверяется там. Новая платформа Executor предоставляет модель запроса и цитирования без необходимости получения разрешений для выполнения сообщений. В документации по безопасности также делается важное различие: ретранслятор может влиять на доступность или время, но не может подделать VAA, поскольку проверка действительности осуществляется с помощью подписей Guardian.

Как это будет применяться к Atlas Treasury?

Atlas может отправить сообщение Ethereum, дождаться подтверждения от Guardian, а затем поручить ретранслятору или исполнителю доставить VAA целевому контракту. Получателю потребуется подтвердить происхождение сообщения и реализовать логику приложения, обеспечивающую защиту от повторного воспроизведения. Если Atlas нужны токены, а не только сообщения, Wormhole различает нативные переводы токенов (Native Token Transfers) и обернутые переводы токенов (Wrapped Token Transfers). В официальном обзоре переводов токенов поясняется, что NTT и WTT используют общий уровень обмена сообщениями Guardian, но различаются способом представления, выпуска или создания токенов.

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

LayerZero против CCIP против Wormhole: практические различия

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

Что показывает пример Atlas о реальных рисках интеграции

1. Межцепочечная безопасность включает в себя обе цепочки.

Если Ethereum завершает транзакцию корректно, но целевая цепочка останавливается, реорганизуется или ведет себя непредсказуемо, Atlas все равно сталкивается с межсетевым инцидентом. В конечном итоге, любой протокол зависит от свойств сетей, к которым он подключается. Chainlink прямо рекомендует разработчикам оценивать безопасность и надежность используемых ими сетей, и тот же принцип применим к интеграции LayerZero и Wormhole.

2. Даже корректное сообщение может запустить небезопасную логику приложения.

Протоколы взаимодействия доказывают или подтверждают, что сообщение прошло по ожидаемому пути. Они не гарантируют автоматическую корректность бизнес-логики Atlas. Совершенно корректная инструкция межсетевого взаимодействия все еще может использовать ошибку в принимающем контракте, если Atlas не сможет проверить отправителя, контекст назначения, сумму, nonce, состояние воспроизведения или разрешенное действие.

3. Для перемещения токенов необходима отдельная модель угроз.

Сообщение типа «Алиса владеет 100 единицами» не равнозначно перемещению 100 экономически значимых токенов. Atlas должен документировать, сжигается и выпускается ли кроссчейн-актив, блокируется и освобождается, депонируется, упаковывается или контролируется эмитентом напрямую. Он также должен указывать, кто обладает правом выпуска токенов, кто контролирует лимиты скорости, как работают аварийные паузы и что происходит, если одна из сторон маршрута становится недоступной.

4. Невыполнение обязательств по доставке не должно стать бухгалтерской ошибкой.

Межцепочечные системы являются асинхронными. Скачки газа, перегрузка цепочки, задержки завершения, проблемы с ретранслятором или возврат к исходному состоянию могут задерживать завершение. Atlas следует моделировать состояния «отправлено», «проверено», «доставлено» и «бизнес-логика завершена» как отдельные состояния, а не рассматривать транзакцию в исходной цепочке как окончательное доказательство успешного выполнения действия в целевой цепочке.

Как команде следует выбирать между ними

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

• Выберите точные сети-источник и сеть назначения. Проверьте текущую поддержку в официальном каталоге протокола, а не предполагайте совместимость со всей экосистемой.
• Определите, что именно пересекает эту границу. Отправляет ли Atlas произвольные байты, токен, токен с инструкциями, выполняет ли он действия по управлению или осуществляет синхронизацию состояния?
• Запишите предположения для проверки. Для LayerZero это включает выбранные DVN и пороговое значение. Для CCIP — текущую архитектуру DON и поведение полосы. Для Wormhole — кворум Guardian и любую конфигурацию делегированного наблюдения, относящуюся к цепочке.
• Моделируйте выполнение запросов к получателю отдельно. Определите, кто может доставить сообщение, что произойдет в случае задержки доставки, как финансируется подача газа и нужно ли обрабатывать сообщения в определенном порядке.
• Проведите аудит авторизации на уровне приложения. Ограничьте доступ к исходным цепочкам, контрактам отправителя, контрактам получателя, привилегированным ролям и управлению токенами.
• Планируйте изменения в работе. Поддержка сети, версии протоколов, ограничения сервисов и рекомендуемая конфигурация могут меняться. Поэтому мониторинг производственной среды должен рассматривать обновления документации и устаревание как операционные события.

Последняя самопроверка для гипотетического Казначейства Атласа.

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

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

Если Atlas не может ответить на эти вопросы, значит, он еще не сравнил протоколы взаимодействия на том уровне, который имеет значение. LayerZero, Chainlink CCIP и Wormhole предоставляют зрелые способы координации действий между блокчейнами, но они по-разному распределяют ответственность за проверку, доставку, конфигурацию и эксплуатацию. Поэтому практический выбор заключается не в том, «какой протокол для межсетевого взаимодействия лучше всего?», а в том, «какая модель безопасности и исполнения лучше всего соответствует конкретному межсетевому действию, которое это приложение готово авторизовать?».