ZK-Rollups: zkSync, StarkNet

Optimistic Rollups заставляют ждать 7 дней, надеясь, что никто не мошенничает. А что если можно доказать корректность математически за минуты? ZK-Rollups генерируют криптографическое доказательство, которое L1 проверяет за одну дешёвую транзакцию. Prover тратит миллионы долларов на GPU-кластеры, чтобы verifier на L1 потратил 1 на проверку. Эта асимметрия - фундамент масштабирования: создать доказательство сложно, проверить - мгновенно. Как математика заменяет доверие и почему гонка за самый быстрый proof определяет будущее блокчейна?

• **zkSync Era** обрабатывает транзакции за 0.02-0.07 с финализацией в минутах вместо 7 дней. Более 200 dApps развёрнуто, включая SyncSwap, Mute и SpaceFi
• **StarkNet** с языком Cairo обеспечивает самое быстрое proving и уже использовался dYdX v3 (StarkEx) для обработки 1T+ объёма торгов - каждый trade доказан криптографически
• **Proof markets** (Gevulot, =nil; Foundation) создают новый рынок вычислений: provers конкурируют за право генерировать ZK-доказательства, подобно тому как майнеры конкурировали за блоки в Bitcoin

Предварительные знания

• Rollups: the Scaling Idea

Validity Proofs: математика вместо ожидания

В уроке про Optimistic Rollups мы видели их главную проблему: **7-дневный challenge period**. Пользователь отправляет вывод средств и ждёт неделю, пока система убедится, что никто не оспорит результат. ZK-Rollups решают эту проблему радикально: вместо ожидания оспаривания они **доказывают корректность математически**. Каждый batch транзакций сопровождается **validity proof** - криптографическим доказательством того, что все state transitions выполнены корректно.

Разница в подходах фундаментальна. Optimistic Rollups используют **реактивную** модель: публикуют результат и ждут, что кто-то найдёт ошибку. ZK-Rollups используют **проактивную** модель: доказывают корректность **до** того, как L1 примет результат. Это как разница между проверкой контрольной работы учителем (ZK - каждая работа проверена) и системой «поставим всем пятёрки, а если кто-то пожалуется - пересмотрим» (Optimistic).

Validity proof гарантирует: «для каждой транзакции в batch существует корректный state transition, и финальный state root математически вытекает из начального state root и списка транзакций». L1 контракт получает proof, проверяет его за ~250K gas (одна дешёвая транзакция) и мгновенно принимает новый state root. Никакого ожидания, никакого доверия - чистая математика.

**Trusted setup - что это и почему это важно.** SNARK-системы (Groth16, PLONK) требуют одноразовой церемонии генерации параметров. Если хотя бы один участник церемонии уничтожил свой секрет - система безопасна. Но если ВСЕ участники сговорились - можно создавать фальшивые proofs. Zcash провёл знаменитую церемонию с 6 участниками, включая Эдварда Сноудена. STARK-системы не требуют trusted setup - параметры генерируются из публичной случайности. Это делает STARK «transparent» (прозрачными), что считается преимуществом для долгосрочной безопасности.

Гибридный подход набирает популярность. Polygon zkEVM и другие системы используют STARK-proof для основных вычислений (без trusted setup, лучшая масштабируемость), а затем оборачивают его в компактный SNARK-proof для дешёвой верификации на L1. Это позволяет получить лучшее от обоих миров: безопасность STARK и экономичность верификации SNARK.

Prover и Verifier: асимметрия вычислений

В центре ZK-Rollups лежит удивительная математическая асимметрия: **создание доказательства** (proving) требует колоссальных вычислений, а **проверка доказательства** (verification) - почти ничего. Это как разница между написанием романа и проверкой, что в нём 300 страниц. Prover (доказывающий) - мощный сервер или кластер GPU, работающий off-chain минуты или часы. Verifier (проверяющий) - смарт-контракт на L1, который проверяет proof за одну транзакцию.

Эта асимметрия - ключ к масштабированию. На L1 Ethereum, 500,000 валидаторов **каждый** выполняет **каждую** транзакцию. В ZK-Rollup один мощный prover выполняет все транзакции off-chain, генерирует компактный proof, и L1 проверяет **один proof вместо тысяч транзакций**. Чем больше транзакций в batch, тем дешевле каждая из них - стоимость верификации proof фиксирована (~250K gas), а делится на все транзакции.

**Централизация proving - текущая реальность.** В 2025 году и zkSync Era, и StarkNet, и Scroll используют централизованные provers, управляемые командами проектов. Если prover перестанет генерировать proofs - rollup остановится (транзакции на L2 выполняются, но не финализируются на L1). Децентрализация proving через proof markets - активная область исследований, но ни один production-ready протокол пока не развёрнут в mainnet.

