Zero-Knowledge Proofs Explained: What They Prove, What They Cost, What to Ask

Updated November 10, 2026.

You hand a bartender your driver's license. She needs one fact: are you over 21? What she gets is your full name, your birth date, your home address, your height, your license number, and whether you need glasses to drive.

That's how most verification works. To prove one thing, you hand over everything.

Banks do it with loan files. Exchanges do it with KYC packets. Auditors do it with sample pulls. Every copy of that data is one more place it can leak, and anyone who's run a security program knows every copy eventually gets tested.

A zero-knowledge proof flips the arrangement. You prove the one fact, and the verifier learns that fact and nothing else. No birth date. No address. Just "over 21: true," backed by math the verifier can check.

This is the main page on the site for zero-knowledge proofs (ZKPs). It covers what they are, where they came from, the main types, what they really cost, and what I'd ask before putting one anywhere near a regulated process. Deep dives on specific proof systems and use cases are linked along the way.

What a zero-knowledge proof is

Two parties. The prover knows a secret, which cryptographers call the witness. The verifier wants to be convinced that a statement about it is true. "I know the password to this account." "This transaction spends coins I own and doesn't create new ones." "This balance is above $10 million."

A proof system counts as zero-knowledge when it has three properties:

• Completeness. If the statement is true and both sides follow the protocol, the verifier accepts.
• Soundness. If the statement is false, a cheating prover can't convince the verifier, except with a probability so small you can ignore it.
• Zero knowledge. The verifier learns nothing beyond the fact that the statement is true. Formally, anything the verifier sees, it could have generated on its own without the secret.

The first two describe any good proof. The third is the strange one, and it's the one that matters for privacy.

The cave

The classic explanation comes from a 1989 paper with a great title: "How to Explain Zero-Knowledge Protocols to Your Children," by Jean-Jacques Quisquater, Louis Guillou and their families.

Picture a ring-shaped cave with one entrance. The path splits left and right, and the two branches meet at the back at a locked door. Peggy says she knows the word that opens the door. Victor wants proof, but Peggy won't tell him the word.

So Victor waits outside. Peggy walks in and takes a branch. Victor walks to the fork and shouts which side he wants her to come out of. If she knows the word, she can always do it, going through the door when she has to. If she doesn't, she's stuck with the branch she picked, and she gets caught half the time.

One round proves little. A faker survives it with 50% odds. Twenty rounds cuts those odds to about one in a million. Victor ends up convinced, and he still doesn't know the word.

He can't even convince anyone else. A video of the twenty rounds proves nothing, because Peggy and Victor could have agreed on the choices in advance and staged it. The transcript is worthless to everyone except the verifier who was there. That's the zero-knowledge property in plain English.

What a proof doesn't prove

Here's the part that matters for anyone with a fiduciary duty, and it's the part vendor decks skip.

A ZKP proves that a statement about some data is true. It doesn't prove the data is true. Feed it wrong inputs and you get a perfectly valid proof about wrong inputs.

Take crypto proof-of-reserves, the reports exchanges started publishing after FTX failed. Some use Merkle trees or zero-knowledge proofs to show customer balances add up without exposing individual accounts. Useful. But the proof covers the liabilities the exchange chose to include, at one point in time. In March 2023 the PCAOB's Office of the Investor Advocate warned that these reports "are not equivalent or more rigorous than an audit." Better math doesn't change that.

The problem is rarely the cryptography. It's what goes into it.

ZKPs also don't replace the rest of the cryptographic toolkit. They sit on top of it. Hash functions, commitments and digital signatures still do the heavy lifting, and a proof usually says something about values that were committed or signed somewhere else. If the signing keys leak, the proof is still valid. It's just meaningless.

The ZK in finance post goes deeper on DeFi, reserves and compliance.

A short history

ZKPs aren't new. They're 40 years old. What's new is that they're cheap enough to use.

• 1985. Shafi Goldwasser, Silvio Micali and Charles Rackoff present "The Knowledge Complexity of Interactive Proof Systems" at STOC. It defines zero knowledge and the three properties above. Goldwasser and Micali later share the 2012 Turing Award for laying the foundations of modern cryptography.
• 1986. Oded Goldreich, Micali and Avi Wigderson show that every statement in the complexity class NP has a zero-knowledge proof, assuming secure encryption exists. That's the result that turns a clever idea into a general tool. The same year, Amos Fiat and Adi Shamir publish the trick for making interactive protocols non-interactive.
• 1988. Manuel Blum, Paul Feldman and Micali show non-interactive zero-knowledge proofs are possible when both sides share a common reference string.
• 2012. Nir Bitansky, Ran Canetti, Alessandro Chiesa and Eran Tromer formalize the SNARK: a proof that stays short and fast to check no matter how big the computation behind it.
• 2014. The Zerocash paper uses zk-SNARKs to design private payments on a Bitcoin-style ledger.
• 2016. Zcash launches on October 28, built on Zerocash. It's the first large public deployment of zk-SNARKs.
• 2018. Bulletproofs (short proofs, no trusted setup) and STARKs (hash-based and transparent) both arrive. ZKProof, an open industry and academic standards effort, holds its first workshop in Boston.
• 2023. Ethereum's KZG ceremony collects 141,416 contributions to generate parameters for its scaling roadmap, the largest setup of its kind at the time.
• 2025. Google open-sources its ZKP libraries, longfellow-zk, for privacy-preserving age checks, aimed at the EU's digital identity wallets.

One correction, because you'll see it repeated in older material, including earlier posts on this site. Goldreich, Micali and Wigderson didn't coin "zero-knowledge proof" in 1988. The term and the definition come from the 1985 Goldwasser, Micali and Rackoff paper. GMW's contribution was showing how far the idea reaches.

The main types

