STARK Vault
Post-quantum secure vault using Circle STARKs — why SNARKs and STARKs coexist, and what makes the STARK system quantum-resistant.
STARK Vault
UPP provides two proof systems that operate side-by-side — not as competing alternatives or a migration path. They serve different threat models.
Two Proof Systems
| Metric | SNARK (PLONK/BLS12-381) | STARK (Circle STARK/M31) |
|---|---|---|
| Curve security | 128-bit (BLS12-381) | Hash-based (Keccak-256) |
| Gas per verification | ~200K | ~20M |
| Proof size | ~200 bytes | ~5 KB |
| Post-quantum secure | No | Yes |
| Trusted setup | Universal (Powers of Tau) | Not required |
| On-chain verification | EIP-2537 precompiles | Native Solidity |
| Use case | Everyday transfers | High-value, long-term storage |
SNARKs use PLONK over BLS12-381 (128-bit security, universal trusted setup via Powers of Tau — no per-circuit ceremony). They're for routine transfers where later exposure doesn't matter. STARKs are for high-value, long-term storage where future decryption must never happen.
Harvest Now, Decrypt Later
State-level adversaries are already storing on-chain data for future decryption. Every BabyJubJub public key published with a SNARK transaction today is a permanent record. The STARK vault provides protection against this threat — today.
What Makes STARKs Post-Quantum Secure?
SNARK security relies on the Elliptic Curve Discrete Logarithm Problem (ECDLP). Shor's algorithm, running on a sufficiently large quantum computer, solves ECDLP in polynomial time. This would break the BLS12-381 pairing used in PLONK verification. However, UPP's SNARKs use hash-based ownership (Poseidon, not BabyJubJub curve operations), so the note ownership model itself is not broken — only the proof verification would need migration.
STARK security relies on hash collision resistance (Keccak-256). No quantum algorithm provides a polynomial speedup against hash functions. Grover's algorithm halves effective security, but 128-bit security becomes 64-bit — still adequate for practical purposes.
The Circle STARK Implementation
Rather than waiting for hypothetical EVM precompiles, we built a native Circle STARK verifier in Solidity — the first of its kind on Ethereum L1.
Built on Stwo with custom modifications:
- Mersenne-31 field () — efficient Mersenne reduction
- Circle group evaluation domain — unique to Stwo
- Keccak-256 channel (replacing Stwo's Blake2s) — ~100x cheaper hashing on EVM
The verifier comprises 7 Solidity libraries (~1,900 lines total) and is parameterized for multiple circuit configurations (withdrawal: 46 trace columns, transfer: 57 trace columns).
Supported Circuits
| Circuit | Trace Width | Constraints | Purpose |
|---|---|---|---|
| Withdraw | 46 columns | 5 | Spend a note, withdraw to a public address |
| Transfer | 57 columns | 6 | Spend a note, create two private output notes |
Technical Documentation
The STARK section covers the full mathematical and implementation detail of each verifier component:
- Post-Quantum Analysis — which components are quantum-vulnerable, migration phases
- Field Arithmetic — M31 → CM31 → QM31 field tower, Solidity implementation
- FRI Protocol — Circle FRI folding, domain construction, pair reconstruction
- DEEP Quotients — out-of-domain quotient computation, line equations, periodicity samples
- Keccak Channel — Fiat-Shamir channel design, proof serialization format