Data availability в L2: восстановление данных

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

В уроке создадим модель восстановления курса 17, различая данные протокола, архив приложения и наблюдения RPC. Мы не запускаем узел и не скачиваем блоки. Выводы ниже относятся к ожидаемым последствиям собственного примера.

Корень состояния и переходы

Представим, что реестр сначала хранит первый отпечаток курса, затем publisher объявляет второй. Итоговое состояние показывает новую запись. Но участнику, который хочет самостоятельно исследовать путь изменения, нужны предусмотренные входы и правила исполнения. Один корень является обязательством относительно состояния, а не полной копией всей истории в открытом виде.

В rollup сведения о переходах распространяются и закрепляются по определённой архитектуре. Это может включать данные на базовом слое и дополнительные компоненты. Точный состав и сроки зависят от протокола. Для нашего досье нужно назвать, какие данные доступны, где они размещены и какую процедуру позволяют выполнить. Слово «данные опубликованы» без предмета слишком неоднозначно.

начальное состояние + доступные входы + правила
                        ↓
                воспроизводимый переход
                        ↓
             состояние курса после операции

Схема не означает, что любое приложение может восстановить любой rollup одним коротким скриптом. Формат, клиент и полномочия протокола требуют отдельного исследования. Она лишь показывает, зачем обязательство и доступность необходимы для разных частей проверки.

Данные протокола и тексты библиотеки

Даже когда предусмотренные данные rollup доступны, учебные HTML-файлы не обязаны находиться среди них. Наш CourseCatalog хранит SHA-256 манифеста, а материалы выдаются отдельно. Поэтому протокольная доступность состояния не заменяет собственные копии выпуска. Читатель может подтвердить объявление и всё равно не получить текст из выключенного хранилища.

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

Из этого следует состав резервирования: материалы с манифестом; история собственных объявлений с сетевым контекстом; необходимые конфигурации чтения; сведения о зависимости от выбранного протокола. Один архив сайта не является резервной копией всего rollup. Один доступный RPC не является нашей долговременной копией уроков.

Получение и долговременное хранение

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

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

При выборе провайдера RPC также выясняют доступ к старым состояниям и событиям. Ответ «последняя запись доступна» не сообщает, способен ли сервис обработать исторический запрос. Ограничения продукта, узла и самого протокола различаются. Для оператора полезно фиксировать, какой источник поддерживает какую архивную задачу.

Rollup и внешняя доступность

Система с доказательствами корректности может хранить данные по другой модели, чем rollup, публикующий необходимый набор в L1. Названия validity proof и data availability описывают разные свойства. Проверка доказательства перехода не восстанавливает недоступные пользовательские данные из ничего. Поэтому систему нельзя оценивать только по тому, что у неё есть криптографическое доказательство.

Для учебной библиотеки зададим вопросы: какие участники должны сохранять входы; можно ли восстановить состояние без единственного оператора; как обнаруживается отказ выдачи; какие полномочия обновления способны изменить правила. Ответы относятся к конкретной выбранной сети, а не автоматически к каждому проекту с приставкой ZK.

Если дополнительный комитет или внешний слой участвует в доступности, это отдельная зависимость досье. Она может быть допустимой для продукта, но её нужно назвать. Такой анализ позволяет сравнивать варианты по фактическим гарантиям, сохраняя различие исполнения, доказательства и получения данных.

Сценарий потери источника

Оператор B перестал отвечать через привычный RPC. У библиотеки сохранился манифест второй редакции, но не полная сетевой история. Первый вопрос — существует ли другой разрешённый источник состояния. Второй — какие сведения доступны для независимого восстановления по протоколу. Третий — что библиотека может показать на основании собственного архива уже сейчас.

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

Если новый источник отдаёт разные ответы, сверяют сетевой контекст и высоту наблюдения. Старое состояние и новое состояние могут быть правильными для разных точек истории. Опись должна хранить основу сравнения. Иначе независимая сверка превратится в голосование двух JSON-ответов без понимания, к какому блоку они относятся.

Практический итог модели

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

Базовые понятия объяснены в документации доступности данных Ethereum. Свойства хранения материалов разобраны в курсе IPFS. В следующем уроке свяжем доступные входы с оспариванием optimistic-перехода; сегодняшняя опись подготовлена без сетевого исполнения.

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