L2: подтверждение, финальность и вывод средств
Редактор нажал «опубликовать», получил идентификатор операции и увидел новую запись курса. Можно ли уже написать «выпуск окончательно доступен во всех сетях»? Ответ зависит от того, какое событие действительно наблюдалось. В уроке построим язык статусов для библиотеки, разделяя приём запроса, включение, предусмотренное подтверждение и завершение конкретного выхода.
Работа остаётся проектированием. Мы не наблюдаем реальную L2 и не назначаем универсальный срок для всех протоколов. Результат — несколько независимых состояний, привязанных к сети, операции и пользовательской цели.
Отправка ещё не результат исполнения
Кошелёк может вернуть идентификатор отправленной транзакции. Это позволяет продолжить наблюдение, но само по себе не подтверждает, что вызов завершился успешно. Операция могла остаться вне блока, заменить другое намерение или исполняться с отказом. Для нашей карточки курса отправка становится отдельной стадией, а не окончательным объявлением.
После включения нужен результат исполнения и соответствующий контекст. Если publish завершился отказом из-за полномочий, наличие транзакции в блоке не означает новую запись курса. Интерфейс связывает состояние вызова с ожидаемыми изменениями, а не только с исчезновением индикатора ожидания.
подготовлено → отправлено → наблюдено включение
→ успешное исполнение / отказ
→ дальнейшее основание принятияЭто собственная модель приложения. Она не подменяет внутренние названия стадий выбранного протокола; адаптер сопоставляет их явно, сохраняя исходные наблюдения.
Быстрое наблюдение и базовый слой
В L2 результат может быстро появиться через источник исполняющего слоя. Далее данные или предусмотренные утверждения проходят связь с базовым слоем. Политика продукта определяет, какое основание достаточно для просмотра и какое требуется для более серьёзного действия. Необратимая выдача ключа и показ открытого урока могут иметь разные последствия.
Слово «подтверждено» требует предмета. Подтверждено RPC B, включено в определённую историю B, закреплено соответствующим механизмом A — разные сообщения. Если продукт объединяет их для простого интерфейса, он всё равно хранит точный внутренний контекст и объясняет ограничение в подходящем месте.
Политика не должна обещать больше наблюдённого. Если библиотека сознательно открывает публичный текст на ранней стадии, это правило приложения. Оно не означает, что процедура выхода из L2 уже завершилась. Текст может остаться доступным из архива независимо от дальнейшего статуса объявления.
Выход имеет собственный процесс
Пользователь может инициировать переход средств или сообщения из B в A. Это другая цель, чем локальное обновление записи B. Для выхода нужны предусмотренные протоколом условия, дополнительные стадии и иногда отдельное завершающее действие. Конкретные сроки и роли зависят от выбранной системы.
Не переносим обещание быстрого L2-исполнения на весь путь выхода. В optimistic-профиле важна соответствующая процедура оспаривания; в validity-профиле — предусмотренная проверка и остальные условия. Реальная реализация может добавлять ограничения, которых нет в коротком теоретическом описании класса систем.
Быстрые сторонние маршруты могут предоставлять другой сервис с собственной ликвидностью и доверием. Их ответ не равнозначен завершению исходного протокольного выхода. Для библиотеки такой маршрут описывается отдельно, если он вообще нужен. Пользователь должен видеть, какой процесс и чьи обязательства обслуживают действие.
Что хранит наблюдатель
Минимальная запись включает идентичность сети, адрес экземпляра, идентификатор операции, ожидаемое назначение и последнее наблюдение. Для блокового контекста сохраняют подходящие номер и хеш по используемому источнику. Если состояние пересматривается, можно понять, к какому наблюдению относился прежний вывод.
В журнале время получения ответа отличается от времени сетевого события. Быстрый сервер может отдать старую запись; медленный — более свежую. Нельзя считать настенные часы HTTP-ответа достаточным доказательством уровня финальности. Сведения оцениваются по сетевой модели и выбранной политике.
Несколько источников полезны для диагностики, но простое большинство JSON-ответов не заменяет понимание их контекста. Расхождение может быть задержкой, разной высотой или неверной конфигурацией. Оператор выясняет причину, не выбирая произвольный более удобный ответ для зелёной отметки.
Потеря связи в середине ожидания
Представим, что редактор отправил публикацию и закрыл страницу. После открытия приложение восстанавливает наблюдение по сохранённой идентичности, а не автоматически отправляет новую публикацию. Если неизвестно, была ли операция отправлена, процедура различает это состояние и подтверждённый отказ. Повтор внешнего действия требует собственной стратегии.
Теперь RPC временно недоступен. Старое наблюдение сохраняется как последнее известное, а свежесть помечается отдельно. Отсутствие ответа не отменяет успешное включение, уже записанное в журнале, но и не подтверждает продолжение дальнейших стадий. Для пользователя полезен статус «наблюдение временно недоступно» с контекстом выбранной операции.
При действительном пересмотре истории прикладное решение может потребовать пересчёта. Если ключ материалов уже выдан, технический откат не сделает его неизвестным читателю. Это ограничение продукта влияет на выбор порога принятия до выдачи, а не исправляется одной сменой текстовой метки позже.
В архивной ссылке можно дополнительно сохранить выбранную редакцию и основание её объявления. Тогда читатель, возвращаясь через месяц, понимает, что открывает исторический результат, а не новое наблюдение старой операции. Если текущая рекомендация изменилась, карточка предлагает другой маршрут отдельно. Для административного решения исторической записи недостаточно: перед новой публикацией получают нужный текущий контекст. Таким образом, длительное хранение наблюдения полезно для объяснения истории, но не является универсальным разрешением выполнить действие с прежними ожиданиями. Политика продукта определяет, где достаточно архивного основания и где требуется свежая сверка.
Конкретная карточка курса
Для курса 17 библиотека хранит отдельно текущий манифест и состояние его объявления. Первая редакция может оставаться доступной как архив, пока вторая проходит предусмотренные стадии. Посетитель видит, что он открыл, и не получает незаметно смешанный текст двух выпусков.
Операторская карточка показывает источник каждого статуса: отправка издателя, наблюдение исполняющего слоя, соответствующий этап базового слоя и редакционное решение. Необязательные для обычного читателя детали остаются в диагностике, но смысл публичной метки должен быть точным. Так простой интерфейс не становится источником ложной гарантии.
Итог — словарь стадий и правила перехода для выбранной пользовательской цели. Основы различий изложены в документации optimistic rollups и ZK-rollups. Фактические блоки и подтверждения не исследовались исполнением. Далее разберём стоимость операции: она тоже может состоять из нескольких независимых компонентов.