Блокчейн-мост: доставка сообщения между сетями

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

Пример переносит объявление манифеста, а не средства. Мы не используем реальный мост, не отправляем сообщение и не меняем базовый CourseCatalog. Целевой приёмник будет самостоятельным расширением с явно описанной политикой.

Действие и сообщение

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

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

объявление A → намерение передачи
             → исходная операция и messageId
             → межсетевые стадии
             → целевое исполнение B
             → прикладное применение зеркалом

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

Содержание полезной нагрузки

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

{
  "schema": "library-announcement-v1",
  "courseId": "17",
  "edition": "2",
  "manifestAlgorithm": "sha256",
  "manifestDigest": "ANNOUNCED_DIGEST"
}

Поле digest здесь обозначено меткой. В реальном кодировании используется согласованный тип с полученным значением. Указание алгоритма относится к нашему приложению; транспорт не угадывает его по длине. CID обнаружения материалов хранится по отдельной модели, не заменяя 32-байтовое обязательство.

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

Что видит исходная сторона

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

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

Публичная карточка может продолжать показывать A как авторитетный источник и статус зеркала рядом. Если продукт требует именно готовое B, он ждёт подтверждённого прикладного результата. Правило интерфейса выбирается до отправки и не меняется молча из-за задержки.

Что видит целевая сторона

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

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

Если целевой журнал уже содержит ту же идентичность, политика повторов исключает повторное применение. Следующие уроки уточнят источник и идемпотентность. Пока важно сохранить результат как отдельное действие B, не выдавая исходный receipt A за доказательство изменения другого storage.

Порядок двух редакций

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

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

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

Для журнала полезно различать доставку сведений и подтверждение их применения обратно исходной стороне. Если A требует знать о результате B, понадобится отдельный предусмотренный ответный маршрут. Он имеет свои стадии и идентичность, а не возникает из исходного receipt автоматически. Отсутствие обратного подтверждения не обязательно означает, что B не применила сообщение: ответ мог задержаться. Поэтому исходная карточка сохраняет неизвестность и использует согласованный способ сверки целевого состояния. В нашей первой модели обратный ответ не реализован; B наблюдается отдельно. Такое ограничение проще объяснить, чем обещать одной отправкой мгновенное общее состояние двух сетей.

Отказ маршрута и сохранённые материалы

Во время задержки B учебный выпуск всё ещё может быть доступен по своему CID и обычным URL. Отказ доставки объявления не доказывает повреждения HTML. Читатель может открыть определённый архивный материал по известному основанию, а интерфейс показывает, что зеркало пока не обновилось.

Для оператора важно не объединять эти причины. Журнал передачи содержит источник, цель, сообщение и стадийность; опись хранения содержит корни и доступность реплик. Если перепутать слои, оператор способен начать повторный импорт материалов вместо восстановления межсетевого задания.

Итог — прикладной журнал, отличающий намерение, исходную операцию, транспортную доставку и целевое применение. Общие модели изложены в документации мостов Ethereum, конкретные стадии одного транспорта — в CCIP Message Lifecycle. Ни сообщение, ни учебная проверка в текущей работе не исполнены. Дальше определим, почему правильный вызывающий транспорт ещё не доказывает разрешённого издателя.

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