Interactive vs. non-interactive

The cave is interactive. Prover and verifier go back and forth: commit, challenge, respond, repeat. It works, but both parties have to be online at the same time, and the result convinces only the verifier who asked the questions.

A non-interactive proof is one message. The prover generates it once, and anyone can check it later, as many times as they want. That's what blockchains and audit trails need.

The usual bridge is the Fiat-Shamir transform. Instead of waiting for the verifier's random challenge, the prover makes the challenge by hashing everything it's sent so far. It can't predict the hash, so it can't rig the challenge. Most practical proof systems rely on this step somewhere.

It's also a common place to get things wrong. In April 2022, Trail of Bits disclosed a class of bugs it called Frozen Heart: implementations of PlonK, Bulletproofs and other systems that left inputs out of their Fiat-Shamir hash, which let an attacker forge proofs. The math was fine. The code wasn't.

SNARKs, STARKs and Bulletproofs

Nearly every production system today is non-interactive and belongs to one of three families. At overview depth:

A trusted setup is a ceremony that generates public parameters from secret randomness. If anyone keeps that randomness, they can forge proofs that check out fine. Modern ceremonies split the job across many participants so that a single honest one is enough. That's why Ethereum wanted 141,416 of them. Zcash's newer pools dropped the need when it moved to Halo 2 in 2022, though its older Sapling pool still rests on its original ceremony.

For the details, read the zk-SNARKs deep dive and the STARKs, Bulletproofs and post-quantum post.

What it really costs

Proving is expensive. Checking a proof is cheap. Making one isn't. The prover has to express the computation as an arithmetic circuit and do heavy cryptographic work across all of it, which typically runs orders of magnitude slower than just doing the computation. For "balance above X," that's nothing. For "this entire loan book meets its covenants," it's real compute, and you'll want to measure it on your own volumes.

Circuits are hard to write and easy to get wrong. Writing a circuit is closer to designing hardware than building an app. A classic serious bug is an under-constrained circuit, one that accepts more than it should. Zcash, with as much cryptographic talent as any project in the space, has now had two counterfeiting-class soundness bugs: one found in 2018, one in 2026. Researchers caught both, and neither is known to have been exploited. If that team can ship one, so can your vendor.

Setups and keys need governance. If the system needs a trusted setup, who took part, and can you verify the transcript? Proving keys, verification keys and the verifier code all become assets you have to control and change-manage, same as any other production crypto.

The quantum clock is ticking on some designs. Elliptic-curve SNARKs rest on math a large quantum computer could break, which would let an attacker forge proofs. For a proof you check today and throw away, that's not urgent. For a system that has to keep forgery impossible for a decade, it belongs on the roadmap now.

Explaining it takes real time. End users don't need to understand the math. Your auditors and examiners do need to understand what's being proved. An examiner who can't follow the statement won't accept the proof as evidence.

Regulators treat it by use, not by math. ZK for identity is being encouraged. The EU's digital identity framework pushes member states toward privacy-enhancing tech like this. ZK for anonymous payments is heading the other way: the EU's Anti-Money Laundering Regulation bars banks and crypto-asset service providers from keeping anonymous accounts, including accounts that use anonymity-enhancing coins, starting July 10, 2027. Same math. Opposite treatment. The question regulators ask isn't "is it zero-knowledge?" It's "who can still see what, when they need to?"

Where it's heading

• Scaling blockchains. zk-rollups batch thousands of transactions off-chain and post a single proof to Ethereum. Here the point is cheap verification, not secrecy. Checking one proof beats re-running thousands of transactions.
• Identity and credentials. Prove you're over 18, a licensed adviser, an accredited investor or a resident of an allowed jurisdiction, without handing over the document. Google's 2025 release and the EU wallet work are the most visible examples. The ZK beyond payments post covers more.
• General-purpose proving. zkVMs let developers write ordinary code and prove it ran correctly, instead of hand-building circuits. That lowers the barrier, and it moves your trust onto the zkVM.
• Recursion. Proofs that verify other proofs, so a year of monthly attestations can roll up into one.
• Formal verification. After the 2026 bug, Zcash's replacement shielded pool, Ironwood, shipped with formally verified circuits. I'd make "is it formally verified?" a standard due-diligence question.
• Post-quantum migration. Hash-based systems like STARKs get more attention as quantum timelines get taken seriously.
• Standards. ZKProof has been building a community reference since 2018. It's useful, but this field still has nothing like the settled standards you'd expect for encryption or signatures.

What I'd do as a leader

Don't start with the technology. Start with a disclosure problem. Where are you collecting or sharing more data than the decision needs? KYC files copied to every counterparty. Full loan files when the lender needs one ratio. Customer lists swapped just to check for overlap.

Then put these questions to any vendor or internal team:

1. What exactly is the statement being proved? One sentence. If nobody can write it, stop.
2. Where do the inputs come from, and who vouches for them? The proof is only as good as the data and signatures under it.
3. Who wrote the circuit, and who audited it? Ask for the audit reports, and ask whether the circuits are formally verified.
4. Is there a trusted setup? If yes, who took part, and can you verify it?
5. What's the quantum story? Which assumptions break, and what's the migration plan?
6. Who can see what, and when? Regulators, auditors, courts. If the answer is "nobody, ever," you've got a compliance problem, not a privacy feature. Selective-disclosure tools like Zcash's viewing keys exist for a reason.
7. What does your auditor think? Bring them in at design time, not after go-live.

Then pilot something small, where the statement is simple and the data source is already trusted. An eligibility check. A threshold attestation. Proof that a screening step ran against the right list. Measure proving cost on real volumes before anyone signs a multi-year contract.

Most of the people asking for your data don't need most of what they get. The bartender never needed your address.

Over 21: true. That's all she needed.