Перейти к содержанию
Financial Context Wiki

Доступность данных

Руководство с приоритетом проверки публикации и извлекаемости данных, обязательств, валидности, финальности, выборки, хранения, архивов, вывода состояния роллапа и исполнимого восстановления.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

Доступность данных означает, что достаточный объем определенных протоколом данных опубликован и доступен в требуемом окне, чтобы предполагаемые участники могли проверить, вывести или восстановить соответствующее состояние. Требуемым объектом могут быть входные данные транзакций, изменения состояния, кодированные доли или другой заданный формат пакета; доступность не сводится к работе сайта, RPC-узла или API проекта.

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

Как это работает

  1. Определите утверждение до измерения: точный пакет, blob, пространство имен или кодированный объект данных; протокол и версию; предполагаемого потребителя; требуемую задачу вывода, проверки или выхода; окна доступности, оспаривания и восстановления. Полнота означает достаточность данных по правилам этого протокола, а не неопределенную копию каждой транзакции.
  2. Зафиксируйте путь и доказательства публикации: расчетную сеть, специализированную сеть DA, calldata, blob sidecar, внешнее обязательство или сертификат комитета; идентификаторы блока, слота и пакета; кодирование и сжатие; обязательство; контракт или мост, который его использует. Публикация в одном месте не доказывает, что другой верификатор ее проверяет.
  3. Независимо проверьте связывание и реконструкцию. Получите байты без API проекта, проверьте их hash, KZG или иное обязательство и ссылку включения, валидируйте фрейминг и стирающее кодирование, декодируйте пакет и воспроизведите входные данные для вывода состояния. Валидное обязательство без байтов не является успешной реконструкцией.
  4. Опишите модель принятия. Запишите, загружают ли полные узлы объект, выбирают ли легкие узлы аутентифицированные доли, несут ли валидаторы обязанности хранения или подписывает ли комитет доступности данных пороговый сертификат. Укажите предположения о выборке, стирающем кодировании, независимости пиров, пороге, стейке, ключах и eclipse-атаках, а также что именно проверяет расчетный контракт или мост.
  5. Отслеживайте отдельные состояния и часы: отправлено, включено, доступно в окне протокола, извлекается независимыми клиентами, декодировано или выведено, валидно по исполнению, безопасно, финализировано и архивировано. Доказательство валидности может подтвердить вычисление с ограничениями, хотя данные для независимого вывода или работы останутся недоступными.
  6. Измерьте хранение, начальную синхронизацию и экономику. Запишите протокольный минимум обслуживания, правила удаления, поставщиков архивов и снимков, требования нового узла, сырые и кодированные байты, накладные расходы, цену единицы, стоимость доказательств и транзакций, лимиты емкости, субсидии и стоимость резервного пути. После истечения временной DA долговременное извлечение становится дополнительной зависимостью.
  7. Отрепетируйте сбои. Проверьте сокрытие и избирательную выдачу данных, коррелированные или изолированные выборки, потерю комитета, остановку или форк DA, реорганизацию расчетной сети, пропущенные фреймы, потерю архива, цензуру секвенсора и скачки комиссий. Подтвердите безопасную остановку, принудительное включение, повтор, резервный путь, реконструкцию и выход на реальном ПО, данных и газе, затем сохраните обязательства, квитанции и независимые архивные доказательства.

Разбор примеров

  • Правильные единицы стоимости данных. Пакет содержит 400,000 bytes, охватывает 2,000 transactions и стоит $0.00002 per byte. Плата DA за данные равна 400,000 * $0.00002 = $8 per batch, или $8 / 2,000 = $0.004 per transaction. Если цена единицы вырастет в десять раз до $0.00020 per byte, стоимость составит $80 per batch и $0.040 per transaction, а не $0.04 per batch. Исполнение, доказательство, транзакционные накладные расходы, архивирование и маржа не учтены.
  • Окно обслуживания протокола не обещает архив. Минимальное окно запроса EIP-4844 равно 4,096 epochs; при 32 slots per epoch и 12 seconds per slot это 4,096 * 32 * 12 = 1,572,864 seconds, или 1,572,864 / 86,400 = 18.2044444444 days. Это протокольный минимум в данной модели, а не гарантия вечного хранения конкретного blob одним поставщиком.
  • Упрощенная вероятность выборки. Только для условной модели предположим, что злоумышленник скрывает 50% равномерно выбираемых расширенных долей, а 30 аутентифицированных выборок независимы и выполняются с возвращением. Вероятность, что все выборки минуют скрытую область, равна 0.5^30 = 0.0000000009313225746; вероятность обнаружения составляет 99.9999999069%. Это не гарантия обслуживания действующего PeerDAS или другой сети: корреляция пиров, смещение выборки, параметры кодирования и адаптивные атаки меняют результат.
  • Порог комитета не равен текущей извлекаемости. Условному комитету DA требуется 5-of-7 подписей. Если три участника недоступны, остается только 4, поэтому новый пороговый сертификат сформировать нельзя. Старый сертификат с 5 signatures подтверждает, что порог дал аттестацию по своим правилам; он не доказывает, что конкретный пользователь может извлечь байты сейчас, что исполнение было валидным или что расчет финализирован.

Риски

  • Проверка неверной сети, пакета, blob, пространства имен или версии протокола.
  • Подмена исходных байтов обязательством или сертификатом.
  • Принятие текущего извлечения из одного узла за общепротокольную доступность.
  • Принятие доступности данных за доказательство валидности исполнения.
  • Принятие доступности или валидности за финальность консенсуса.
  • Ссылка на устаревший, небезопасный или реорганизованный расчетный блок.
  • Пропуск протокольного окна хранения до получения данных.
  • Зависимость от одного архива, снимка, индексатора или API проекта.
  • Принятие неправильного фрейминга, сжатия или стирающего кодирования.
  • Отсутствие проверки hash, KZG или иного обязательства.
  • Недостаточная выборка для заявленной модели угроз.
  • Предположение о независимости коррелированных выборок, пиров или групп хранения.
  • Eclipse-атака, смещенный выбор пиров или избирательная выдача.
  • Параметры стирания или пороги реконструкции, несовместимые с верификатором.
  • Зависимость от сговорившегося или недоступного комитета DA.
  • Принятие мостом или расчетным контрактом более слабого объекта, чем ожидают пользователи.
  • Потеря данных из-за сокрытия секвенсором, цензуры или отсутствующих фреймов пакета.
  • Остановка, форк или реорганизация DA либо несовместимое обновление клиента.
  • Неисполнимость принудительного включения, резервного пути, восстановления или выхода.
  • Недооценка емкости, скачков комиссий, накладных расходов, стоимости архива или окончания субсидий.

Распространенные заблуждения

  • Доказательство валидности устраняет потребность в доступности данных.
  • Обязательство или доказательство KZG подтверждает доступность полных байтов.
  • Финализированное включение означает постоянную извлекаемость данных.
  • Метки on-chain, blob, специализированная DA или выборка автоматически дают одинаковую безопасность.
  • Большее число выборок или меньшая стоимость сами по себе доказывают превосходство дизайна DA.

Связанные темы

Источники

Навигация

Поиск по вики...