Смарт-контракт в двух сетях: экземпляры L1 и L2
Библиотека подготовила модель L1/L2 и словарь стадий. Теперь нужно сохранить конфигурацию, которая однозначно выбирает экземпляр в каждом контексте. Одинаковое имя CourseCatalog не гарантирует, что браузер, издатель и наблюдатель читают одну и ту же запись. В уроке создадим досье размещений и правила его изменения.
Нового развёртывания нет. Существующий локальный профиль использует chainId 31337, Solidity 0.8.30, EVM Cancun, Node 22.14.0 и viem 2.37.9. Это закреплённая учебная база, а не описание публичной L2. Внешние адреса и параметры оставляем явно незаполненными до выбора сети.
Конфигурация относится к экземпляру
Для каждой роли нужны идентификатор сети, разрешённый источник чтения, адрес контракта и сведения о версии интерфейса. Эти поля отвечают на разные вопросы. ChainId помогает различать сетевой контекст подписи; адрес выбирает экземпляр; ABI определяет способ взаимодействия. Ни одно из них само по себе не устанавливает организационную принадлежность библиотеки.
Добавим назначение размещения: исходное объявление или предполагаемое зеркало. Это собственная политика проекта. Если две записи одинаково названы «главный реестр», оператор не поймёт, где допустима новая публикация. Назначения должны согласовываться с интерфейсом издателя и правилами чтения карточки курса.
{
"configurationVersion": "library-networks-v1",
"origin": {
"chainId": "SELECTED_CHAIN_ID_A",
"catalog": "DEPLOYED_ADDRESS_A",
"role": "authoritative-announcement"
},
"destination": {
"chainId": "SELECTED_CHAIN_ID_B",
"catalog": "DEPLOYED_ADDRESS_B",
"role": "declared-mirror"
}
}Это редакционный образец с метками, не готовый вход клиента. Реализация потребует допустимых типов и реальных значений после отдельного развёртывания. Она отвергает незаполненные поля, а не превращает их в случайные адреса.
Проверка перед действием
Издательский экран получает текущую выбранную сеть и сравнивает её с назначением подготовленного действия. Пользовательское переключение кошелька требует повторной привязки действия. Старое окно с адресом A не отправляет вызов в B только потому, что оба контекста поддерживают EVM. До подписи интерфейс показывает выбранный экземпляр и предмет публикации.
Публичное чтение может использовать отдельный клиент, не зависящий от кошелька посетителя. Поэтому конфигурация чтения также имеет свой явный контекст. Иначе переключение кошелька способно неожиданно сменить видимую рекомендацию курса. Для библиотеки это нежелательно: чтение официального объявления не должно определяться произвольным состоянием чужой сессии.
Наличие кода по адресу полезно исследовать, но не достаточно для удостоверения нужной ревизии. Код может быть другой программой с похожими функциями; proxy требует понимания текущей реализации и полномочий обновления. Досье сохраняет предполагаемый интерфейс и способ установления доверенного развёртывания отдельно от простой синтаксической проверки адреса.
Publisher и зеркало
У каждого базового CourseCatalog собственное значение publisher. Развёртывание второго экземпляра не даёт первому право публиковать во втором автоматически. Если зеркало должно обновляться через межсетевой адаптер, архитектура вводит отдельный приёмник и определяет, каким полномочием он управляет целевой записью. Это изменение описывается явно.
Наш базовый контракт не получает новый метод receiveMessage незаметно между уроками. Можно использовать отдельный MirrorCatalog с определённой моделью или другой согласованный адаптер. В любом случае исходный publisher и доверенный источник межсетевого объявления названы. Такой подход позволяет сопоставить права с реальной кодовой границей.
Если редакция решает публиковать независимо в двух реестрах, это другая модель. Возможны две несогласованные рекомендации, и продукт должен определить, как их показывает. Совпадение SHA-256 в один момент не доказывает постоянной синхронизации. Процесс обновления получает собственный журнал и выбранное правило авторитетности.
Секреты и публичная конфигурация
Адреса экземпляров и номера сетей обычно являются публичными сведениями проекта. Подписывающие секреты, административные токены RPC и полномочия управления не входят в доступный браузеру файл только потому, что рядом лежит публичный адрес. Для библиотеки создаём разные границы чтения и издательского действия.
Если URL провайдера содержит токен, его распространение зависит от модели сервиса и допустимых ограничений; нельзя автоматически назвать любой такой URL безопасным для публичного репозитория. В этом уроке реальные URL и токены не используются. Собственный серверный адаптер может предоставлять минимальный разрешённый интерфейс, когда приложение действительно нуждается в закрытом доступе.
Досье обозначает, какие поля публичны и кто вправе их менять. Для адреса реестра изменение опаснее косметического заголовка: оно способно переключить доверенное объявление. Поэтому конфигурационная ревизия проходит редакционный процесс и сохраняет прежнюю версию для объяснения исторических ссылок.
Переключение конфигурации
Представим, что у библиотеки появилась новая ревизия целевого экземпляра. Сначала описывают миграцию состояния и назначение нового адреса, затем обновляют управляемую конфигурацию. Старые наблюдения остаются привязаны к прежнему адресу. Они не становятся записями нового контракта после замены одного общего поля.
Поздний ответ от старого RPC проверяется относительно снимка конфигурации запроса. Если экран уже показывает новый экземпляр, ответ не должен подменить его состояние. Это тот же принцип идентичности операции, который ранее применялся к двум редакциям IPFS. Здесь цель состоит из сети, адреса и выбранного контекста чтения.
Для отката сохраняют причину и конкретную ревизию. Откат файла конфигурации не отменяет отправленные транзакции и не удаляет данные нового экземпляра. Он изменяет выбор приложения. Поэтому оператор видит раздельно действия в сетях и решение интерфейса о том, какое размещение сейчас считается основным.
В собственном журнале конфигурации сохраняем также назначение самой ревизии. Исправление опечатки в отображаемом названии не равно смене адреса доверенного реестра. Смена адреса не равна переносу его истории. Для каждого изменения записывается, какие старые операции продолжают наблюдаться и какой контекст получают новые. Если отдельный индексатор всё ещё читает прежний адрес, новый браузер может показывать одно состояние, а сервер выдачи — другое. Поэтому согласование конфигурации касается всех участников маршрута, а не только текущей вкладки. До такого согласования продукт не объявляет миграцию завершённой.
Готовое досье
Итог урока — две записи размещений, версии интерфейса, роли publisher и предполагаемого приёмника, политика источника чтения и процедура конфигурационного перехода. Критерий будущей лаборатории: действие и наблюдение не пересекают сетевой контекст без явного решения. Пока фактические адреса отсутствуют, а конфигурация не передавалась клиенту.
Принципы сетевого контекста описаны в документации сетей Ethereum, различия слоёв — в масштабировании. Далее введём межсетевое сообщение. Оно получит собственную идентичность и жизненный цикл, а не станет скрытым эффектом второго развёртывания.