Proof Systems
Groth16 today. STARK at Phase 3. Re-attestation in between.
Problem
Which zero-knowledge proof system does the chain use for shielded transactions and compliance attestations, and how does it migrate to a post-quantum destination?
Solution
Groth16 today. Hybrid in Phase 2. STARK at Phase 3.
| Phase | Proof system | Verifier cost | Setup |
|---|---|---|---|
| Phase 1 | Groth16 / BLS12-381 | Fast, small proofs | Trusted, per-circuit |
| Phase 2 | Groth16 + hash commitment | Slightly slower | Same as Phase 1 |
| Phase 3 | STARK (Reed-Solomon FRI) | ~ms verify, 100KB–200KB proofs | No trusted setup |
Phase 2 hybrid: each Phase 1 proof is accompanied by a hash-based commitment to the same circuit witness, allowing a verifier in Phase 2 to verify either or both. This buys integrity through the migration window without invalidating the existing on-chain proof inventory. Phase 3: STARK-based proofs for non-recursive applications; Plonky2-style or recursive STARK constructions for applications requiring proof aggregation. Lattice-based proof systems are tracked as a research alternative but not on the production path as of this writing.
Discussion
The proof-system migration is the most user-visible part of the cryptographic migration because every shielded transaction and every compliance attestation depends on it. The Groth16-to-STARK transition gives up some performance — STARK proofs are larger and slower to verify — but eliminates trusted setup as an attack surface and is the post-quantum destination.
100KB–200KB for typical circuits. Both numbers are improving. The cookbook will be updated when the production-side numbers move.
See Also
- § 6.2 · ZK Compliance Attestations — the application that depends most on this primitive
- § 6.5 · Re-attestation Under Primitive Change — how the proof migration shows up to the holder