What Is Zero Knowledge? How Zero-Knowledge Proofs Work

A zero-knowledge proof is a way for one party, the prover, to convince another party, the verifier, that a statement is true without revealing why it is true or any of the data behind it. The verifier ends up certain of the claim but learns nothing else.

A simple example is proving you are over 18. Normally you would hand over a passport, which also shows your name, address, and exact birth date. With a zero-knowledge proof, you could demonstrate only that your birth date satisfies the rule, and the verifier would learn a single bit of information: the answer is yes.

The idea was formalized in a 1985 paper by Shafi Goldwasser, Silvio Micali, and Charles Rackoff. For years it was mostly a theoretical result. It became practical for blockchains once researchers found ways to make proofs small and fast to check, and once Zcash showed that private payments could be built on them.

In crypto, zero-knowledge proofs do two separate jobs, and it helps to keep them apart:

• Privacy: hiding amounts, senders, or personal data while still proving a transaction or credential is valid.
• Scaling: proving that a large batch of computation was done correctly, so a blockchain can verify one short proof instead of redoing all the work.

The second job is why the term appears so often alongside Ethereum layer-2 networks. Many so-called ZK rollups use proofs for compression and correctness, not for hiding anything. Throughout this guide, the phrase zero knowledge refers to the underlying technique, and the use cases are covered separately below.

For a protocol to count as a zero-knowledge proof system, it must satisfy three properties. These come from the original research and are still the standard definition.

Completeness. If the statement is true and both parties follow the rules, an honest prover will always convince an honest verifier. A valid claim should never be rejected by accident.

Soundness. If the statement is false, a cheating prover cannot convince the verifier, except with a negligible probability. This is the security property. In practice, the chance of a forged proof is made so small that it is treated as impossible, provided the system is built and implemented correctly.

Zero-knowledge. If the statement is true, the verifier learns nothing beyond the fact that it is true. Formally, anything the verifier sees could have been simulated without knowing the secret, so the transcript carries no extra information.

Two related terms appear often:

• Proof versus argument. A proof is sound even against a prover with unlimited computing power. An argument is sound only against provers with realistic, bounded computing power. Most systems used in crypto are technically arguments, but the industry calls them proofs.
• Succinctness. This is not part of the zero-knowledge definition. It means the proof is short and quick to verify, even when the original computation was huge. It is what makes ZK useful for blockchains.

A system can be zero-knowledge without being succinct, and succinct without being zero-knowledge. Many scaling systems are the latter: they are succinct and fast to verify, but they do not actually hide anything. Knowing the difference helps when a project uses the label loosely.

Several well-known thought experiments make the idea concrete.

The cave. Imagine a ring-shaped cave with a magic door blocking the far side. Peggy claims she knows the password. Victor waits outside while Peggy walks in and takes either the left or right path, out of his sight. Victor then walks to the entrance and shouts which side she must come out from. If Peggy knows the password, she can always comply by opening the door when needed. If she does not, she can only succeed when she happened to pick the right side, which is a 50 percent chance. Repeat this 20 times, and a bluffer's odds of passing every round fall to about one in a million. Victor becomes convinced, yet he never learns the password and has nothing to replay for others.

The two colored balls. A friend who cannot distinguish a red ball from a green one holds one in each hand. You can, so you ask them to hide the balls behind their back, optionally swap them, and show them again. You say whether they swapped. If you were guessing, you would be right only half the time. After many rounds, your friend is convinced you can tell the balls apart, yet they never learn which color is which.

A Sudoku puzzle. You can prove you have a valid solution by cryptographically committing to each cell and revealing only randomly chosen rows, columns, or boxes. Each reveal shows the digits are all different, but the full grid stays hidden.

The common pattern is a challenge the prover can only answer reliably if the claim is true, repeated enough that luck cannot explain success.

Modern ZK systems used in crypto follow a general pipeline. The details vary by scheme, but the stages are similar.

