How Zero-Knowledge Proofs Work

What Are Zero-Knowledge Proofs?

A zero-knowledge proof (ZKP) is a cryptographic method by which one party — the prover — can convince another party — the verifier — that a statement is true, without revealing any information beyond the truth of the statement itself. The prover demonstrates knowledge without disclosure.

The concept was introduced in 1985 by Shafi Goldwasser, Silvio Micali, and Charles Rackoff in their landmark paper "The Knowledge Complexity of Interactive Proof Systems." For decades it remained a theoretical curiosity — a beautiful result in complexity theory with no practical applications. Then, two developments changed everything: elliptic curve cryptography made proof generation computationally feasible, and blockchain created an urgent demand for verifiable computation without trust.

Today, zero-knowledge proofs underpin two of the most important areas of blockchain development: scalability and privacy. ZK-rollups use proofs to compress thousands of transactions into a single on-chain verification step — enabling Ethereum to scale without sacrificing security. Privacy protocols use proofs to let users prove they meet a condition (sufficient balance, valid credential, eligible voter) without revealing the underlying data.

The appeal of ZK proofs is that they solve a fundamental problem in cryptography: how do you prove you know something without saying what it is? The classic analogy is the Ali Baba cave — a prover can demonstrate they know the secret word to open a passage by repeatedly entering from one side and exiting the other, while the verifier challenges them with which side to exit from. After enough rounds, the verifier is convinced without ever learning the word.

Completeness, Soundness & Zero-Knowledge

Every zero-knowledge proof system must satisfy three formal properties. These are not design choices — they are mathematical requirements that any protocol claiming to be a ZK proof must prove it satisfies.

Completeness means that an honest prover with a valid witness can always convince an honest verifier. If the statement is true and the prover knows the proof, the verifier will accept. Formally: for all valid witnesses w, Pr[Verify(Prove(w)) = 1] = 1. This prevents a valid prover from being falsely rejected — the protocol must work when used honestly.

Soundness means that a cheating prover cannot convince the verifier of a false statement — except with negligible probability. Even if the prover is computationally unbounded and tries every strategy, the probability of convincing the verifier of a lie is at most some small ε (soundness error). In practice, soundness error is made negligible by repeating the protocol or by using cryptographic hardness assumptions.Computational soundness (which STARKs and SNARKs achieve) is sufficient in practice — a cheating prover would need more computation than exists in the universe.

Zero-knowledge is the defining property: the verifier learns nothing from the proof beyond the fact that the statement is true. Formally, there exists a simulator that can produce transcripts indistinguishable from real proofs — without knowing the witness. If a simulator can fake a proof that looks real, then real proofs must reveal no information (because the simulator has no information to reveal). This counter-intuitive formulation is the mathematical backbone of the entire field.

How ZK Proofs Work

The original ZK proof protocols were interactive: prover and verifier exchanged multiple rounds of messages, with the verifier issuing random challenges the prover had to respond to. Modern ZK systems are non-interactive — the entire proof is a single message — achieved via the Fiat-Shamir heuristic.

The Fiat-Shamir transform converts interactive protocols to non-interactive ones by replacing the verifier's random challenges with a hash of the prover's commitments. The prover computes e = H(commitment, statement) and uses e as the challenge — simulating a random verifier with a hash function. In the random oracle model (treating hash functions as truly random), this is provably secure. Non-interactive proofs are essential for blockchain use: the verifier is a smart contract that cannot engage in rounds of communication.

The structured reference string (SRS) in SNARKs is the output of a trusted setup ceremony. During the ceremony, participants contribute randomness; the ceremony is secure as long as at least one participant honestly destroys their toxic waste (the randomness used to generate the SRS). The Zcash Powers of Tau ceremony involved hundreds of participants across multiple countries. Groth16 requires a per-circuit SRS; PLONK introduced a universal SRS — one ceremony for all circuits up to a maximum size, dramatically simplifying deployment.

SNARKs vs STARKs

The two dominant families of practical ZK proof systems are SNARKs (Succinct Non-interactive Arguments of Knowledge) and STARKs (Scalable Transparent Arguments of Knowledge). They make different trade-offs between proof size, prover time, transparency, and post-quantum security.

SNARKs achieve succinct proofs — typically under 1 KB regardless of the complexity of the statement being proven — at the cost of a trusted setup and reliance on elliptic curve pairing assumptions (which are not post-quantum secure). Groth16 proofs are ~200 bytes and verify in milliseconds with just three pairing operations. This constant verification cost is transformative for blockchains: verifying a Groth16 proof on Ethereum costs roughly 300,000 gas regardless of whether the circuit encodes 100 or 1,000,000 constraints.

STARKs are transparent — no trusted setup, relying only on hash functions that are believed to be post-quantum secure. The trade-off is proof size: STARKs produce proofs of 40–200 KB rather than ~200 bytes. However, STARKs have better prover scalability — proving time grows quasi-linearly with computation size, versus the super-linear growth of many SNARK constructions. StarkNet uses recursive STARKs: many inner proofs are recursively combined into a single outer proof, amortising the large proof size across many transactions.