**Proof markets** - рыночный механизм для децентрализации proving. Идея: любой участник с достаточным оборудованием может стать prover. Sequencer публикует задачу на генерацию proof, provers конкурируют по цене и скорости, победитель получает вознаграждение. Это создаёт рынок вычислений, аналогичный майнингу, но вместо бессмысленного перебора хешей provers выполняют полезную работу - доказывают корректность транзакций.

**Экономика proving.** Стоимость генерации proof для batch в 1000 транзакций на GPU-кластере составляет $5-50 (электричество + амортизация оборудования). Стоимость верификации на L1 - ~250K gas (~$0.50-2.00). Итого: ~$0.005-0.05 на транзакцию за proving + verification. Для сравнения: L1 транзакция на Ethereum стоит $1-10+. ZK-Rollup удешевляет транзакции в 20-200 раз, при этом наследуя безопасность L1.

zkEVM: четыре типа совместимости

Главная инженерная проблема ZK-Rollups: **EVM не был разработан для ZK-доказательств**. Ethereum Virtual Machine создавалась для выполнения транзакций, а не для того, чтобы каждый opcode можно было доказать в ZK-цепи. Opcodes вроде `KECCAK256` (хеширование) крайне неэффективны для ZK-proving, а `SELFDESTRUCT`, `DIFFICULTY`, `BLOCKHASH` вообще не имеют смысла в контексте L2. Поэтому создание «EVM, совместимого с ZK» - это инженерная задача с множеством trade-offs.

Виталик Бутерин в 2022 году предложил классификацию zkEVM на **четыре типа**, от полной эквивалентности Ethereum (Type 1) до языковой совместимости (Type 4). Каждый следующий тип жертвует совместимостью ради эффективности proving. Это не шкала «хуже-лучше» - это спектр trade-offs.

**zkSync Era** (Type 4) - яркий пример trade-off. Matter Labs создали свой компилятор **zksolc**, который компилирует Solidity не в стандартный EVM-байткод, а в промежуточное представление (IR), оптимизированное для ZK-proving. Это означает: Solidity-код компилируется и работает, но байткод отличается от EVM. Контракты, использующие inline assembly или EVM-специфичные хаки, могут не работать. Зато proving быстрый и дешёвый.

**StarkNet** пошёл дальше всех в направлении Type 4, создав собственный язык программирования - **Cairo**. Cairo спроектирован с нуля для ZK-proving: каждая операция эффективно доказуема, нет «тяжёлых» opcodes. Это даёт максимальную производительность proving, но требует от разработчиков учить новый язык. Cairo 2.0 стал похож на Rust (с ownership model), что упрощает миграцию Rust-разработчиков, но Solidity-разработчикам приходится начинать с нуля.

**Почему KECCAK256 - враг zkEVM.** Ethereum повсеместно использует KECCAK256: хеширование storage slots, адреса контрактов, Merkle Patricia Trie. Но KECCAK256 крайне неэффективен для ZK-circuits: одна операция KECCAK в ZK-proof требует ~150,000 constraints, в то время как ZK-friendly хеш Poseidon - всего ~250 constraints. Разница в 600 раз! Type 1 zkEVM вынужден доказывать KECCAK как есть (медленно). Type 2+ могут заменить внутренние хеши на Poseidon, сохраняя KECCAK только для совместимости с EVM opcodes.

Proof Generation: от circuit до on-chain верификации

Генерация ZK-proof - это превращение вычислительной задачи в математическое уравнение и нахождение его «свидетеля» (witness). Процесс начинается с **arithmetization** - преобразования программы (транзакций) в систему полиномиальных ограничений (**circuit**). Каждый opcode, каждое чтение из storage, каждая арифметическая операция становится набором constraints (ограничений). Чем больше транзакций в batch - тем больше constraints, тем дольше proving.

**Proof time** (время генерации) зависит от размера batch и сложности транзакций. Простой перевод ETH - ~500 constraints. Сложный DeFi-swap с чтением storage - ~50,000+ constraints. Batch из 1000 разнородных транзакций может содержать 10-100 миллионов constraints. GPU-ускорение критично: основные операции proving (Fast Fourier Transform, Multi-Scalar Multiplication) параллелизуются на GPU в 10-50 раз эффективнее, чем на CPU.

**Proof aggregation** (рекурсивные доказательства) - ключевая оптимизация. Идея: вместо одного proof на весь batch, prover генерирует маленькие proofs для частей batch, а затем создаёт **meta-proof**, который доказывает: «все маленькие proofs верны». Этот meta-proof верифицируется на L1 как единый proof. Рекурсия позволяет: 1. распараллелить proving на несколько машин 2. агрегировать proofs от нескольких batches в один, снижая L1 gas cost.

