Optimistic vs ZK-rollup’ы: сравнение подходов к масштабированию Ethereum

Оптимистичные и ZK-rollup’ы: базовая идея

Optimistic rollup:

• оператор (sequencer) собирает транзакции, исполняет их на L2 и публикует батч данных на L1;
• состояние L2 считается корректным «оптимистично», пока никто не докажет обратное;
• в течение challenge-периода любой наблюдатель может подать fraud proof, пересчитать спорный участок и инициировать откат/штраф.

ZK-rollup:

• оператор собирает транзакции и исполняет их;
• параллельно строится криптографическое доказательство корректности (ZK-/validity-proof);
• на L1 публикуется только это доказательство (и/или сильно сжатые данные), и состояние L2 считается правильным, если proof успешно верифицирован.

Оба подхода опираются на безопасность Ethereum как слоя данных и консенсуса, но по-разному распределяют вычисления и риски.

Модель безопасности и доверия

С точки зрения доверия:

• Optimistic-rollup:
  • предполагает, что хотя бы один участник будет следить за цепочкой и подаст fraud proof при нарушении;
  • безопасность зависит от:
    • качества и децентрализации валидаторов/наблюдателей;
    • корректности механизма споров;
    • параметров challenge-периода.
  • если никто не оспорит некорректное состояние в отведённое время, оно закрепится.

• ZK-rollup:
  • корректность состояния условно гарантируется математическим доказательством;
  • безопасность зависит от:
    • корректности реализации провера;
    • криптографической прочности схемы доказательств;
    • защищённости trusted setup (если он есть);
  • даже если оператор злонамерен, он не может сгенерировать валидный proof для некорректного состояния (при условии безопасности схемы доказательства).

При этом в обоих случаях остаются:

• риски доступности данных (DA);
• риски централизации sequencer’а;
• риски мостов и UX-слоя поверх rollup’а.

Финализация и время вывода средств

Одно из ключевых практических отличий — латентность финализации и вывода:

• Optimistic-rollup:
  • вводит challenge-период (обычно от нескольких дней до недели) перед тем, как состояние L2 считается полностью финализированным на L1;
  • «медленный» мост L2 → L1 (канонический), который ждёт окончания challenge-периода;
  • вокруг появляются «быстрые мосты» и ликвидность провайдеров, которые выкупают L2-активы заранее, беря на себя риск спора и взимая за это комиссию.

• ZK-rollup:
  • как только proof принят на L1, соответствующий батч считается финализированным;
  • время вывода ограничено:
    • скоростью генерации доказательства;
    • частотой публикации proof’ов на Ethereum;
  • в идеале вывод может занимать значительно меньше времени, чем в optimistic-rollup’ах.

Фактически:

• optimistic-rollup’ы жертвуют временем финализации ради более простой и дешёвой модели доказательств;
• ZK-rollup’ы платят вычислительной сложностью proof’ов за более быстрое «жёсткое» подтверждение корректности.

Комиссии и масштабирование

С точки зрения комиссий:

• Optimistic-rollup:
  • каждый батч несёт в себе «сырой» или слабо сжатый набор транзакций;
  • доказательства споров строятся редко (только при challenge), но сами транзакции занимают место в calldata;
  • экономия достигается за счёт объединения транзакций, но газ за данные всё равно платится.

• ZK-rollup:
  • предъявляет дорогие вычислительные требования к оператору (построение proof’а);
  • может эффективнее сжимать данные, а proof часто имеет фиксированный или сублинейный размер относительно числа транзакций;
  • по мере развития железа и криптопримитивов стоимость proof’ов снижается.

Появление EIP-4844 и proto-danksharding (blob-данные) меняет экономику для обоих подходов:

• стоимость публикации данных для rollup’ов падает;
• для ZK-rollup’ов это вкупе с улучшением proving-стека делает модель всё более конкурентоспособной;
• для optimistic-rollup’ов удешевление данных тоже выгодно, но их модель всё равно завязана на длительный challenge-период.

