Design a Privacy Coin Using Zero-Knowledge

Problem statement

Design a layer-1 privacy coin whose shielded transfers hide sender, receiver, and amount while still letting every full node verify three invariants in milliseconds: no double-spend, no hidden inflation, and only-well-formed notes enter the pool. The system must run two address spaces side by side - transparent addresses whose balances are public, and shielded addresses whose notes exist only as cryptographic commitments - and must let value move between them without leaking which shielded note funded a transparent output.

The core object is the shielded note. A note carries a value and a recipient key, is published only as a Pedersen-style commitment inside a global append-only Merkle tree, and is spent by producing a zero-knowledge proof that (a) the spender knows a note committed in some past tree root, (b) the note's value is inside a valid range, (c) the sum of input values equals the sum of output values plus any transparent leakage, and (d) a freshly derived nullifier has never appeared on chain. The nullifier is the double-spend guard: it is deterministically derived from the note secret, reveals nothing about the note, and collides only if the same note is spent twice.

Why this is a systems question, not a math question

A candidate can name Groth16 and still fail. The interview probes the machinery around the proof: who generates it and how long that takes on a phone, how a validator verifies thousands of proofs inside a block budget, how the nullifier set and the commitment tree are stored and replayed after a reorg, how a brand-new wallet scans years of ciphertext without trusting a third party, how the cryptographic parameters themselves get upgraded when the setup ceremony or the curve is no longer trusted, and how value crosses to other chains without dissolving the anonymity set. Each of those is a storage, concurrency, or governance problem.

The four architectural planes

1. Wallet plane: key derivation, note scanning, witness construction, local proof generation, selective disclosure.
2. Prover plane: witness generation, proving hardware (CPU, GPU, optional delegated proving service), job scheduling, memory ceilings.
3. Consensus plane: mempool, parallel proof verification, nullifier and tree state application, BFT finality, block dissemination.
4. Compliance and governance plane: viewing keys, proof-parameter ceremonies, upgrade activation, bridge policy, audit tooling for regulated integrators.

A strong answer keeps these planes separate: the prover may be slow or delegated, but consensus verification must stay fast and independent; compliance tooling must exist without creating a protocol-level backdoor.

Public baseline versus design assumptions

Public protocol facts anchor the design: Zcash launched Sprout in 2016 with a six-party setup ceremony, moved to Sapling and Groth16 in 2018 with a public multiparty ceremony of roughly ninety participants, and added the Orchard pool in 2022 using Halo 2 recursive proofs that remove the trusted setup for that pool. Zcash uses a 75-second block target and a 21 million coin cap. Sapling and Orchard commitment trees are depth-32 incremental Merkle trees. Groth16 proofs are on the order of 192 bytes and verify in single-digit milliseconds on commodity CPUs. Monero took a different public path: RingCT with stealth addresses and Bulletproofs range proofs at a fixed ring size, trading a bounded anonymity set for no setup at all. Everything not tied to such a public fact in this answer is an explicitly labeled design assumption.