**Real-time proving - святой грааль ZK.** Сегодня proving занимает минуты. Цель - довести proving до уровня block time (~1-2 секунды), чтобы каждый блок L2 сразу сопровождался proof. Это устранит задержку финализации полностью. Несколько команд работают над этим: Succinct SP1, RISC Zero, Polygon Miden. Комбинация ASIC-ускорения, оптимизированных proof systems и параллелизации может достичь real-time proving к 2026-2027 году.

Стоимость proving снижается по закону, напоминающему закон Мура: каждый год proving дешевеет примерно в 2 раза за счёт алгоритмических оптимизаций (новые proof systems), аппаратного ускорения (GPU → FPGA → ASIC) и лучшей параллелизации. StarkNet в 2024 году снизил стоимость proving на 90% относительно 2023 года за счёт перехода на SHARP (Shared Prover) с рекурсивными proofs. Тренд однозначен: ZK-proving становится commodity-ресурсом.

Итоги

• **Validity proofs** заменяют 7-дневное ожидание Optimistic Rollups математической гарантией: prover генерирует proof, verifier на L1 проверяет за ~250K gas, state root финализируется мгновенно. SNARK - компактные proofs (300 bytes), но требуют trusted setup. STARK - больше (40-200 KB) и дороже для верификации, но transparent и квантово-устойчивые
• **Prover/Verifier асимметрия** - ядро масштабирования: prove = O(n log n) off-chain на GPU-кластере за минуты, verify = O(1) on-chain за ~$1. Стоимость proving делится на весь batch: 10,000 транзакций → ~$0.001 за верификацию каждой. Proof markets декентрализуют proving через конкуренцию provers
• **zkEVM Types 1-4** балансируют совместимость и скорость proving: Type 2 (Scroll, Polygon zkEVM) - полная EVM-эквивалентность, медленный proving. Type 4 (zkSync Era/Solidity→IR, StarkNet/Cairo) - максимальная ZK-эффективность, ограниченная совместимость. KECCAK256 в ZK = 600x overhead vs Poseidon
• **Proof generation** включает arithmetization (код → circuits), witness generation и polynomial commitments. GPU ускоряет proving в 25-30x vs CPU. Рекурсивные proofs агрегируют множество batches в один proof, фиксируя стоимость верификации на L1 независимо от объёма
• Математика из hook не просто метафора - ZK-Rollups буквально заменяют доверие ("подожди 7 дней, вдруг мошенник") математической уверенностью ("proof верифицирован, state root корректен"). Асимметрия prove/verify делает это экономически возможным: дорого доказать, дёшево проверить - и транзакции масштабируются без потери безопасности L1

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

ZK-Rollups находятся на пересечении криптографии, масштабирования L2 и инженерии EVM-совместимости:

• Rollups: введение — Фундамент ZK-Rollups: data availability, execution off-chain, settlement on L1. ZK-Rollups используют те же принципы, но заменяют fraud proofs на validity proofs
• Optimistic Rollups: Arbitrum, Optimism — Альтернативный подход к масштабированию: fraud proofs вместо validity proofs, 7-дневный challenge period вместо мгновенной финализации, полная EVM-эквивалентность без ограничений zkEVM
• Основы ZK-доказательств — Математический фундамент: zero-knowledge proofs, commitment schemes, interactive vs non-interactive proofs - теория, лежащая в основе SNARK и STARK систем
• zk-SNARK: глубокое погружение — Детальный разбор SNARK-системы: pairing-based криптография, Groth16, PLONK, trusted setup ceremonies - как именно генерируются и верифицируются компактные proofs

Вопросы для размышления

• Type 4 zkEVM (zkSync, StarkNet) жертвует совместимостью ради скорости proving, а Type 2 (Scroll, Polygon zkEVM) наоборот. Какой подход победит? Или рынок L2 достаточно велик для обоих, как Windows и macOS сосуществуют десятилетиями?
• Proving сегодня централизован - одна команда управляет GPU-кластером. Proof markets обещают децентрализацию, но создают новый вид «майнинга» (кто имеет больше GPU - тот зарабатывает). Не приведёт ли это к той же концентрации, что и в Bitcoin-майнинге?
• Если real-time proving станет реальностью (proof за <1 секунды), нужны ли будут Optimistic Rollups? Или их экосистемное преимущество (Arbitrum TVL, Base adoption) сделает технологическое превосходство ZK неважным?

Связанные уроки

• crypto-34-zkp-basics