Two families of zero-knowledge proof systems dominate modern cryptography and blockchain infrastructure. zk-SNARKs (Succinct Non-interactive Arguments of Knowledge) and zk-STARKs (Scalable Transparent Arguments of Knowledge) both enable a prover to convince a verifier that a computation was performed correctly, without revealing the inputs or intermediate values. Both are used in production systems processing billions of dollars in transactions.
But they are built on fundamentally different mathematical foundations, carry different trust assumptions, and make different tradeoffs between proof size, verification cost, prover complexity, and quantum resistance. The “S” in SNARKs and STARKs stands for different properties – “succinct” versus “scalable” – and that naming difference encodes a philosophical disagreement about what matters most in a proof system.
As of early 2026, zk-SNARKs (particularly Groth16 and PLONK variants) are used by Zcash, Filecoin, Mina Protocol, Polygon zkEVM, Scroll, and dozens of Ethereum Layer 2 rollups. zk-STARKs power StarkNet, StarkEx (dYdX, Sorare, ImmutableX), and are used in Cairo-based applications. The two families are converging: recent systems like Plonky2, Boojum, and RISC Zero combine elements of both. Understanding each in isolation is the prerequisite to understanding where the field is headed.
zk-SNARKs: The Pairing-Based Family
What “SNARK” Means
- Succinct: Proofs are small (constant or near-constant size) and verification is fast (constant or logarithmic time), regardless of the computation’s complexity.
- Non-interactive: The prover sends a single message (the proof) to the verifier. No back-and-forth communication.
- Argument: Soundness holds against computationally bounded adversaries (not information-theoretically).
- Knowledge: The prover not only proves that a statement is true but demonstrates possession of a “witness” (the secret input that makes the statement true).
Groth16: The Gold Standard
Groth16, published by Jens Groth in 2016, is the most efficient zk-SNARK in terms of proof size and verification time:
- Proof size: 3 group elements = ~128 bytes (on BN254) or ~192 bytes (on BLS12-381)
- Verification: 3 pairing computations = ~2-3 milliseconds
- Prover time: O(n log n), where n is the number of constraints
The mathematical foundation: the prover must demonstrate that a system of quadratic equations (a Rank-1 Constraint System, or R1CS) is satisfiable. This is transformed into a polynomial identity check at a secret evaluation point. The trusted setup ceremony generates the evaluation point (embedded in elliptic curve group elements), and the bilinear pairing enables the verifier to check the polynomial identity without knowing the evaluation point.
Groth16’s limitation: it requires a circuit-specific trusted setup. Every distinct computation needs its own ceremony. This is why Zcash ran separate ceremonies for Sprout and Sapling, and why Filecoin’s circuits each have dedicated parameters.
PLONK and Universal SNARKs
PLONK (2019) introduced a universal and updatable setup: a single ceremony generates parameters usable for any circuit up to a maximum size. The setup can be strengthened at any time by additional contributions.
PLONK uses a different arithmetization (PLONKish constraints instead of R1CS), which is more flexible – it supports custom gates, lookup tables, and copy constraints that map naturally to real computations. The proof system uses KZG polynomial commitments for succinct verification.
- Proof size: ~400-600 bytes
- Verification: ~1 pairing + O(1) scalar multiplications = ~3-5 milliseconds
- Prover time: O(n log n) with FFTs
PLONK variants (TurboPLONK, UltraPLONK, HyperPLONK, GeminiPLONK) optimize different aspects: custom gates reduce circuit size, lookup arguments enable efficient range checks, and recursive proof composition enables proof aggregation.
The Trust Issue
All pairing-based SNARKs require some form of structured reference string. Groth16 needs a circuit-specific SRS. PLONK needs a universal SRS. Both require a trusted setup ceremony where participants generate and destroy secret values.
The security assumption is “1-of-n honest”: if at least one ceremony participant destroyed their toxic waste, the SRS is secure. The Ethereum KZG ceremony (2023) had over 141,000 participants, making this assumption extremely strong. But “extremely strong” is not “unconditional.” A system that requires any trust assumption, no matter how distributed, is fundamentally different from one that requires none.
zk-STARKs: The Hash-Based Family
What “STARK” Means
- Scalable: Prover time is “quasi-linear” in the computation size – roughly O(n * polylog(n)). Verification time is O(polylog(n)), scaling sublinearly with computation complexity.
- Transparent: No trusted setup. The only public parameters are hash function specifications and the field characteristic. The “T” in STARK stands for “transparent.”
- Argument of Knowledge: Same as SNARKs – soundness against bounded adversaries, with a knowledge extractor.
Mathematical Foundation
STARKs are built on fundamentally different mathematics than SNARKs. Instead of elliptic curve pairings, STARKs use:
Algebraic Intermediate Representation (AIR). The computation is encoded as a set of polynomial constraints over an execution trace. Each row of the trace represents a step of the computation, and the constraints relate consecutive rows. For example, a constraint for the Fibonacci sequence would be: trace[i+2] = trace[i+1] + trace[i].
FRI Protocol (Fast Reed-Solomon Interactive Oracle Proof). The core of STARK verification. The prover commits to polynomial evaluations using Merkle trees (hash-based commitments). The FRI protocol then verifies, through a series of “folding” steps, that the committed values actually lie on a polynomial of the claimed degree.
Each FRI folding step reduces the polynomial degree by half, and the verifier checks consistency at random points. After log(d) folding steps (where d is the polynomial degree), the polynomial is reduced to a constant, which the verifier checks directly.
The security of FRI relies on the collision resistance of the hash function (typically SHA-256, BLAKE2, or Poseidon) and the distance properties of Reed-Solomon codes. No group structure, no pairings, no number-theoretic assumptions beyond hash function security.
Performance Characteristics
- Proof size: ~50-200 KB (depending on the computation and security parameter)
- Verification: ~2-10 milliseconds (O(polylog(n)) hash evaluations)
- Prover time: O(n * log^2(n)), faster than Groth16 for very large computations
- Post-quantum security: Yes (relies only on hash functions)
The Cairo VM
StarkWare developed Cairo, a programming language and virtual machine specifically designed for STARK-provable computation. Rather than compiling programs to circuits (the standard SNARK approach), Cairo programs run on a CPU-like architecture whose execution trace is directly amenable to AIR constraints.
This means developers write programs in a high-level language rather than designing circuits. The Cairo VM abstracts away the arithmetization entirely. StarkNet, the decentralized network running Cairo-based smart contracts, processes thousands of transactions per second with STARK proofs verified on Ethereum L1.
Head-to-Head Comparison
| Property | zk-SNARKs (Groth16) | zk-SNARKs (PLONK) | zk-STARKs |
|---|---|---|---|
| Proof size | ~128 B | ~400 B | ~50-200 KB |
| Verification time | ~3 ms | ~5 ms | ~5-10 ms |
| Prover time | O(n log n) | O(n log n) | O(n log^2 n) |
| Trusted setup | Circuit-specific | Universal, updatable | None |
| Post-quantum | No | No | Yes |
| Recursion | Complex | Moderate | Native |
| Maturity | 10+ years | 7 years | 7 years |
Proof Size: SNARKs Win
Groth16 proofs are ~128 bytes. STARK proofs are 50-200 KB – a factor of 400-1,600x larger. On Ethereum, where calldata costs ~16 gas per byte, a Groth16 proof costs ~2,048 gas while a 100 KB STARK proof costs ~1.6 million gas. This cost difference is why many Ethereum L2 rollups use SNARKs for on-chain verification, even if they use STARKs internally.
However, STARK proof sizes are improving. Proof compression techniques (DEEP-FRI, Stone prover optimizations) have reduced proof sizes by 50-80% since the first STARK implementations. Circle STARKs, introduced by StarkWare in 2024, use the M31 (Mersenne31) field to achieve smaller proofs and faster proving.
Prover Time: STARKs Scale Better
For computations with millions of constraints, STARK provers outperform SNARK provers because the bottleneck operation is FFT (Fast Fourier Transform) over the field, and STARKs use smaller fields (Goldilocks, M31) that fit in native 64-bit registers, while pairing-based SNARKs operate over 254-bit or 381-bit fields that require multi-precision arithmetic.
RISC Zero’s STARK prover for the RISC-V instruction set processes approximately 1 million cycles per second on a standard laptop. For a computation requiring 10 million steps, proof generation takes approximately 10 seconds. The equivalent Groth16 prover on a 381-bit field would take significantly longer.
Post-Quantum Security: STARKs Win
SNARKs based on elliptic curve pairings are vulnerable to quantum attack. Shor’s algorithm can compute discrete logarithms and pairings in polynomial time. A sufficiently powerful quantum computer would break Groth16, PLONK, and all pairing-based proof systems.
STARKs rely only on hash functions. The best known quantum attack on hash functions is Grover’s algorithm, which provides a quadratic speedup – reducing SHA-256’s security from 256 bits to 128 bits. This is addressed by using a 256-bit hash, which remains secure against quantum computers.
For applications that must remain secure for decades – land registries, identity systems, long-lived financial instruments – STARKs’ post-quantum security is a decisive advantage.
Transparency: STARKs Win
No trusted setup means no toxic waste, no ceremonies, no trust assumptions. The public parameters for a STARK proof system are deterministic functions of the security parameter and the hash function. Anyone can verify them. No one can subvert them.
This is not merely a philosophical preference. It is a practical consideration for decentralized systems where no entity should have privileged access to system parameters. The existence of a trusted setup introduces a permanent trust assumption that cannot be fully eliminated, regardless of how many participants contribute to the ceremony.
The Convergence: Hybrid Systems
The field is moving beyond the SNARK-vs-STARK dichotomy toward hybrid systems that combine the strengths of both.
Plonky2 (Polygon). Uses PLONK arithmetization with FRI-based polynomial commitments (instead of KZG). This gives PLONK’s flexible constraint system with STARK’s transparency and post-quantum security. Proof sizes are larger than KZG-based PLONK but smaller than full STARKs.
Boojum (zkSync). Uses a custom proof system combining PLONK-like constraints with FRI commitments over the Goldilocks field. Optimized for GPU proving with sub-second proof generation for typical transactions.
RISC Zero. Produces STARK proofs of arbitrary RISC-V program execution, then wraps the STARK proof in a Groth16 SNARK for on-chain verification. This gives STARK-level transparency and post-quantum prover security with SNARK-level on-chain verification cost.
SP1 (Succinct). Similar to RISC Zero but uses a different STARK architecture and supports SNARK wrapping for Ethereum verification.
The pattern is clear: use STARKs for proving (transparency, post-quantum prover, fast proving) and SNARKs for verification (small proofs, cheap on-chain verification). The STARK-to-SNARK wrapping introduces a trusted setup for the verification layer, but the proving layer remains transparent.
The Stealth Cloud Perspective
Stealth Cloud’s zero-knowledge architecture is named for its data handling philosophy – the server has zero knowledge of user data – rather than for the specific use of ZK proof systems. But the technologies are converging.
Consider the verification challenge: how does a user prove to the Stealth Cloud infrastructure that their prompt has been properly sanitized by the PII engine without revealing the prompt? How does the server prove to the user that it has destroyed session data without revealing what was destroyed? How does a third-party auditor verify the cryptographic shredding guarantee without accessing the data that was shredded?
Each of these is a zero-knowledge proof problem. The choice between SNARKs and STARKs depends on the specific constraints:
- For on-chain verification of privacy guarantees (e.g., proving that a session token was properly destroyed): SNARKs, for proof size and gas efficiency.
- For client-side proving of prompt sanitization: STARKs, for transparency (no trusted setup) and the ability to generate proofs in the browser without trusting external parameters.
- For long-term auditability of privacy claims: STARKs, for post-quantum security.
The zero-knowledge proof landscape is not a binary choice. It is a toolkit. The engineering challenge – and Stealth Cloud’s long-term architectural commitment – is selecting the right tool for each verification requirement, with transparency and post-quantum resilience as the default preferences for a platform whose privacy guarantees must outlast the current generation of computational capabilities.