Design a Zero-Knowledge Identity Verification System

Problem statement

Design a system in which a user proves a claim about themselves — “I am over 18”, “I am a resident of country X”, “I passed KYC with a regulated issuer”, “I am a unique human” — without revealing the underlying attribute, document, or even their wallet address linkability across verifiers. The proof is a zero-knowledge proof (ZKP) generated inside the user’s wallet from a credential signed by a trusted issuer, and verified either off-chain by a relying party’s backend or on-chain by a smart-contract verifier. Revoked or expired credentials must stop verifying, and a proof must never be replayable for a second use of a one-time entitlement.

This is not a conventional authentication problem. In OAuth the identity provider sees every login and the resource server receives a bearer artifact tied to a stable subject identifier. In a zero-knowledge identity system the issuer must be blind to which verifiers the holder talks to, the verifier must learn only the boolean claim (plus whatever the holder chose to disclose), and two verifiers must not be able to correlate their sessions by comparing identifiers. The cryptographic machinery — commitments, signature verification inside a circuit, Merkle membership or accumulator non-revocation proofs, and scope-bound nullifiers — exists to enforce those three blindness properties while preserving soundness: a user without a valid credential must not be able to produce an accepting proof.

Why the problem is distinctive

A classic identity backend can retry a failed lookup. A zero-knowledge identity system fails in modes ordinary systems never see: a trusted-setup compromise that lets an attacker forge proofs, a circuit bug that accepts invalid witnesses, a stale revocation root that lets a revoked credential verify for an hour, a nullifier database partition that allows a double-spend of a one-time entitlement, or a prover that leaks witness bytes through a side channel and silently destroys the privacy property the product was sold on. The design therefore separates four planes and gives each its own failure semantics.

1. Issuance plane: identity assurance (document check, liveness, NFC chip passive authentication), schema governance, issuer key custody in HSM, credential signing, and re-issuance.
2. Holder plane: wallet secret in a secure enclave, credential vault, witness construction, client-side proving, consent UX, and recovery.
3. Verification plane: off-chain verifier service and on-chain verifier contract, nullifier uniqueness, root freshness policy, and audit minimization.
4. Governance plane: revocation and status publication, circuit versioning and ceremonies, issuer registry, lawful-access escrow, and privacy compliance operations.

Public operating baseline versus design assumptions

Public evidence shows the category is production-real. Worldcoin (Tools for Humanity) reports millions of Orb-verified humans and issues World ID credentials whose anonymous use relies on Semaphore-style zero-knowledge proofs with contracts on OP Mainnet. Polygon ID / iden3 ships client-side Groth16 and PLONK proof generation with on-chain verifier contracts and an on-chain revocation tree on Polygon networks. Semaphore, from Privacy & Scaling Explorations, provides group-membership and signaling proofs used by anonymous voting and whistleblowing apps. Sui’s zkLogin binds OIDC logins to on-chain accounts through a Groth16 proof verified natively by the chain. These are cited public approaches, not requirements for our fictional system.

For capacity planning this answer explicitly assumes: 40 million registered wallets, 8 million issued credentials, 3 million verification requests per day with a 6× peak multiplier, 200 thousand issuances per day, and 10 percent of verifications settling on-chain. Unless a number is tied to a citation, it is a stated design assumption, target, or budget — not a claim about any company’s private architecture.

The invariant set

• Minimal disclosure: no raw attribute byte leaves the wallet unless the holder explicitly consents to selective disclosure of that field.
• Unlinkability: two verifiers using different scopes cannot correlate presentations by any value in the protocol transcript.
• Soundness and forge-resistance: accepting proofs require a currently-valid, unrevoked credential signed by a registered issuer.
• One-time semantics: scope-bound nullifiers make double-use of an entitlement detectable and preventable.
• Revocability: revocation propagates into verification decisions within a declared freshness window.

A strong interview answer states these invariants in the first two minutes, then derives every component from them.