Cross-chain сообщения: проверка источника

Приёмник библиотеки получил вызов через межсетевой механизм. Достаточно ли проверить, что msg.sender равен адресу локального messenger? Нет: этот адрес может обслуживать сообщения многих исходных приложений. Для изменения зеркала нужно установить как транспортную границу, так и разрешённое происхождение конкретного объявления.

Результат урока — порядок аутентификации источника для курса 17. Мы рассмотрим общий смысл на примере cross-domain messaging и CCIP, но не создадим готовую универсальную реализацию для всех SDK. Адреса инфраструктуры и исходных издателей не выдумываются.

Непосредственный вызывающий

В целевой сети фактический msg.sender обычно относится к предусмотренному локальному механизму доставки. Он не обязан совпадать с исходным publisher или отправляющим контрактом другой сети. Поэтому проверка адреса обычного EVM-вызова решает лишь первый вопрос: кто вызвал наш приёмник здесь.

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

проверить локальный транспорт
  → получить подтверждённый им контекст источника
  → проверить сеть и исходного отправителя
  → разобрать схему объявления
  → применить прикладную политику

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

Исходный отправитель

В cross-domain-подходе предусмотренный messenger может предоставлять контекст исходного отправляющего адреса отдельным методом. Этот адрес проверяется против согласованного экземпляра библиотеки. Важно исследовать гарантии метода и область, где его чтение допустимо. Прямой обычный вызов приёмника не должен получить эквивалентные полномочия случайно.

Разделим publisher и исходный адаптер. Publisher может иметь право подготовить объявление, а адаптер — передать его через транспорт. Если целевой приёмник доверяет адаптеру, его собственная логика управления также входит в модель безопасности. Публичный setter разрешённого источника без проверки полномочий способен обойти весь последующий процесс аутентификации.

Исторический учебный пример messenger полезен для понимания двух адресов, но его упрощения не становятся production-правилом. Для нашей библиотеки изменения удалённого экземпляра допускаются только по определённой административной процедуре. Точный код адаптера будет отдельным результатом после выбора профиля.

Сетевой контекст

Один адрес может существовать в разных сетях, и разрешённый источник определяется парой контекста и адреса. В CCIP применяется chain selector транспорта; он не является просто другим написанием EVM chainId. Поэтому конфигурация хранит значения в разных полях и не сравнивает их без предусмотренного сопоставления.

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

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

Схема и область разрешения

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

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

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

Три отрицательных случая

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

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

Ожидаемые результаты не получены запуском. Это подготовленные случаи для последующей локальной лаборатории, где можно контролировать источник без обращения к внешней сети. Модель локального relay не должна выдаваться за настоящий криптографический мост; она проверяет прикладные условия, а не всю инфраструктуру.

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

Изменение разрешённого источника

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

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

Официальные рекомендации описаны в CCIP Best Practices для EVM и руководстве передачи сообщения. Итог — несколько независимых проверок с понятными границами. Следующая глава добавит однократное применение, поскольку подлинность источника не запрещает повтор доставки сама по себе.

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