STARKs vs. SNARKs: Why We Chose STARKs
Two Families of ZK Proofs
The two dominant zero-knowledge proof systems are SNARKs (Succinct Non-Interactive Arguments of Knowledge) and STARKs (Scalable Transparent Arguments of Knowledge).
Minerva uses STARKs. Here's why.
Comparison
| Property | SNARK | STARK |
|---|---|---|
| Trusted setup | Required | Not required |
| Post-quantum | No (relies on elliptic curves) | Yes (relies on hash functions) |
| Proof size | ~200 bytes | ~10-50 KB |
| Prover time | Moderate | Moderate-Fast |
| Verifier time | Very fast | Fast |
| Transparency | No (hidden setup parameters) | Full |
The Trusted Setup Problem
SNARKs require a one-time "ceremony" to generate proving parameters. If any participant in this ceremony retains their secret input, they can forge proofs.
This is a fundamental trust assumption that STARKs eliminate entirely. STARK parameters are derived from public randomness — no secrets, no ceremony, no trust.
Post-Quantum Security
SNARKs rely on elliptic curve pairings — mathematical structures that quantum computers can break using Shor's algorithm. When large-scale quantum computers arrive, all existing SNARK proofs become forgeable.
STARKs rely on collision-resistant hash functions. The best known quantum attack (Grover's algorithm) only provides a quadratic speedup — easily countered by doubling the hash output size.
Minerva's proofs will remain valid in a post-quantum world.
The Trade-Off: Proof Size
STARK proofs are larger than SNARK proofs (kilobytes vs. bytes). For on-chain verification where every byte costs gas, this matters.
For enterprise applications — audits, compliance, supply chain verification — proof size is irrelevant. A 50 KB file is trivial to store and transmit.
Minerva's Implementation
Minerva uses the Winterfell library (v0.13.1) — a production-grade STARK prover written in Rust.
Key parameters:
When to Choose SNARKs Instead
For everything else — especially enterprise compliance and privacy — STARKs are the better choice.