---
title: "Оптимистические роллапы"
description: "Руководство с учетом конкретного развертывания: квитанции секвенсора, данные деривации L1, unsafe/safe/finalized heads, игры доказательств ошибки, канонические выводы, управление и быстрые выходы."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Оптимистические роллапы
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Оптимистический роллап исполняет упорядоченный поток транзакций и публикует заданные протоколом данные деривации и утверждения состояния, не прилагая доказательство корректности к каждому пакету. «Оптимистический» означает, что допустимое утверждение может продвигаться по правилам развертывания, пока успешный спор с доказательством ошибки не установит его неверность. Это не означает, что сообщение секвенсора доказывает корректность или что в каждой реализации оспаривание открыто всем и действует одинаковая задержка вывода.
Узлы роллапа независимо выводят блоки L2 из канонических входов L1 и точной конфигурации протокола. Поэтому путь безопасности включает доступность данных, правильную деривацию и исполнение, работающую и корректную систему доказательств ошибки, доступность и финальность L1, управление и мостовые контракты. Одного корня состояния недостаточно для восстановления цепочки или оспаривания неверного перехода.
## Как это работает
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 уже исполним.
- Быстрый мост сокращает канонический период оспаривания или несет только риск роллапа.
## Связанные темы
- [Доказательства ошибки](/ru/crypto/fraud-proof/)
- [Доступность данных](/ru/crypto/data-availability/)
- [Роллапы](/ru/crypto/rollup/)
## Источники
- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (дата обращения: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [Rollup Node](https://specs.optimism.io/protocol/rollup-node.html) - OP Stack Specification (дата обращения: 2026-08-13)
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification (дата обращения: 2026-08-13)
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification (дата обращения: 2026-08-13)
- [Optimism Portal](https://specs.optimism.io/fault-proof/stage-one/optimism-portal.html) - OP Stack Specification (дата обращения: 2026-08-13)
- [Stage 1 Roles and Requirements](https://specs.optimism.io/protocol/stage-1.html) - OP Stack Specification (дата обращения: 2026-08-13)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (дата обращения: 2026-08-13)
Source: https://wiki.fcontext.com/ru/crypto/optimistic-rollup/index.mdx