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

ZK-роллапы

Практическое руководство по пакетам ZK-роллапа, доказательствам корректности, доступности данных, стадиям расчёта, комиссиям, выводам и рискам конкретной реализации.

Обновлено

Только в образовательных целях; не является инвестиционной, мостовой или технической рекомендацией. Надёжность ZK-роллапа зависит от доказываемой программы, публичных входов, доступности данных, контрактов, операторов, управления и расчётной сети.

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

ZK-роллап, точнее роллап корректности, исполняет транзакции вне расчётной сети, объединяет их в пакеты и отправляет обязательства по данным, утверждения о состоянии и доказательства корректности её контрактам. Верификатор проверяет закодированные правила перехода без повторного исполнения каждой транзакции. Стоимость публикации и проверки распределяется по множеству транзакций.

Гарантия конкретна, а не абсолютна. Проверенное доказательство подтверждает только утверждение программы, связанное публичными входами. Само по себе оно не доказывает доступность данных, работоспособность и честность секвенсора, финальность блока, корректность моста или безопасность обновления. «ZK» также не означает приватность: многие роллапы публикуют транзакции или разницы состояния.

1
Выполнять

Доказывающая программа выполняет пакет или вычисление и записывает результирующий переход состояния.

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

  1. Зафиксируйте реализацию: ID L1 и L2, контракты роллапа и моста, верификатор и версию ключа, программу или схемы, формат пакета, режим DA, секвенсор, доказатель, администраторов, права паузы и блок наблюдения. Название стека не гарантирует свойства всех развёртываний.
  2. Разделяйте порядок и доказательство. Секвенсор может выдать квитанцию и блоки L2 до появления обязательства или доказательства в L1. Запишите точный пакет и различайте состояния: упорядочено, опубликовано, доказано, принято, безопасно, финализировано и вывод завершён.
  3. Восстановите пакет. Получите транзакции, разницы состояния, blob sidecar или иные обязательные данные; проверьте порядок и обязательства; выведите старый и новый корни, корень выводов или сообщений и публичные входы. Доказательство для неверной сети, пакета или корня подтверждает неверное утверждение.
  4. Проверьте путь доказательства. Убедитесь, что расчётная транзакция вызвала нужный верификатор с ожидаемыми доказательством, ключом и входами, успешно создала событие и обновила правильный слот. По возможности воспроизведите независимо.
  5. Отдельно проверьте доступность данных. Blob Ethereum дают доступность в окне протокола и обязательства, но не вечный архив. Внешний комитет или альтернативный DA добавляет допущения. Верное доказательство не восстанавливает утраченные данные для состояния или выхода.
  6. Проследите ввод и вывод полностью. Сверьте канонические токен и мессенджер, сумму, адрес, nonce, корень включения, доказательство, правило финальности и баланс. Быстрый мост авансирует ликвидность со своими ценой, маршрутом и риском контрагента, не сокращая канонический срок.
  7. Следите за работоспособностью и контролем. Измеряйте очередь пакетов и доказательств, принудительное включение и выход, разнообразие доказателей, обновления, таймлоки, хранителей и аварийные режимы. Повторяйте после каждого изменения.

Расчётные примеры

  • Сжатие. Учебный пакет содержит 10,000 transactions; 1,200 KB данных сжаты до 300 KB. Коэффициент 1,200 / 300 = 4.0x, сокращение 1 - 300 / 1,200 = 75%, среднее 300,000 / 10,000 = 30 bytes/transaction. Это не оценка надёжности, роста состояния или архива.
  • Распределение затрат. Пользователи платят 3.0 ETH; данные L1 стоят 1.4 ETH, проверка 0.4 ETH, исполнение L2 0.2 ETH. Остаток 3.0 - 1.4 - 0.4 - 0.2 = 1.0 ETH, среднее 3.0 / 10,000 = 0.0003 ETH/transaction. Это не чистая прибыль: не учтены доказательство, техника, сбои, мосты, капитал и налоги.
  • Жизненный цикл. Квитанция в minute 0, обязательство L1 в minute 12, доказательство принято в minute 50, политика финальности выполнена в minute 64, вывод исполнен в minute 70. Итого 12 + 38 + 14 + 6 = 70 minutes. Ранние стадии не равны завершённому выводу.

Риски

  • Неверная сеть, реализация, контракт, пакет, корень, верификатор, ключ или схема.
  • Неполная или ошибочная программа, верно доказанная надёжной системой.
  • Пропущенные или неверно кодированные входы, домены, сообщения или параметры.
  • Уязвимости верификатора, прекомпиляции, моста, мессенджера или состояния.
  • Компрометация setup или нарушение криптографических предположений.
  • Цензура, перестановка, противоречие, сбой или задержка секвенсора.
  • Сбой, централизация, цензура, нехватка мощности или очередь доказателя.
  • Недоступные, неверные или неархивированные транзакции, разницы или blob sidecar.
  • Подмена текущей доступности обязательством или подписью комитета.
  • Реорганизация L1 или преждевременное доверие небезопасному расчёту.
  • Привилегированные обновления, короткие таймлоки, замена, пауза или обход.
  • Отсутствующие, отключённые или непригодные принудительное включение и выход.
  • Ошибки моста, токена, повтор, сбой сообщения или доказательства вывода.
  • Ликвидность, цена, маршрут, неплатёжеспособность и контрагент быстрого моста.
  • Оценка без данных L1, доказательств, мостов, перегрузки или сбоев.
  • Перенос EVM-совместимости, финальности, приватности или защиты одного роллапа на другой.

Частые заблуждения

  • Любой ZK-роллап скрывает суммы, адреса и действия приложений.
  • Верное доказательство гарантирует данные и восстановление состояния.
  • Квитанция секвенсора равна принятому в L1 доказательству или финальному выводу.
  • Доказательства устраняют риски секвенсора, доказателя, управления, обновлений и мостов.
  • Самая дешёвая или быстрая система автоматически наиболее безопасна.

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

Источники

Навигация

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