Chainlink CCIP: адаптер межсетевого сообщения

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

Срез документации — 12 октября 2026 года. Текущее руководство EVM описывает CCIP 2.0; старые пути и копии предыдущего SDK не считаем автоматически актуальными. Мы не устанавливаем Chainlink-пакеты, не создаём аккаунт и не отправляем сообщения. Результат — спецификация границы адаптера, а не проверенное развёртывание.

Транспорт не является нашим издателем

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

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

Формат инфраструктурного контекста также не следует переписывать вручную из произвольного JSON. Он поступает предусмотренным путём SDK. Собственный адаптер только преобразует допустимые сведения в нормализованную запись для прикладного обработчика после нужных проверок.

Какие сведения сохраняет граница

Руководство описывает идентичность сообщения, селектор исходной цепочки, sender в байтовом представлении и полезные данные. Для EVM-профиля sender декодируется в подходящий адрес по ABI, с проверкой допустимого формата. Нельзя обрезать произвольный набор байтов и объявить получившийся фрагмент авторизованным адресом.

CCIP-контекст
  → источник и транспортная идентичность
  → разрешённый исходный адрес
  → library-announcement-v1
  → MirrorLedger: порядок и однократное применение

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

Chain selector и EVM chainId хранятся отдельно. Первый нужен транспортному маршруту, второй — соответствующему сетевому контексту приложения и подписи. Сходное назначение не позволяет применять одно число в обоих интерфейсах без документированного сопоставления.

Конфигурация действующего профиля

В документации 2.0 описаны дополнительные правила проверки и финальности. Для проекта важно выбрать допустимую политику приёмника и исследовать её последствия. Более быстрый режим не является просто бесплатной заменой финального основания. Приложение должно понимать, какие гарантии допускает и для какого действия.

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

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

Комиссия и исполнительный ресурс

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

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

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

Успешная доставка и прикладной эффект

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

Один транспортный статус нельзя превращать в заявление, что читатель уже получил HTML. Хранители и шлюзы остаются отдельной зависимостью. Зеркало может правильно объявить недоступный сейчас выпуск. И наоборот, файл может быть доступен при незавершённой межсетевой процедуре.

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

Что не переносим из старого примера

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

Мы специально не приводим смесь классов разных поколений SDK как якобы завершённый контракт. Библиотечный MirrorLedger независим, а реальный адаптер требует закреплённой версии пакета и согласованных интерфейсов. Установки здесь не было, поэтому совместимость не объявляется фактически проверенной.

Текущая документация отдельно предупреждает о роли стандартного проверяющего механизма и дополнительных Cross-Chain Verifiers. Дополнительная защита не должна восприниматься как произвольная замена предусмотренного основного verifier. Для нашего досье выбор таких компонентов становится частью доверительной модели, а не косметической настройкой. Если команда хочет изменить проверяющий набор, она исследует конкретные гарантии и ответственность участников. В этой статье такие изменения не конфигурируются; сохраняется требование следовать действующему профилю и явно описать любое дополнительное полномочие. Это не даёт читателю спутать прикладной allowlist отправителя с инфраструктурным основанием проверки сообщения.

Подготовленная интеграция

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

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

Оглавление серии