Разработка ZK-STARK приложений

Разработка ZK-STARK приложений

ZK-STARK доказательства появились в 2018 году в работе Eli Ben-Sasson и команды из Technion. Ключевое отличие от SNARK: нет доверенной установки (trusted setup), квантовоустойчивы, масштабируются лучше на больших вычислениях. Платите за это размером доказательства — STARK-пруф весит 40-200 KB против 200 байт у Groth16 SNARK. На практике это критично при верификации на L1.

STARK vs SNARK: когда что выбрать

Вопрос «STARK или SNARK» неверный. Правильный вопрос — под какую задачу, с каким объёмом вычислений, с какими требованиями к верификации на чейне.

Для публичного роллапа с верификацией на Ethereum STARK проигрывает SNARK по стоимости верификации. StarkNet решает это через рекурсию: сотни STARK-доказательств агрегируются в одно, верификация которого стоит ~500K gas на весь батч транзакций. Для изолированного ZK-приложения, которое верифицируется на EVM за каждое доказательство отдельно, SNARK часто практичнее.

Там, где STARK выигрывает безоговорочно: вычисления с большим числом шагов (>10^6 шагов), контексты с требованием пост-квантовой безопасности, государственные и enterprise проекты где trusted setup неприемлем политически.

Как устроено STARK-доказательство

Понимание внутренней механики нужно разработчику, который пишет circuits, потому что ошибки в constraint системе дают либо некорректные доказательства, либо доказательства, которые никогда не верифицируются.

Arithmetization. Вычисление переводится в систему полиномиальных ограничений (constraints). Каждый шаг вычисления описывается как строка в execution trace — таблице, где столбцы — регистры, строки — такты. Constraints связывают строки между собой.

FRI (Fast Reed-Solomon IOP). Верификатор не проверяет весь trace — это было бы дорого. Вместо этого пруver обязуется к low-degree polynomial через FRI протокол, верификатор делает случайные запросы. Безопасность основана на collision-resistance хэш-функции (обычно Keccak или Poseidon), а не на допущениях о дискретном логарифме.

Рекурсия. Одно STARK-доказательство может доказывать корректность верификации другого STARK-доказательства. Это даёт логарифмическую агрегацию: 1000 пруфов → 1 рекурсивный пруф.

Инструментарий разработки

Cairo + Starknet Prover

Наиболее зрелый production-ready стек для STARK-приложений. Cairo VM генерирует execution trace, который затем доказывается через STWO prover (новый, написан на Rust) или Stone prover (legacy). Ключевые детали:

• Builtins — аппаратные ускорители Cairo VM для дорогих операций: range_check, bitwise, hash (Pedersen/Poseidon), ec_op, ecdsa. Если circuit требует много хэшей, выбор между Pedersen и Poseidon влияет на стоимость доказательства.
• Poseidon hash предпочтителен для circuit-friendly операций: разработан специально для ZK-систем, ~3x эффективнее Pedersen в Cairo.
• Hints — механизм Cairo, позволяющий прувер-side вычислять значения без доказательства их корректности, при условии что constraint система всё равно верифицирует результат. Hints ускоряют proving, но требуют осторожности: неправильно написанный hint может скомпрометировать корректность.

Winterfell (Rust)

Библиотека от Polygon Miden для построения кастомных STARK-систем на Rust. Подходит, когда нужен контроль над каждым параметром: размер домена, выбор хэш-функции, custom AIR (Algebraic Intermediate Representation). Производительность превосходная — Winterfell генерирует доказательства для Fibonacci sequence из 10^6 шагов за ~2 секунды на современном железе.

Порог входа высокий: нужно понимать AIR design, boundary constraints, transition constraints. Ошибка в constraint системе (неполное покрытие) создаёт soundness уязвимость — верификатор принимает некорректные доказательства.

Miden VM

Stark-based виртуальная машина от Polygon, использует Winterfell под капотом. Более высокоуровневый инструмент, чем raw Winterfell — пишешь на Miden Assembly, получаешь STARK-пруф. Хорошо подходит для ZK-приложений, которым нужен тьюринг-полный ZK-execution без EVM-ограничений.

Soundness уязвимости в ZK-circuits

Это самый критичный раздел. В отличие от обычного смарт-контракта, баг в ZK-circuit может позволить пруверу сгенерировать доказательство для невалидного утверждения — и верификатор примет его. Аудиторы называют это soundness bug.

