From SNARKs to STARKs: Post-Quantum Privacy
Why UPP is migrating from Groth16 SNARKs to Circle STARKs — and why post-quantum security can't wait
The Starting Point: SNARKs Work, But for How Long?
UPP's privacy system uses Groth16 zk-SNARKs for on-chain proof verification. Every withdrawal and transfer requires a zero-knowledge proof that the user knows a valid note in the pool, that balances are conserved, and (optionally) that the origin address is on a compliance allowlist.
Groth16 proofs are remarkably efficient:
| Metric | Value |
|---|---|
| Proof size | ~200 bytes |
| Verification gas | ~230K |
| On-chain verifier | Single pairing check |
This efficiency comes from elliptic curve pairings over the BN254 curve. The security of the entire system rests on the assumption that the discrete logarithm problem (DLP) on BN254 is computationally intractable.
That assumption has an expiration date.
The Quantum Threat
Shor's Algorithm and Elliptic Curves
Shor's algorithm, running on a sufficiently large quantum computer, solves the discrete logarithm problem in polynomial time. This breaks:
- All pairing-based SNARKs (Groth16, PLONK over BN254/BLS12-381)
- All elliptic-curve key exchange (ECDH, used for stealth addresses)
- All ECDSA/EdDSA signatures (used for Ethereum transactions themselves)
The JVG Result (March 2026)
The Jesse-Victor-Gharabaghi (JVG) algorithm, published by AQTI in March 2026, demonstrated that RSA-2048 can be factored with approximately 8,200 qubits in about 11 hours, using a hybrid classical-quantum approach with Quantum Number Theoretic Transform (QNTT).
While current quantum hardware sits at roughly 1,000 qubits, this result significantly shortens the estimated timeline for practical quantum attacks on elliptic curve cryptography. The question has shifted from "if" to "when" — and the answer is measured in years, not decades.
Harvest Now, Decrypt Later
State-level adversaries are already storing encrypted communications and on-chain data for future decryption. Every BabyJubJub public key published with a SNARK transaction today is a permanent record that will become decryptable when quantum computers reach sufficient scale. This isn't speculative — "harvest now, decrypt later" (HNDL) is an acknowledged strategy by intelligence agencies including the NSA.
What's Vulnerable in UPP's SNARK Architecture
Not everything breaks. The vulnerability is concentrated in the cryptographic primitives layer — specifically, anything that relies on elliptic curve hardness.
Critically Vulnerable (ECDLP-dependent)
| Component | Implementation | Why Vulnerable |
|---|---|---|
| Proving system | Groth16 on BN254 | Soundness relies on DLP; quantum attacker could forge proofs |
| Key management | BabyJubJub (twisted Edwards) | Private keys extractable from public keys |
| Stealth addresses | ECDH on BabyJubJub | Shared secrets computable from ephemeral pubkeys |
| Viewing keys | BabyJubJub scalar multiplication | DVK/EVK derivation relies on ECDLP |
| Note encryption | ECDH shared secret → AES-GCM | ECDH part breaks; AES-GCM itself is fine |
Quantum-Resistant (Hash/Symmetric-based)
| Component | Implementation | Why Safe |
|---|---|---|
| Poseidon hash | Algebraic hash over BN254 field | Collision resistance is hash-based |
| Merkle trees | Poseidon-based LeanIMT (32 levels) | Hash-based structure |
| Nullifiers | Poseidon(secret, leafIndex, commitment) | Hash preimage resistance survives quantum |
| Note commitments | Poseidon(amount, owner, blinding, origin, token) | Hash-based hiding/binding |
| AES encryption | AES-256-GCM | Grover halves security to 128-bit, still adequate |
The Core Insight
The protocol logic — UTXO model, nullifiers, Merkle inclusion proofs, ASP compliance, ragequit guarantees — is fundamentally quantum-resistant by design. These are all hash-based constructions. The vulnerability is entirely in the elliptic curves used for proofs and key management.
This means a migration to post-quantum cryptography preserves all of UPP's privacy and compliance guarantees. The protocol doesn't change. Only the underlying primitives do.
Why STARKs
STARKs (Scalable Transparent Arguments of Knowledge) are the natural replacement:
| Property | SNARK (Groth16) | STARK |
|---|---|---|
| Security assumption | Elliptic curve DLP | Hash collision resistance |
| Post-quantum secure | No | Yes |
| Trusted setup | Required (Powers of Tau) | Not required |
| Proof size | ~200 bytes | ~5 KB |
| Verification gas | ~230K | ~20M |
| Prover speed | 10-30s (browser) | ~2ms (native) |
STARKs are more expensive to verify on-chain today. But they are the only production-ready path to post-quantum zero-knowledge proofs on Ethereum. The gas premium is the cost of quantum resistance.
Our Approach: Native Solidity Verification
Rather than waiting for hypothetical EVM precompiles or wrapping STARKs through intermediary systems, we built a native Circle STARK verifier in Solidity — the first of its kind on Ethereum L1.
The verifier is built on Stwo, StarkWare's next-generation prover framework, which uses the Mersenne-31 field () and the circle group for its evaluation domain. We implemented a custom Keccak-256 channel to replace Stwo's default Blake2s, leveraging Ethereum's native keccak256 opcode for a 100x gas reduction in hash operations.
The system currently supports two circuit types through a parameterized verifier:
| Circuit | Trace Width | Constraints | Purpose |
|---|---|---|---|
| Withdraw | 46 columns | 5 | Spend a note, withdraw funds to a public address |
| Transfer | 57 columns | 6 | Spend a note, create two new private output notes |
For the full technical details, see the Circle STARK Verifier documentation.
Migration Phases
Phase 1: Hash-Based Shield (Complete)
- Replaced BabyJubJub key derivation with Keccak hash for STARK accounts
- New commitment format:
Keccak(amount, ownerHash, blinding, origin, token) - Shield operations work end-to-end without ZK proofs
Phase 2: STARK Proving (Complete)
- Built native Circle STARK verifier in Solidity (7 libraries, ~1,900 lines)
- Implemented withdraw and transfer circuits in Rust (Stwo prover)
- End-to-end verification on Ethereum L1 at ~20M gas
- 72 tests passing, parameterized for multiple circuit configurations
Phase 3: Full STARK Integration (Next)
- Replace remaining Groth16 circuits (merge, joinsplit, merge-transfer variants)
- Production deployment with optimized gas usage
- Browser-based STARK proving via WASM
Phase 4: Post-Quantum Key Management (Future)
- Replace ECDH stealth addresses with ML-KEM or hash-based alternatives
- Update note encryption for post-quantum key exchange
- Update viewing key architecture
The Urgency
Post-quantum migration is not a future problem. It is a present one.
Every SNARK proof published on-chain today embeds ephemeral elliptic-curve public keys. These keys are stored permanently in Ethereum's state history. When quantum computers reach sufficient scale, every historical transaction becomes retrospectively deanonymizable.
The window for proactive migration — before harvest-now-decrypt-later becomes harvest-now-decrypt-now — is narrowing. UPP's Circle STARK verifier is a working implementation of the path forward.