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

Оптимистические роллапы

Руководство с учетом конкретного развертывания: квитанции секвенсора, данные деривации L1, unsafe/safe/finalized heads, игры доказательств ошибки, канонические выводы, управление и быстрые выходы.

Обновлено

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

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

Оптимистический роллап исполняет упорядоченный поток транзакций и публикует заданные протоколом данные деривации и утверждения состояния, не прилагая доказательство корректности к каждому пакету. «Оптимистический» означает, что допустимое утверждение может продвигаться по правилам развертывания, пока успешный спор с доказательством ошибки не установит его неверность. Это не означает, что сообщение секвенсора доказывает корректность или что в каждой реализации оспаривание открыто всем и действует одинаковая задержка вывода.

Узлы роллапа независимо выводят блоки L2 из канонических входов L1 и точной конфигурации протокола. Поэтому путь безопасности включает доступность данных, правильную деривацию и исполнение, работающую и корректную систему доказательств ошибки, доступность и финальность L1, управление и мостовые контракты. Одного корня состояния недостаточно для восстановления цепочки или оспаривания неверного перехода.

1
Последовательность

Секвенсор заказывает транзакции L2 и публикует данные транзакций или обязательства.

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

  1. Зафиксируйте развертывание: chain ID L1 и L2, конфигурацию и форк роллапа, контракты inbox и моста, формат пакета и режим DA, контракты утверждений состояния и игр спора, версию портала, администраторов, guardian и блок наблюдения. Документация стека не подтверждает, что каждая функция активна в конкретной сети.
  2. Классифицируйте наблюдаемое состояние. Квитанция секвенсора или unsafe-блок — быстрое локальное обязательство порядка; опубликованный в L1 пакет может поддерживать безопасно выведенный head; финальность L1 может поддерживать finalized head деривации. Утверждение состояния или выхода, разрешенный спор и исполнимый вывод — отдельные объекты с разными часами.
  3. Восстановите конвейер деривации L1→L2. Проверьте депозиты и упорядоченные входы, каналы и пакеты, L1 origins, изменения конфигурации и переходы состояния по каноническим данным L1. Для blob-данных отличайте доступность в окне протокола от последующего архивного извлечения.
  4. Составьте карту доступности и управления. Разделите секвенсор, batcher, proposer, challenger, relayer, guardian и полномочия обновления; проверьте наличие путей forced inclusion или delayed inbox, их задержки и условия паузы, а также наличие рабочего ПО для обычных пользователей.
  5. Проверьте фактически развернутый путь доказательства ошибки. Запишите respected game type, права proposer и challenger, залоги, absolute prestate, программу доказательства и VM, preimage oracle, глубину утверждения, часы и продления, правила разрешения, права blacklist или pause и задержку обновления. Не переносите механику OP Stack на Arbitrum или другой роллап.
  6. Отдельно отслеживайте выводы и экономику. Проследите инициацию в L2, доказательство в L1, зависимость от утверждения или игры, задержки maturity и finality, повторное доказательство, проверки портала и исполнение в L1. Быстрый выход — отдельная платная сделка ликвидности или кредита с контрагентом, а не сокращенный канонический срок оспаривания.
  7. Постоянно сверяйте данные. Сопоставляйте хеши unsafe, safe и finalized блоков, пакетные транзакции L1, утверждения состояния, исходы игр, сообщения моста, квитанции, токен-контракты и конечные балансы. Возобновляйте анализ после реорганизации L1 или L2, пропавшего пакета, спора, паузы, обновления контракта или миграции DA.

Разобранные примеры

  • Полезная нагрузка деривации. Пакет содержит 10,000 транзакций, 1,200 KB исходных входов протокола и 300 KB после сжатия. Коэффициент равен 1,200 / 300 = 4.0x, сокращение — 1 - 300 / 1,200 = 75%, а десятичное среднее — 300,000 / 10,000 = 30 bytes/tx. Эти числа описывают только закодированные входные данные, а не газ L1, корректность исполнения, размер состояния или гарантии архива.
  • Вклад до неучтенных затрат. Пользователи платят 2.4 ETH; измеренное исполнение L2 стоит 0.3 ETH; DA в L1 — 1.2 ETH. Остаток равен 2.4 - 0.3 - 1.2 = 0.9 ETH, или 0.9 / 10,000 = 0.00009 ETH/tx. Это не чистая прибыль: не учтены инфраструктура оператора, исполнение L1, игры доказательств, возвраты, капитал, сбои и налоги.
  • Локализация спора. Учебная трасса исполнения содержит 2^20 = 1,048,576 шагов. Идеальное бинарное сужение требует log2(2^20) = 20 выборов для выделения одного шага. Если бы у каждого учебного раунда был отдельный максимум 3-hour, наивная последовательная граница составила бы 20 * 3 = 60 hours; реальные протоколы используют собственные шахматные часы, параллелизм, продления и расписание транзакций.
  • Часы вывода и быстрая ликвидность. Учебный пакет достигает L1 через 10 minutes, признанное утверждение — еще через 30 minutes, затем гипотетический период оспаривания длится 7 days, а финальная ретрансляция — 2 hours. Последовательное время равно 10 + 30 + 10,080 + 120 = 10,240 minutes = 7 days 2 hours 40 minutes. Мост ликвидности авансирует 4.97 ETH под требование 5 ETH и берет 0.03 ETH, то есть 0.03 / 5 = 0.6%; каноническое требование сохраняет исходные сроки и риски.

Риски

  • Неверные L1, L2, chain ID, конфигурация роллапа или развертывание контрактов.
  • Принятие unsafe-квитанции секвенсора за safe или final.
  • Противоречивые сообщения, цензура, переупорядочивание или простой секвенсора.
  • Задержанная, отсутствующая, некорректная или недействительная публикация пакета в L1.
  • Недоступность или отсутствие архива blob-данных либо альтернативной DA.
  • Несовпадение клиента деривации, конфигурации или форка.
  • Реорганизация L1, отменяющая ранее безопасные входы деривации.
  • Простой batcher, proposer состояния или участника доказательства.
  • Отсутствующий, приостановленный или неверно понятый forced-inclusion/delayed-inbox путь.
  • Неразвернутые, неактивные или привязанные не к тому game type доказательства ошибки.
  • Permissioned или allowlist-роли proposer либо challenger.
  • Challenger офлайн, подвергнут цензуре, недостаточно финансирован или пропустил срок.
  • Ошибка программы доказательства, VM, absolute prestate, oracle или verifier.
  • Ошибка часов, продления, позиции утверждения, залога или учета разрешения.
  • Вмешательство guardian, security council, pause или blacklist.
  • Немедленное обновление, короткий timelock или скомпрометированные ключи администратора.
  • Уязвимость канонического моста, messenger, replay-защиты или сопоставления активов.
  • Сбой доказательства вывода, maturity, повторного доказательства, финализации или relay.
  • Риск ликвидности, цены, маршрута, неплатежеспособности или контрагента быстрого выхода.
  • Смешение финальности L1, производной финальности L2, разрешения утверждения и получения актива.

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

  • Optimistic означает безусловное доверие пользователей результату секвенсора.
  • Публикация одного корня состояния обеспечивает доступность данных и независимую деривацию.
  • У каждого оптимистического роллапа активны permissionless fault proofs и единый семидневный срок.
  • Safe или finalized блок L2 означает, что вывод L2→L1 уже исполним.
  • Быстрый мост сокращает канонический период оспаривания или несет только риск роллапа.

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

Источники

Навигация

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