
Faster, Aggregatable and Quantum Safe Privacy Pools
Ethresear.ch post porting Tornado Cash to Flock, a post-quantum binary-field SNARK, proving a depth-32 SHA-256 withdrawal in about 19.5 ms (203.6 KiB proof), with recursive aggregation at about 0.68 s per withdrawal. It also proposes a ZIP 2005-inspired recovery protocol: wallets derive note secrets from a seed, the pool freezes on a discrete-log break, and users withdraw through a post-quantum verifier. Security is argued under an epoch assumption, with Grover-bounded pre-image attacks.
What it is
An Ethresear.ch post, written with winderica, that ports a Tornado Cash-style pool to Flock, a transparent, hash-based binary-field SNARK, and adds a recovery protocol for existing pools. Both address a quantum discrete-log break, which would defeat the pool's Pedersen commitments and Groth16 proofs. The post's headline says "under 30 ms" for a depth-32 withdrawal. The body measures 19.5 ms.
How it works
Circuit design. A depth-32 withdrawal needs 34 SHA-256 compressions: one commitment, one nullifier hash and 32 Merkle nodes. A single monolithic circuit with all 34 worked but wasted Flock's batching strength. The authors instead wrote one circuit with a single compression and a multiplexer. A private bit swaps the input order, so the same circuit serves all three roles. A sumcheck-based glue argument links the 34 invocations. At depth 32 this made proving 28× faster than the monolithic version.
Depth scaling. Prover time barely changes with tree depth. Circuit size does not depend on depth, and Flock's shipped Ligerito configs need a committed witness of at least 2^22 bits. Depths from 8 up to about 126 therefore share one witness size.
Aggregation. Flock's upstream repository recently gained a recursion layer. Each user proves their own withdrawal locally, and an aggregator folds the proofs into one. The final proof attests to the withdrawal count and a digest over every (nullifier hash, root). Final proof size and verification time stay constant. The aggregator's cost is about 0.68 s per withdrawal. The authors expect this to work alongside in-mempool aggregation.
Recovery protocol (inspired by ZIP 2005).
- Wallets stop sampling the two 248-bit values (k, r) at random. They derive k || r = H(s) from a 256-bit seed s, with H(s) = truncate(SHA512(s), 496). The commitment stays C = Pedersen(k || r).
- When a cryptographically relevant quantum computer becomes public knowledge, the pool freezes. Users then withdraw through a recovery verifier.
- With a post-quantum SNARK, a user proves knowledge of s such that C is in the Merkle tree and h = Pedersen(k).
- The nullifier hash is unchanged, so one spent-nullifier set covers both paths and a note spent before the freeze cannot be spent again.
flowchart TD
A[Deposit with seed-derived k, r] --> B{Freeze triggered?}
B -- No --> C[Old Groth16 withdrawal]
B -- Yes --> D[Old verifier disabled]
D --> E[Recovery proof of seed s]
C --> F[Shared nullifier set]
E --> FPreconditions / Affected
- Applies to Tornado Cash-like pools. Only notes whose secrets came from a seed can be recovered.
- The security argument uses an epoch assumption. The freeze must happen before the break, or the pool is drained through the old verifier.
- It assumes the pool's MiMC Merkle tree stays collision resistant against a quantum adversary.
- It models H as a random oracle and assumes Pedersen is close to uniform on uniform inputs.
- It needs a knowledge-sound post-quantum zkSNARK for the recovery verifier.
What to do
- Wallets: derive note secrets from a seed as above. This is the only deposit-side change.
- New pools: ship the recovery verifier together with the pool.
- Upgradeable pools: install the verifier through governance. The only privileged action should be a one-way freeze that disables the old verifier. The post says this can strand non-seed notes but cannot steal.
- Immutable pools: they cannot install a verifier. The post calls for a social-layer effort to move funds to pools that offer a recovery path.
Caveats
- The post gives measurements for 19.5 ms proving and a 203.6 KiB proof at depth 32. Hardware and the full tables are not in the text.
- Security is argued as intuition, not a full proof. After the freeze, the attacks are Grover searches costing about √(2^251 / m) evaluations of the seed-to-commitment map for double spends, and √(2^251 / l) for theft. Here m is the attacker's deposits and l is the honest users' deposits.
- Each commitment has about 32 seed pre-images, since 2^256 seeds map onto about 2^251 group elements. Excluding the attacker's own seeds barely changes the cost.
- The post calls Flock "plausibly" post-quantum, not proven.
Organisations named here
- babyjubjub
- epoch assumption
- leanVM
- Ligerito
- Pedersen commitment
- ZIP 2005
Technologies named here
- Existing upgradeable privacy pools
- Immutable privacy pools
- ZIP 2005
- leanVM aggregation work
- Tornado Cash
- Groth16
- SHA-256
- Zcash
- Ironwood
- Flock
Techniques named here
- Quantum discrete-logarithm break
- Single-circuit batching
- Grover's algorithm
Related in Blockchain

THORChain Exploit Report #2 — GG20 root-cause disclosure

Black Thursday revisited: MakerDAO keeper exploited for $500K
.jpg)