Optimistic rollup: оспаривание состояния L2
Библиотека рассматривает optimistic rollup для действий редактора. Название optimistic связано с моделью принятия и последующего оспаривания утверждений о состоянии, а не с надеждой разработчика, что программа работает правильно. Разберём путь публикации курса 17 и увидим, почему быстрое принятие операции и завершение протокольного процесса могут иметь разные основания.
Результат — схема наблюдаемых стадий и условий принятия для будущего приложения. Это общая учебная модель. Конкретная реализация, полномочия участников и сроки должны быть исследованы отдельно; реальная транзакция не отправляется.
Исполнение вне базового слоя
Пользователь передаёт операцию в исполняющий слой. Тот упорядочивает её с другими действиями и получает новое состояние. Для нашего реестра переход может заменить объявленный отпечаток курса, если операция имеет полномочие publisher. Такой прикладной переход по-прежнему подчиняется контракту; L2 не разрешает обычному читателю публиковать материалы от лица редакции.
Далее сведения о наборе операций и результаты проходят предусмотренную связь с L1. Именно здесь важно исследовать архитектуру конкретного rollup: какие данные закрепляются и какое утверждение можно оспорить. Браузер не должен считать одним и тем же событием ответ оператора и окончательный протокольный вывод.
операция редактора → исполнение B
→ предусмотренная публикация в A
→ процесс проверки/оспаривания
→ основание принятия по политикеЭто прикладная карта, не буквальный список внутренних событий каждого клиента. Она помогает сохранить контекст, когда документация определённой сети использует собственные названия состояний.
Что оспаривает проверяющий участник
В optimistic-подходе утверждение о переходе не обязательно сопровождается заранее представляемым доказательством корректности всего вычисления. Протокол предусматривает механизм выявления некорректного утверждения и разрешения спора. Проверяющий участник использует доступные данные и правила, чтобы определить несогласованность. Точный формат fault proof зависит от системы.
Для понимания возьмём условное неверное утверждение: отправитель без полномочия publisher якобы обновил курс. При независимом исполнении исходный контракт должен отвергнуть такое действие. Если объявленное состояние приписывает ему успешную запись, переход не соответствует правилам. Учебная идея оспаривания связывает ошибку с проверяемым вычислением, а не с мнением двух веб-серверов.
При этом наша собственная ошибка в корректном контракте не становится протокольной ошибкой автоматически. Если код намеренно разрешает опасное действие, его правильное исполнение может быть нежелательным для продукта и всё же соответствовать программе. Fault proof не исправляет бизнес-логику и не является заменой редакционной или контрактной проверки.
Окно и полномочия
Процедура оспаривания имеет определённые сроки и роли. Не задаём всем optimistic-сетям одно число дней: сроки, механизмы разрешения и доступ участников зависят от действующего профиля. При исследовании библиотеки сохраняются источник параметра, дата и область применения. Старое значение из примера не становится постоянной конфигурацией нового проекта.
Также выясняют, кто способен представить спор, какие средства или условия требуются и как работают обновления протокола. Теоретическое описание класса систем не отвечает на вопрос, открыт ли конкретный механизм любому участнику сейчас. Если есть дополнительные полномочия или аварийные режимы, они входят в анализ зависимости.
Это особенно важно для обещания выхода. Пользовательский интерфейс должен связывать задержку с определённой процедурой, а не показывать бесконечную анимацию без причины. Готовность одной операции в L2 не доказывает, что любой соответствующий вывод в L1 уже разрешён.
Наблюдение браузера
После отправки публикации редактор может быстро увидеть её через RPC B. Для карточки курса это основание показать определённую наблюдаемую стадию. Приложение сохраняет сеть, идентификатор операции и контекст блока. Позже обновляет статус по выбранной политике, не перезаписывая все стадии одним полем success.
Если оператор временно перестал отвечать, приложение не объявляет публикацию исчезнувшей. Оно знает, что последнее наблюдение устарело. Если история пересмотрена, сохранённая операция может перейти в другое состояние. Интерфейс разделяет отсутствие свежего ответа и действительное изменение принадлежности принятой истории.
Архивные материалы при этом не обязательно недоступны. SHA-256 манифеста остаётся проверяемым относительно конкретного объявленного выпуска. Но вопрос «какой выпуск сейчас рекомендован» требует актуального контекста. Эти два маршрута позволяют не закрывать весь учебный сайт из-за отказа одного RPC и не выдавать старую запись за новую.
Изменённый сценарий
Представим, что редактор отправил публикацию второй редакции, а затем открыл другую сеть в кошельке. Операция не переносится вместе с переключением интерфейса. Её наблюдение остаётся связано с исходной B. Поздний ответ этой операции не должен обновить карточку экземпляра в новой сети. Это обычное правило идентичности запроса, усиленное наличием нескольких сетевых контекстов.
Теперь предположим, что досье ошибочно установило слишком ранний статус «окончательно завершено». Исправление заключается в корректной политике статусов, а не в изменении байтов уже подготовленного манифеста. Контент и уровень уверенности в объявлении различаются. Для пользователя полезно назвать стадию прямо и показать, какие дальнейшие события ещё ожидаются.
Если приложение допускает показ материалов до завершения определённого процесса, это сознательное продуктовое решение. Его не следует маскировать утверждением, будто протокол уже дал более сильную гарантию. Для необратимой выдачи права или вывода средств последствия такого решения отличаются от обычного просмотра открытого текста.
При сравнении двух размещений учитываем и возможность включения операции. Механизм проверки неправильного перехода не обещает, что оператор немедленно включит каждую допустимую публикацию. Цензура или задержка подачи имеет отдельные маршруты защиты по конкретному протоколу. Поэтому досье исследует как корректность принятых переходов, так и возможность подать действие или выйти при отказе обычного оператора. Для редактора библиотеки это разные симптомы: нежелательная задержка собственного объявления и принятие неверного изменения. Они требуют разного объяснения и дальнейшего решения.
Досье optimistic-размещения
Сохраним формат данных и утверждений, механизм спора, действующие роли, источники сроков, полномочия обновления и выбранные прикладные стадии. Каждая строка относится к определённой сети и версии. Наша карта не объявляет любой rollup одинаково децентрализованным и не содержит выдуманных production-адресов.
Понятия описаны в первичном объяснении optimistic rollups. Следующий урок рассмотрит другой способ проверки переходов — validity proof. При подготовке текста доказательства спора не создавались, клиенты не устанавливались и правила будущей лаборатории не исполнялись.