Во-первых, различайте данные выполнения и данные BLOB-объектов

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

Краткосрочная доступность отличается от постоянного резервного копирования.

Протоколы и клиенты устанавливают правила обслуживания и хранения данных Blob. Эти параметры и обновления могут меняться; обратитесь к текущим спецификациям. Не следует воспринимать количество дней, упомянутое в старой статье, как постоянную гарантию. Фиксации в Proof-of-History могут быть доступны для поиска, но фиксации, онтологии данных и доступные службы архивирования — это разные вещи; наличие хеша не означает, что вы можете восстановить весь контент из хеша.

Почему это должно волновать обычных пользователей.

Балансы кошельков обычно предоставляются приложениями и узлами; пользователи редко загружают Blob-объекты напрямую. Однако путь доступа к данным становится важным во время простоя оператора, независимого восстановления состояния или разрешения споров. Возможность выхода из сети уровня 2 также связана с мостами, системами доказательств и разрешениями на обновление; нельзя предполагать, что все сбои автоматически устраняются основной сетью просто потому, что «используются данные Ethereum».

Пример исторического запроса

Предположим, исследователь хочет просмотреть пакет транзакций уровня 2 за несколько месяцев. Сначала ему следует найти блоки L2 и пакет, отправленный в основную сеть, затем определить формат данных и источник архива, все еще предоставляющий полезную нагрузку. Если общий конечный пункт не может найти старые данные, нельзя сделать вывод о том, что исходная транзакция никогда не существовала. Необходимо проверить область действия сервиса конечного пункта, ссылки на пакеты и другие независимые источники, а также зафиксировать, какие шаги по-прежнему не воспроизводятся.

Методы оценки поставщиков архивных услуг

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

Предоставить источник для статей и исследований данных

Хранить идентификаторы сети L1 и L2, хеши пакетов и блоков, версии спецификаций, время запросов и адреса архивов. При цитировании данных указывайте, завершена ли загрузка, есть ли пробелы и была ли она независимо проверена. Этот документ только описывает жизненный цикл данных и не гарантирует безопасность какой-либо системы уровня 2; обновления протоколов, службы архивирования и условия выхода должны быть повторно проверены перед фактическим использованием.