ZK-STARK Application Development
ZK-STARK proofs appeared in 2018 in work by Eli Ben-Sasson and team from Technion. Key difference from SNARK: no trusted setup, quantum-resistant, scale better on large computations. You pay with proof size — a STARK proof weighs 40-200 KB vs 200 bytes for Groth16 SNARK. In practice this is critical for on-chain verification.
STARK vs SNARK: When to Use What
The question "STARK or SNARK" is wrong. Right question — for what task, with what computation volume, what on-chain verification requirements.
| Parameter | ZK-STARK | ZK-SNARK (Groth16) | SNARK (PLONK/Halo2) |
|---|---|---|---|
| Trusted setup | No | Yes (per-circuit) | No (universal) |
| Proof size | 40-200 KB | ~200 bytes | 1-10 KB |
| EVM verification | Expensive (~500K gas) | Cheap (~200K gas) | Medium (~300K gas) |
| Quantum resistance | Yes (hash-based) | No (elliptic curve pairings) | No |
| Proving speed | Fast on large circuits | Slow | Medium |
| Stack | Cairo/Miden, Winterfell | circom/snarkjs, gnark | Halo2, Plonky2 |
For a public rollup with Ethereum verification, STARK loses to SNARK on verification cost. StarkNet solves this via recursion: hundreds of STARK proofs aggregate into one, whose verification costs ~500K gas for the entire batch. For an isolated ZK-app verified on EVM once per proof, SNARK is often more practical.
Where STARK wins unconditionally: large computations (>10^6 steps), post-quantum security requirements, government and enterprise projects where trusted setup is politically unacceptable.
How STARK Proof Works
Understanding internal mechanics is needed by developers writing circuits, because errors in constraint systems produce either incorrect proofs or proofs that never verify.
Arithmetization. Computation is translated into a system of polynomial constraints. Each computation step is a row in an execution trace — a table where columns are registers, rows are time steps. Constraints link rows together.
FRI (Fast Reed-Solomon IOP). Verifier doesn't check entire trace — that would be expensive. Instead, prover commits to low-degree polynomial via FRI protocol, verifier makes random queries. Security is based on hash collision-resistance (usually Keccak or Poseidon), not discrete logarithm assumptions.
Recursion. One STARK proof can prove correctness of another STARK proof's verification. This provides logarithmic aggregation: 1000 proofs → 1 recursive proof.
Development Tooling
Cairo + Starknet Prover
Most mature production-ready stack for STARK apps. Cairo VM generates execution trace, then proved via STWO prover (new, Rust) or Stone prover (legacy). Key details:
-
Builtins — hardware accelerators for expensive operations:
range_check,bitwise,hash (Pedersen/Poseidon),ec_op,ecdsa. If circuit needs many hashes, choice between Pedersen and Poseidon affects proof cost. - Poseidon hash preferred for circuit-friendly operations: designed for ZK systems, ~3x more efficient than Pedersen in Cairo.
- Hints — Cairo mechanism allowing prover-side computation without proof, as long as constraint system still verifies result. Hints speed up proving but require care: incorrect hints compromise correctness.
Winterfell (Rust)
Library from Polygon Miden for building custom STARK systems in Rust. Suitable when you need control over every parameter: domain size, hash function choice, custom AIR (Algebraic Intermediate Representation). Performance is excellent — Winterfell generates proofs for Fibonacci sequence of 10^6 steps in ~2 seconds on modern hardware.
Entry barrier is high: need to understand AIR design, boundary constraints, transition constraints. Error in constraint system (incomplete coverage) creates soundness vulnerability — verifier accepts incorrect proofs.
Miden VM
Stark-based virtual machine from Polygon, uses Winterfell under the hood. Higher-level than raw Winterfell — write Miden Assembly, get STARK proof. Good for ZK apps needing Turing-complete ZK execution without EVM constraints.
Soundness Vulnerabilities in ZK Circuits
This is the most critical section. Unlike regular smart contracts, a bug in ZK circuit can let a prover generate proof for an invalid statement — verifier accepts it. Auditors call this a soundness bug.
Underconstraint
Most common vulnerability. Constraint system doesn't fully restrict execution trace — freedom remains that attacker uses for forgery.
Example: circuit for range check 0 <= x < 2^64. If you forget constraint that x is represented in exactly 64 bits (not as negative number in different field), circuit accepts x = p - 1 (near max field value), which isn't in [0, 2^64).
Missing Boolean Check
Circuit uses selector as boolean flag (0 or 1), but doesn't constrain selector * (1 - selector) == 0. Attacker passes selector = 5 and breaks conditional logic.
Non-Deterministic Hints
Hints in Cairo can compute values not fully verified by constraints. If hint computes square root and constraint only checks sqrt * sqrt == n, constraint accepts both sqrt and -sqrt mod p. Need additional sign constraint.
Circuit Audit Process
Circuit auditing requires mathematical expertise regular smart contract auditors don't have. Specialized teams: Veridise (have public Cairo audits), Trail of Bits, Least Authority. Tools: Picus (formal verification for circom), Ecne (soundness checker). For Cairo there's minimal automated tooling — most findings come from manual analysis.
ZK Application Architecture
Typical ZK-STARK app architecture for blockchain:
Off-chain prover. Takes private inputs (witness) and public inputs, generates STARK proof. Most resource-intensive component — proving for non-trivial circuits requires tens of GB RAM and minutes. Production: dedicated proving servers, possibly GPU acceleration (STWO supports CUDA for some operations).
On-chain verifier. Smart contract verifying STARK proof and making decisions based on public outputs. For StarkNet verification happens natively on L2. For Ethereum L1 — custom verifier contract by StarkWare team or custom for specific STARK systems.
Prover network (optional). For decentralized apps — distributed prover network. Risc Zero and Gevulot build shared prover infrastructure you can plug into instead of running your own server.
Practical example: ZK-lottery where STARK proof proves winning number was computed by predetermined algorithm from committed seed. StarkNet contract verifies proof and pays prize. Private input — seed. Public input — committed seed (Pedersen hash), winning number. Constraints verify winning_number = hash_chain(seed, round) % max_tickets. Circuit size — ~50K Cairo VM steps. Proving time on standard server — ~3 seconds.
Blockchain Integration
StarkNet. Native Cairo/STARK environment. Contracts run in Cairo VM, proofs generated automatically by sequencer. Developer doesn't interact with prover — write Cairo, get ZK execution.
Ethereum via SHARP. StarkWare provides Shared Prover (SHARP) — service taking Cairo programs, proving them, verifying proofs on Ethereum. Used for StarkEx (dYdX v3, Sorare, Immutable X).
Risc Zero. STARK-based zkVM for arbitrary Rust/WASM programs with ZK proof generation. Verifier — EVM-compatible contract or Bonsai network. Good for ZK-coprocessor pattern: heavy off-chain computation with on-chain proof.
Timeline and Effort
ZK-STARK app development is non-linear. Basic circuit for simple computation (merkle proof, range check, hash preimage) — 1-2 weeks development and testing. Product ZK project with custom AIR system — 2 to 6 months full cycle from architecture to audit.
Critical stage — circuit audit. For production ZK apps audit is mandatory and takes 4-8 weeks with specialized team.
Cost calculated after detailed scope discussion: circuit type, target chain, proving time requirements, distributed prover infrastructure needs.