PLONK and its variants (TurboPlonk, UltraPlonk, Plonky2, Plonky3) occupy a middle ground: universal trusted setup, moderate proof size (~400 bytes to a few KB), and flexible custom gates that make it efficient to encode domain-specific computations. zkSync Era and Aztec use PLONK-family proof systems. Plonky2 achieves extremely fast recursion by using a Goldilocks field (optimised for CPUs) combined with FRI polynomial commitments from the STARK world.

ZK Circuits & Arithmetic Constraints

To create a ZK proof, you must first express the computation you want to prove as an arithmetic circuit — a directed acyclic graph of addition and multiplication gates over a finite field. This process of "arithmetisation" is the core engineering challenge of ZK development.

Every computation that can be expressed as an arithmetic circuit can be proven in ZK. This includes hash functions, digital signatures, range proofs, balance checks, and — with enough constraints — arbitrary program execution. The challenge is that operations which are cheap computationally (like integer division, comparisons, conditionals) are expensive in circuits because they must be decomposed into field arithmetic.

A zkEVM (zero-knowledge Ethereum Virtual Machine) is a ZK circuit that encodes the full EVM execution semantics — every opcode, stack operation, memory access, and storage read/write — as arithmetic constraints. Proving a single EVM transaction requires millions of constraints. Different teams have made different trade-offs between EVM compatibility (can you run unmodified Solidity?) and proving efficiency (how fast can you generate a proof?):

The unit of ZK circuit complexity is constraints. A simple addition costs 1 constraint. A SHA-256 hash costs ~25,000 constraints in R1CS, but fewer in PLONK with custom gates. A Poseidon hash (designed for ZK) costs ~200 constraints. An ECDSA signature verification costs ~700,000 constraints in R1CS — which is why ZK systems often use EdDSA or BLS signatures instead. The choice of hash function, signature scheme, and data structure is the primary determinant of circuit efficiency.

ZK-Rollups in Practice

ZK-rollups are the dominant production application of zero-knowledge proofs. They execute transactions off-chain, generate a ZK proof of correct execution, and post the proof to Ethereum — where a verifier contract checks the proof in O(1) time and cost regardless of how many transactions were included.

The architecture of a ZK-rollup has three components. The sequencercollects user transactions, orders them, and executes them against the rollup state. The prover generates a ZK proof that the sequencer's state transition was executed correctly — that every transaction was valid, every signature checked, every balance update correct. The L1 verifier contract receives the proof and a compressed form of the transaction data (calldata or blobs), checks the proof, and updates the rollup's state root on Ethereum.

1. 1
   User submits transaction

   Transaction sent to the rollup sequencer (centrally operated by the rollup team in most current systems). Sequencer receives transaction fees and determines ordering.

2. 2
   Sequencer executes & orders

   Sequencer applies transactions to the rollup state, updating balances, contract storage, and computing the new state root after each transaction.

3. 3
   Prover generates proof

   Prover takes the sequencer's execution trace as witness and generates a ZK proof that the state transition from root_old to root_new is valid. This is computationally intensive — minutes to hours depending on batch size and hardware.

4. 4
   Data posted to L1

   Compressed transaction data (ensuring data availability) and the ZK proof are posted to Ethereum. Since EIP-4844 (March 2024), rollup data goes in blobs — temporary, cheap storage — rather than permanent calldata.

5. 5
   L1 verifier accepts

   The verifier smart contract on Ethereum checks the proof in ~300,000 gas. If valid, the new state root is accepted as canonical. Withdrawals to L1 are immediately final — unlike optimistic rollups which require 7-day fraud proof windows.

The key advantage of ZK-rollups over optimistic rollups is finality. Optimistic rollups assume transactions are valid and wait 7 days for fraud proofs — meaning withdrawals to L1 take a week (without liquidity providers bridging). ZK-rollup withdrawals are final as soon as the proof is verified on L1, which can be minutes to hours. As proof generation hardware (GPUs, FPGAs, ASICs) improves, proving time is falling rapidly — some teams are targeting sub-minute proof generation for standard transaction batches.

Privacy Applications

Privacy is the original application of zero-knowledge proofs in crypto. Zcash introduced shielded transactions in 2016; the privacy model has since expanded to mixers, private DeFi, and confidential payment systems.

Zcash uses Groth16 proofs (after the Sapling upgrade) to implement shielded transactions: the sender, recipient, and amount are all hidden on-chain. The proof demonstrates that the sender owns sufficient funds (hidden), that the transaction conserves the total supply (no coins created from nothing), and that the recipient can later claim the output — all without revealing any of these values. Zcash's shielded pool is the largest production deployment of ZK privacy for a monetary system.

Tornado Cash used Groth16 Merkle tree proofs to implement a coin mixer on Ethereum. A depositor commits a secret note to a Merkle tree; later, the withdrawer proves (in ZK) that they know a note in the tree without revealing which one — breaking the link between deposit and withdrawal address. Tornado Cash was sanctioned by the US Treasury in August 2022 and its smart contracts added to the OFAC SDN list — the first time immutable code (not a person or entity) was sanctioned, raising fundamental legal questions about the status of open-source cryptographic software.

