Ethereum L1 и L2: зависимости сетей

Учебная библиотека уже умеет объявлять выпуск курса 17 через CourseCatalog. Материалы находятся вне контракта, а браузер сверяет их с объявлением. Теперь редакция хочет уменьшить стоимость частых действий и рассматривает L2. Начнём с карты зависимостей: какое состояние хранится в каждом слое, кто принимает операции и какие решения по-прежнему принадлежат приложению.

Результат урока — архитектурное досье двух сетевых контекстов без развёртывания. Существующий контракт не получает новых методов молча. publisher, courses, publish и deactivate сохраняют смысл; второе размещение, зеркало и межсетевой приём будут отдельными решениями.

Сеть входит в идентичность записи

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

Для библиотеки выделим авторитетный реестр A и предполагаемое размещение B. Слово «авторитетный» означает наше прикладное правило выбора объявления. Само название L1 или L2 не решает, где редакция должна публиковать. Можно выбрать только L2 для конкретного продукта; можно сохранить L1 как исходный слой и отдельно передавать объявления. Каждый вариант требует явного поведения читателя.

страница курса 17
  ├─ выбранный реестр: сеть + адрес
  ├─ объявленный SHA-256 манифеста
  ├─ получение манифеста и материалов
  └─ политика текущего выпуска

Здесь SHA-256 относится к точным сохранённым байтам манифеста. CID остаётся отдельным идентификатором хранения. Смена сети реестра не превращает CID в адрес контракта и не переносит сами HTML-файлы в storage EVM.

Что добавляет L2

Rollup исполняет операции в своём слое, используя определённую связь с базовым Ethereum для проверки и публикации предусмотренных данных. Это отличается от самостоятельной sidechain с собственной моделью безопасности. При одинаковом формате адреса и похожем RPC зависимости протокола могут существенно различаться. Поэтому нельзя назвать любую дешёвую EVM-сеть «тем же Ethereum, только быстрее».

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

Полезно отдельно записать исполнение и расчётный слой. Браузер обращается к RPC B и видит действие в B; связанное состояние затем проходит предусмотренную процедуру относительно A. Эти наблюдения имеют разные стадии. Одно успешное чтение из B не является доказательством завершения любого возможного вывода в A.

Приложение сохраняет свои правила

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

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

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

Карта отказов по слоям

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

Во втором сценарии B быстро приняла публикацию, но связанный этап базового слоя ещё не завершён. Интерфейс показывает наблюдённую стадию, а не общее «везде опубликовано». В третьем материалы получены, но SHA-256 не совпал с объявленным. Изменение RPC или уменьшение комиссии не исправляет такую подмену байтов; нужно получить соответствующий манифест.

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

Перенос курса без переноса истории

Редакция решила создать второе размещение B и опубликовать там тот же отпечаток. Читательские материалы действительно могут совпасть, но история объявления B начинается отдельно. Утверждение «текст тот же» не равнозначно утверждению «эта транзакция перенеслась». В досье связываются два объявления относительно общего манифеста.

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

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

Досье выбора

Сохраним назначение A и B, авторитетный источник, способ чтения, издательские полномочия, механизм проверки переходов и правила пользовательского статуса. Реальные RPC, адреса и параметры ещё не выбраны; метки не подменяются правдоподобными выдуманными значениями. Базовый учебный профиль 31337 обозначает отдельную будущую локальную лабораторию, а не публичную L2.

Общие различия описаны в документации масштабирования Ethereum. Дальше разберём доступность данных: правильный отпечаток состояния ещё не объясняет, из каких сведений независимый участник сможет это состояние восстановить. Пока получена письменная модель зависимостей; узлы, контракты и учебные проверки не запускались.

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