Faster, Aggregatable and Quantum Safe Privacy Pools

Introduction

Privacy pools such as Tornado Cash rely on discrete‑log‑based commitments and Groth16 proofs. If a sufficiently powerful quantum computer ever breaks the discrete logarithm, those pools become vulnerable. Recent advances in binary‑field SNARKs (e.g., Flock) and aggregation techniques make it feasible to replace the classical stack with post‑quantum primitives while retaining performance. This article outlines a working Tornado‑Cash‑like pool built on Flock, presents benchmark results, and proposes a lightweight recovery protocol that lets notes deposited today remain spendable after a quantum break.

A Faster, Aggregatable Post‑Quantum Pool

Minimal circuit design

A withdrawal from a Merkle tree of height 32 requires 34 SHA‑256 compressions (one for the commitment, one for the nullifier, and 32 for the Merkle path). Rather than encoding all 34 compressions in a single monolithic circuit, we construct a tiny circuit that performs one SHA‑256 compression and includes a private‑bit‑controlled multiplexer. The same circuit can serve as a commitment hash, a nullifier hash, or a Merkle node depending on the inputs.

By invoking this small circuit 34 times and linking the outputs with a sum‑check‑style glue argument, we keep the circuit size constant regardless of tree depth. Flock’s batch‑proving capability shines here: proving many copies of a tiny circuit is far more efficient than a single large one.

Benchmark highlights

| Tree depth | Monolithic proof time | Stepwise (batched) proof time | Speed‑up | |------------|----------------------|------------------------------|----------| | 8 | 0.23 s | 31.7 ms | 7.3× | | 20 | 0.50 s | 27.4 ms | 18× | | 32 | 0.81 s | 28.6 ms | 28× |

The prover time barely grows with depth because the circuit size is depth‑independent and Flock’s configuration fixes the witness size. This makes the system scalable to trees far deeper than those used today.

Recursive aggregation

Flock now supports a recursion layer. Each user generates an individual withdrawal proof (~19.5 ms, 204 KiB) on their own device. An aggregator then folds any number of these proofs into a single constant‑size proof (≈344 KiB) whose verification time stays around 60 ms. The aggregator’s wall‑clock cost grows linearly (~0.68 s per withdrawal), but the on‑chain verification cost remains constant, enabling efficient batch withdrawals in mempool‑level aggregators.

Quantum‑Resilient Recovery Protocol

Seed‑derived notes

In the classic Tornado Cash deposit, a user samples two random 248‑bit strings \(k, r\) and forms a Pedersen commitment \(C = \text{Pedersen}(k\|r)\). To make notes recoverable after a quantum break, wallets should derive \(k\) and \(r\) from a 256‑bit seed \(s\):

``` H(s) = truncate(SHA‑512(s), 496) // 496 bits = 248 || 248 k‖r = H(s) ```

The commitment and nullifier are unchanged, but the secret randomness now comes from a deterministic function of the seed.

Freeze and recovery

When a credible quantum threat emerges, the pool is frozen: the classic verifier is disabled and a recovery verifier is enabled. Users submit a post‑quantum zk‑SNARK proof that they know a seed \(s\) such that:

1. \(C = \text{Pedersen}(k\|r)\) with \(k\|r = H(s)\) appears in the Merkle tree, and
2. the nullifier \(h = \text{Pedersen}(k)\) matches the one they publish.

Because the nullifier is unchanged, the contract continues to track spent nullifiers, preventing double‑spending of notes that were already withdrawn before the freeze.

Security intuition

• No double‑spend: An attacker would need a second‑pre‑image on the seed‑to‑commitment map \(F(s)=\text{Pedersen}(H(s))\). Each commitment has about \(2^{245}\) openings, and a fresh seed lands in that set with probability \(2^{-251}\). Grover search therefore requires roughly \(\sqrt{2^{251}/m}\) evaluations for \(m\) attacker‑controlled notes, which is infeasible for realistic \(m\).
• No theft: The same analysis applies to honest users' notes (\(l\) of them). A quantum adversary must find a seed that maps to an honest commitment, costing \(\sqrt{2^{251}/l}\) Grover iterations.
• Spendability: Honest users retain the original seed, so they can recompute \(k\|r\) and produce a valid recovery proof.

The protocol assumes an epoch model: before the freeze the adversary is classical (Groth16 remains sound); after the freeze the adversary knows all discrete logs but cannot forge the post‑quantum SNARK proofs.

Practical Deployment Considerations

• Integration: New pools should ship the recovery verifier alongside the main contract. Existing upgradeable pools can add it via governance; immutable pools would need a community‑driven migration to a pool that supports recovery.
• One‑way freeze: The freeze action must be irreversible and only disable the old verifier. It must not grant the governance entity any ability to withdraw funds.
• User experience: Wallets need a tiny update to derive note secrets from a seed. The change is backward‑compatible: notes created before the update remain spendable via the classic path until a freeze occurs.
• Future‑proofing: While we use SHA‑256 for the Merkle tree and nullifier derivation (still believed quantum‑resistant as a hash), the design allows swapping in any hash function that remains collision‑resistant against quantum attacks.

Conclusion

By re‑architecting the withdrawal circuit for batch proving, leveraging Flock’s binary‑field SNARK, and adding a seed‑derived recovery mechanism, we demonstrate that privacy pools can become both faster and quantum‑safe without sacrificing usability. The approach preserves existing funds, enables efficient aggregation, and offers a clear migration path for the broader Ethereum privacy ecosystem.