Underconstraint

Самая частая уязвимость. Constraint система не полностью ограничивает execution trace — остаётся свобода, которую злоумышленник использует для фальсификации.

Пример: circuit для range check 0 <= x < 2^64. Если забыть constraint на то, что x представлен именно 64 битами (а не, например, как отрицательное число в другом поле), circuit принимает x = p - 1 (почти максимальное значение поля), что не входит в диапазон [0, 2^64).

Missing boolean check

Circuit использует переменную selector как boolean flag (0 или 1), но не constrains selector * (1 - selector) == 0. Злоумышленник может подать selector = 5 и сломать логику условного выполнения.

Не-детерминированные hints

Hints в Cairo могут вычислять значения, которые потом constraintами не полностью верифицируются. Если hint вычисляет квадратный корень, а constraint только проверяет sqrt * sqrt == n, то constraint принимает и sqrt = -sqrt mod p. Нужен дополнительный constraint на знак.

Процесс аудита ZK-circuits

Аудит ZK-circuits требует математической экспертизы, которой нет у стандартных smart contract аудиторов. Специализированные команды: Veridise (имеют публичные Cairo audits), Trail of Bits, Least Authority. Инструменты: Picus (formal verification для circom), Ecne (soundness checker). Для Cairo специфических инструментов автоматизированного аудита пока минимум — большинство находок приходит через ручной анализ.

Архитектура ZK-приложения

Типичная архитектура ZK-STARK приложения для блокчейна:

Off-chain prover. Принимает private inputs (witness) и public inputs, генерирует STARK-пруф. Это самый дорогой по ресурсам компонент — proving для нетривиальных circuits требует десятки GB RAM и минуты времени. Для production: выделенные proving серверы, возможно GPU-acceleration (STWO prover поддерживает CUDA для отдельных операций).

On-chain verifier. Смарт-контракт, который верифицирует STARK-пруф и принимает решения на основе public outputs. Для StarkNet верификация происходит нативно на L2. Для Ethereum L1 — custom verifier контракт, написанный командой StarkWare или кастомный для специфичных STARK-систем.

Prover network (опционально). Для децентрализованных приложений — распределённая сеть проверов. Risc Zero и Gevulot строят общую prover инфраструктуру, к которой можно подключиться вместо запуска собственного proving сервера.

Пример из практики: ZK-lottery, где генерируется STARK-пруф того, что winning number был вычислен по предопределённому алгоритму из committed seed. Контракт на StarkNet верифицирует пруф и выплачивает приз. Private input — seed. Public input — committed seed (Pedersen hash от seed), winning number. Constraint система проверяет, что winning number = hash_chain(seed, round) % max_tickets. Размер circuit — ~50K шагов Cairo VM. Proving time на стандартном сервере — ~3 секунды.

Интеграция с блокчейном

StarkNet. Нативная среда для Cairo/STARK. Контракты выполняются в Cairo VM, доказательства генерируются автоматически секвенсером. Разработчик не взаимодействует с prover напрямую — пишешь Cairo, получаешь ZK-execution.

Ethereum через SHARP. StarkWare предоставляет Shared Prover (SHARP) — сервис, который принимает Cairo programs, доказывает их, и верифицирует доказательства на Ethereum. Используется для StarkEx (dYdX v3, Sorare, Immutable X).

Risc Zero. STARK-based zkVM для выполнения произвольных Rust/WASM программ с генерацией ZK-пруфа. Верификатор — EVM-совместимый контракт или Bonsai сеть. Подходит для ZK-coprocessor паттерна: тяжёлые вычисления off-chain с пруфом результата on-chain.

Сроки и трудоёмкость

Разработка ZK-STARK приложения — нелинейная задача. Базовый circuit для простого вычисления (merkle proof, range check, hash preimage) — 1-2 недели на разработку и тестирование. Продуктовый ZK-прожект с кастомной AIR системой — от 2 до 6 месяцев на полный цикл от архитектуры до аудита.

Критичный этап — аудит circuit. Для production ZK-приложений аудит обязателен и занимает 4-8 недель у специализированной команды.

Стоимость рассчитывается после детального обсуждения scope: тип circuit, целевой чейн, требования к proving time, необходимость распределённой prover инфраструктуры.