1. Express the claim as a computation. The statement, such as "this batch of transactions follows the rules and moves the state from A to B", is written as a program or a circuit, a set of arithmetic constraints.
2. Arithmetize it. The constraints are converted into polynomial equations over a finite field. If the computation was run correctly, a certain polynomial has specific properties, such as being zero at particular points.
3. Generate a witness. The witness is the private input plus all intermediate values from running the computation. It is the secret the prover holds.
4. Commit to the polynomials. The prover uses a polynomial commitment scheme, such as KZG or FRI, to lock in the polynomials without showing them.
5. Answer random challenges. The verifier picks random points and asks the prover to open the commitments there. A false witness would almost certainly fail at some point.
6. Output a short proof. The prover packages the responses into one compact proof.
7. Verify. The verifier checks the proof with a small amount of work, far less than rerunning the computation.

The interactive back-and-forth in step 5 would be impractical on a blockchain, where no verifier is waiting online. The Fiat-Shamir transform fixes this by replacing the verifier's random challenges with outputs of a hash function applied to the transcript so far. The result is a non-interactive proof that anyone can check later. Most blockchain proofs work this way.

The two main families of succinct proofs are SNARKs and STARKs. Both let a verifier check large computations cheaply, but they make different trade-offs.

• SNARK stands for Succinct Non-interactive Argument of Knowledge. Zero-knowledge versions are often called zk-SNARKs.
• STARK stands for Scalable Transparent Argument of Knowledge, and the transparency refers to needing no trusted setup.

Feature	SNARKs	STARKs
Proof size	Very small, often a few hundred bytes	Larger, often tens to hundreds of kilobytes
Verification cost	Low, especially on-chain	Higher, though improving
Trusted setup	Needed for some designs, universal for others	Not needed
Core cryptography	Usually elliptic curves and pairings	Hash functions
Quantum resistance	Pairing-based versions are not resistant	Generally considered more resistant
Prover speed	Varies by scheme	Often fast for large computations

Well-known SNARK schemes include Groth16, which has tiny proofs but needs a setup for each circuit, and PLONK-style systems, which use a single universal setup that many circuits can share. STARKs are associated with StarkWare and its Starknet network, and with newer hash-based systems.

These lines blur in practice. Many production systems combine approaches, for example proving with a STARK-like system and then wrapping the result in a small SNARK so the final on-chain check is cheap. When a project describes its proof system, the useful questions are what the proof size and verification cost are, whether a setup is needed, and which cryptographic assumptions it rests on.

Some SNARK schemes require a trusted setup, a one-time ceremony that generates public parameters used by every later proof. The process also creates secret randomness, sometimes called toxic waste, that must be destroyed. If someone kept it, they could forge proofs that pass verification, which would break soundness without anyone noticing.

The standard defense is a multi-party computation ceremony. Many independent participants each add their own randomness in turn. The final parameters are secure as long as at least one participant honestly discarded their contribution. Large ceremonies with hundreds or thousands of contributors make it very unlikely that all of them colluded or were compromised. Zcash ran early ceremonies of this kind, and Ethereum's KZG ceremony, used for data blobs, followed the same principle with a very large number of participants.

Setups come in two kinds:

• Circuit-specific: each new program needs its own ceremony. Groth16 works this way.
• Universal and updatable: one ceremony covers any circuit up to a size limit, and anyone can later contribute fresh randomness. PLONK-style schemes follow this model.

Transparent systems avoid the issue. STARKs derive their randomness from public hash functions, so there is nothing secret to protect. The cost is typically larger proofs.

A trusted setup is not automatically a red flag. A well-run ceremony with broad participation is a reasonable security model. It is simply an assumption worth knowing about, and a project should disclose it clearly in its documentation.

Blockchains are slow and costly largely because every node re-executes every transaction. A ZK rollup moves execution off the main chain. A sequencer collects user transactions, executes them on layer 2, and produces a new state. A prover then generates a validity proof showing that the transition followed the rules. That proof, along with enough data to reconstruct the state, is posted to Ethereum, where a verifier contract checks it.

Because the proof is small and quick to verify, one check on Ethereum can cover thousands of transactions. The cost of verification is shared across all of them, which lowers fees. The security inheritance is the key benefit: if the proof checks out, the state update is correct by mathematics, without having to trust the sequencer's honesty.

This differs from an optimistic rollup, such as Arbitrum. Optimistic rollups assume updates are valid and allow a challenge window in which anyone can submit a fraud proof. That is why withdrawals on optimistic networks traditionally take days, while validity-proof systems can in principle finalize once the proof is verified. Anyone moving funds through a bridge such as Arbitrum Bridge should know which model the destination chain uses, since it affects withdrawal timing.