Совместимость с EVM и разработка

Настоящая боль для ZK-rollup’ов — поддержка EVM:

• Optimistic-rollup’ы:
  • как правило, максимально EVM-эквивалентны (OP Stack, Arbitrum Nitro и др.);
  • используют тот же байткод, те же опкоды и семантику;
  • позволяют запускать контракты практически без переписывания.

• ZK-rollup’ы:
  • строят zkEVM — виртуальную машину, совместимую или эквивалентную EVM, но подходы различаются:
    • от «минимальных изменений» (EVM-equivalent) до «Solidity-совместимых, но внутренне других VMs»;
  • иногда требуют адаптации кода или tooling’а;
  • более сложны для аудита и формальной верификации (новые компоненты proving-системы).

С течением времени:

• zkEVM становятся всё ближе к полной эквивалентности;
• tooling (компиляторы, отладчики, анализаторы) подтягивается к уровню классического EVM;
• но на момент написания разработчикам проще стартовать в полностью EVM-эквивалентных optimistic-rollup’ах, если важно «минимум сюрпризов».

Риски и ограничения каждого подхода

Дополнительно:

• Optimistic-rollup’ы:
  • уязвимы к сценариям, где challenge-период истёк, а наблюдатели не успели/не захотели подать proof;
  • должны защищаться от grief-атак (спам-споры, блокирующие финализацию).

• ZK-rollup’ы:
  • опираются на сложные криптопримитивы и, иногда, на доверенный setup (trusted setup);
  • более чувствительны к багам в реализации prover/verifier’а и к ошибкам в схемах доказательства.

Как выбирать между optimistic и ZK-rollup’ами

Если смотреть глазами разработчика протокола или продукта:

• Критичен time-to-market и простота запуска?
  • EVM-equivalent optimistic-rollup часто проще стартовать:
    • зрелые инструменты;
    • понятный UX для пользователей;
    • готовые шаблоны деплоя.
• Важна латентность вывода и строгая финализация?
  • ZK-rollup’ы с частой публикацией proof’ов дают:
    • быстрые «жёсткие» финальные состояния;
    • более предсказуемый вывод без опоры на быстрые мосты.
• Нужна ли глубокая ZK-интеграция?
  • для приложений с ZK-логикой (zkML, приватные приложения, сложные offchain-вычисления) ZK-rollup может быть более естественной средой.

Со стороны пользователя:

• важно понимать, какой именно L2 используется:
  • принадлежит ли он к классической модели rollup с on-chain DA (rollup);
  • не является ли это validium/собственным DA-слоем;
• понимать, как устроен мост и какие риски он добавляет;
• проверять:
  • уровень централизации sequencer’а;
  • планы на децентрализацию;
  • кто контролирует апгрейды клиентов и контракты rollup’а.

Что будет дальше: сближение моделей

Тренды развития:

• Optimistic-rollup’ы:
  • улучшают механизмы fraud proofs;
  • интегрируются с новыми DA-решениями;
  • работают над сокращением реальной UX-задержки вывода (через более надёжные быстрые мосты и социальные схемы защиты).

• ZK-rollup’ы:
  • стремятся к полной EVM-эквивалентности;
  • снижают стоимость proof’ов (новые схемы, оптимизация под железо, специализированные чипы);
  • осваивают сценарии за пределами простого «L2-с масштабированием»: приватность, offchain-вычисления и др.

Вероятно, в будущем граница «optimistic vs ZK» станет менее жёсткой: часть rollup’ов может использовать гибридные схемы, а классическая дихотомия будет уступать место более тонкой классификации по DA, безопасности, децентрализации и UX.

См. также

• Layer 2: общая концепция
• Обзор экосистемы L2-rollup’ов
• Термін: rollup L2
• Optimistic rollup
• ZK-rollup
• Data Availability (DA)
• Validium
• Мосты между Ethereum и L2
• Архитектура Ethereum