Private DeFi is an active research area. Aztec Network is building a ZK-rollup with native privacy: assets move between a public Ethereum state and a private shielded state, with ZK proofs ensuring conservation. The challenge is that DeFi composability — the ability to chain protocols — requires revealing some information about what you're doing, which conflicts with full privacy.

ZK Identity & Credentials

Zero-knowledge proofs enable a new model for identity and credentials: selective disclosure. Instead of showing your passport to prove your age, you prove in ZK that your age is above 18 — without revealing your name, passport number, or exact date of birth.

zkKYC protocols allow regulated platforms to verify that users have passed KYC without the platform holding personal data. A KYC provider issues a signed attestation; the user generates a ZK proof that they hold a valid attestation (from a trusted issuer) meeting the required criteria (resident of an allowed jurisdiction, above minimum age). The platform verifies the proof on-chain — it learns the user is verified, but nothing else.

Semaphore is a ZK protocol for anonymous signalling. Members of a group commit a secret identity to a Merkle tree. When a member wants to signal (vote, like, verify membership), they prove they are in the tree without revealing which member they are. Each signal includes a nullifier — a deterministic hash of the secret and the signal context — which prevents double-voting while preserving anonymity. Semaphore is used for anonymous voting in DAOs, anonymous feedback systems, and Sybil-resistant applications.

zkEmail uses ZK proofs over DKIM signatures — the cryptographic signatures email providers attach to outgoing messages — to prove properties of an email without revealing its contents. A user can prove they received an email from bank@chase.com confirming a transaction amount above $1,000, or that they own an @company.com email address, without revealing the email body or their address.

Limitations & Risks

Zero-knowledge proofs are not a cryptographic panacea. They have significant limitations — computational cost, circuit complexity, trusted setup risk, and the gap between theoretical security and production implementations — that every builder and user must understand.

Prover computational cost is the primary practical limitation. Generating a ZK proof for a complex computation requires orders of magnitude more compute than simply executing the computation. Proving a single Ethereum block (hundreds of transactions) on current zkEVM implementations takes several minutes on a high-end GPU cluster. While dedicated proving hardware (FPGAs, ASICs) and algorithmic improvements are closing this gap, ZK proving remains a significant operational cost for rollups.

Trusted setup risk affects all pairing-based SNARKs. If any participant in the trusted setup ceremony retained their toxic waste, they can generate proofs for false statements — forging transactions, minting tokens, or bypassing any check encoded in the circuit. The standard mitigation is multi-party computation (MPC) ceremonies with many participants, where security requires all participants to collude. Universal setups (PLONK) improve this by reusing a single ceremony; STARKs eliminate it entirely.

Circuit bugs are the ZK equivalent of smart contract bugs — potentially catastrophic and difficult to detect. If a constraint is missing or incorrect, the proof system may accept proofs for invalid statements. In August 2022, Polygon zkEVM was found to have a critical bug that would have allowed an attacker to withdraw any amount of funds from the bridge contract. The Zcash team discovered a counterfeiting bug in their original Sprout circuit that could have been exploited to create unlimited shielded ZEC — fortunately, the bug was discovered internally before exploitation. Circuit auditing is highly specialised and far less mature than smart contract auditing.

The Future of ZK

Zero-knowledge proofs are advancing on every dimension simultaneously — faster provers, smaller proofs, better developer tooling, and new application domains. The 2020s will likely see ZK proofs embedded in financial infrastructure, identity systems, and AI verification.

Hardware acceleration is the near-term priority. ZK proofs are parallelisable — the most computationally intensive operations (fast Fourier transforms, multi-scalar multiplications) are highly amenable to GPU and FPGA acceleration. Dedicated ZK ASICs are in development at several companies (Ingonyama, Cysic, Fabric Cryptography). As ASICs mature, proving costs will fall by orders of magnitude — potentially enabling real-time ZK proofs for individual transactions.

Proof aggregation allows many proofs to be recursively combined into a single proof. Rather than verifying 1,000 individual ZK-rollup proofs on L1 (1,000 × 300,000 gas = $300M/day at $30 gas), an aggregator can combine them into a single proof verified once. EigenLayer's EigenDA and Avail are positioning as data availability layers for aggregated proof systems. The endgame is a single Ethereum verification of all L2 activity — a "proof of everything."

ZK coprocessors allow smart contracts to outsource complex computation to off-chain provers that return verifiable results. A DeFi protocol could use a ZK coprocessor to compute complex risk metrics over its entire loan book — impossible on-chain due to gas costs — and receive a verified result that the contract trusts. Risc Zero, Axiom, and Brevis are building ZK coprocessor infrastructure.

Post-quantum migration is the long-term imperative. A large-scale quantum computer running Shor's algorithm would break the elliptic curve assumptions underlying all pairing-based SNARKs (Groth16, PLONK, KZG commitments). STARKs, which rely only on hash functions believed to be quantum-resistant, would survive. As quantum computing matures, the crypto ZK ecosystem will need to migrate to post-quantum proof systems — a decades-long transition that should begin with system designs today.