A few clarifications:

• Most ZK rollups publish transaction data, so the activity is public. The proof guarantees correctness, not privacy.
• A zkEVM is a rollup designed to run Ethereum smart contracts and prove their execution.
• Not every network marketed with ZK branding is a full rollup. Sidechains and commit chains, including some Polygon networks, have different security assumptions, so check the specifics.

Beyond rollups, zero-knowledge proofs are being applied in several areas.

Private payments. Zcash's shielded transactions use zk-SNARKs to show that a transfer is valid, with no double spending and balanced inputs and outputs, while hiding sender, receiver, and amount. Several Ethereum-based privacy tools use the same principle with shielded pools. Rules about such tools vary by country and change over time, so check local regulations before using them.

Identity and credentials. A person could prove they are over a certain age, hold a valid license, or are a unique human without disclosing the underlying document. This is often called selective disclosure.

Proof of reserves and solvency. An exchange can prove that its customer liabilities do not exceed its holdings without publishing every account balance. Proofs of this kind are only as meaningful as the data fed into them, so completeness of the liability list still matters.

Cross-chain verification. A proof can show that something happened on another chain, which can reduce reliance on trusted multisig committees in bridges and messaging protocols. Cross-chain tools such as Across and Chainlink CCIP each use their own security designs, so read their documentation to see what, if anything, relies on proofs.

Verifiable computation. A heavy calculation, including some machine-learning inference, can be run off-chain and proven correct. This is an active research area, relevant to projects working on verifiable AI agents such as EigenCloud, though proving large models remains expensive.

Voting and governance. Proofs can show a vote was cast by an eligible member and counted once, without revealing the voter's choice.

Zero-knowledge proofs are powerful, but the mathematics is rarely the weak point. The risks sit around it.

• Circuit bugs. A proof only confirms that the rules written into the circuit were followed. If the circuit forgets a constraint, an attacker may be able to produce a valid proof of a false statement. Such bugs have been found in real projects and are hard to spot, which is why audits and formal verification matter.
• Implementation errors. Even a sound scheme can be undermined by faulty code in the prover, verifier contract, or surrounding infrastructure.
• Trusted setup assumptions. As covered above, setups depend on at least one honest participant.
• Centralization. Many rollups still run a single sequencer and a small set of provers. Users may depend on one operator for transaction ordering and censorship resistance, even though proofs protect correctness.
• Upgrade keys. A team or council holding the ability to change contracts quickly could override the proof system. Look for time delays, a security council, and clear disclosure.
• Data availability. If transaction data is not published, users may be unable to reconstruct their balances and exit. Designs that keep data off Ethereum carry different trade-offs.
• Proving cost and latency. Generating proofs requires heavy computation, and this affects how quickly batches can finalize.
• Quantum risk. Pairing-based SNARKs would be vulnerable to a sufficiently large quantum computer, which is one reason hash-based systems attract interest.

None of these makes ZK unsafe in itself. They are reasons to treat "uses zero knowledge" as a starting point for research, not as a guarantee of security. This guide is educational and not financial advice.

When a project says it uses zero knowledge, a short checklist helps separate substance from branding. Many of these details change often, so verify them in current sources rather than in older articles.

1. Which job do the proofs do? Determine whether they provide privacy, scaling, or both. A network with validity proofs may still show every transaction publicly.
2. Are proofs actually live? Some networks launched with proofs planned for later or running in a limited mode. Check the project's documentation for the current state.
3. Which proof system is used? Look for the scheme name, whether it needs a trusted setup, and whether the setup was a public ceremony.
4. Who runs the prover and sequencer? Decentralization of these roles affects censorship resistance and liveness.
5. Who can upgrade the contracts? Look for the governance structure, time delays, and any emergency powers.
6. Has the code been audited? Check for multiple independent audits of circuits and contracts, plus a bug bounty program.
7. Where is the data stored? Confirm whether transaction data is posted to Ethereum or elsewhere, and what users can do if the operator stops.
8. How do withdrawals work? Understand the exit path and expected timing before moving significant funds.

Independent trackers such as L2BEAT publish risk summaries and maturity stages for many rollups, and are a good place to compare projects. The official documentation and audit reports are the primary sources. Treat marketing pages and social posts as claims to be checked, not as evidence.