Skip to content

Back to the catalog

Faster, Aggregatable and Quantum Safe Privacy Pools
ethresear.charticle

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.

TL;DR Ports Tornado Cash to a post-quantum SNARK and proposes a seed-derived recovery protocol so existing pools survive a discrete-log break.
Document

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 --> F

Preconditions / 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