Zero-knowledge proofs are among the most powerful cryptographic tools to emerge in recent decades. They allow a prover to convince a verifier that they know something — a secret, a computation result, a transaction’s validity — without revealing the underlying data. In blockchain, ZKPs enable both privacy (hide transaction details) and scalability (compress thousands of transactions into a single proof that can be verified cheaply).
What “Zero Knowledge” Means
The classic illustration is the cave problem (Quisquater et al., 1989):
Imagine a circular cave with a magic door in the middle requiring a secret password. Peggy claims she knows the password. Victor wants to be convinced without learning the password.
- Victor waits outside while Peggy enters the cave, going left or right
- Victor enters and shouts “come out the left side!” (or right)
- If Peggy knows the password, she can always comply — she uses the door if needed
- After many rounds, the probability Peggy is guessing correctly by luck approaches zero
- Victor is convinced Peggy knows the password — but he learned nothing about the password itself
This is zero-knowledge: conviction without information transfer.
Three Properties of a ZKP
| Property | Meaning |
|---|---|
| Completeness | If the statement is true, an honest prover can always convince an honest verifier |
| Soundness | A dishonest prover cannot convince a verifier of a false statement (except with negligible probability) |
| Zero-knowledge | The verifier learns nothing beyond the truth of the statement |
ZK-SNARKs vs ZK-STARKs
The two dominant ZKP systems used in blockchain:
| Property | zk-SNARK | zk-STARK |
|---|---|---|
| Full name | Zero-Knowledge Succinct Non-Interactive Argument of Knowledge | Zero-Knowledge Scalable Transparent Argument of Knowledge |
| Requires trusted setup? | Yes (toxic waste ceremony) | No (transparent) |
| Proof size | Very small (~200 bytes) | Larger (~50-100 KB) |
| Verification time | Very fast | Fast but slower than SNARK |
| Post-quantum secure? | No (elliptic curve based) | Yes (hash-based) |
| Used by | Zcash, Groth16, Plonk, Polygon Hermez | StarkNet, StarkEx, RISC Zero |
Trusted Setup Problem: Some SNARK systems require a “powers of tau” ceremony where participants generate random parameters. If all participants keep their secret inputs (the “toxic waste”), the setup is secure. But if even one participant kept their secret, they could generate fake proofs that validators would accept. Modern systems (PLONK, Halo2) use universal or updateable setups; STARKs eliminate the problem entirely.
ZK Proofs in Blockchain
Privacy Use Cases
- Zcash (zk-SNARKs): Transactions where sender, receiver, and amount are hidden; only validity is proven
- Aztec Network: Private smart contract execution on Ethereum using ZKPs
- Tornado Cash (ZKPs for anonymity): Proved token deposits without linking withdrawals (OFAC-sanctioned 2022)
- Worldcoin (ZK biometrics): Prove you’re a unique human without revealing which iris scan is yours
Scaling Use Cases (ZK Rollups)
- Polygon zkEVM: EVM-compatible ZK rollup; proofs batch thousands of EVM transactions
- zkSync Era: Native account abstraction + ZKP-based scaling
- Starknet: STARK-based rollup for general computation
- Scroll: EVM-equivalent ZK rollup targeting bytecode-level compatibility
- Linea (Consensys): ZK proof-based Ethereum L2
Verification Applications
- KYC without data sharing: Prove “I am over 18” or “I passed KYC” without revealing passport details
- Voting: Prove you voted without revealing your vote
- Supply chain: Prove a product meets standards without revealing supplier details
ZK Proof Generation Pipeline
“`
Input data (private) + Public statement
↓
Arithmetization (convert computation to polynomial constraints)
↓
Prover generates proof (~seconds to minutes on modern hardware)
↓
Proof sent to verifier/chain (~200 bytes for SNARK)
↓
Verifier checks proof (~milliseconds, cheap on-chain)
“`
The asymmetry — expensive to prove, cheap to verify — makes ZKPs ideal for blockchain scaling. A proof covering 10,000 transactions costs ~$0.01 to verify on-chain.
Current Challenges
- Proving time: ZK proof generation is computationally intensive (seconds to minutes). Hardware acceleration (FPGA/ASIC) is a major research focus.
- EVM compatibility: ZK-proving the full EVM is extremely complex. zkEVM implementations range from “bytecode equivalent” to “language equivalent” — each with different compatibility tradeoffs.
- Developer tooling: Writing ZK circuits directly (Circom, Cairo, Noir) is specialized; high-level abstractions are improving but still immature.
Related Terms
Sources
Goldwasser, S., Micali, S., & Rackoff, C. (1989). The Knowledge Complexity of Interactive Proof Systems. SIAM Journal on Computing.
Ben-Sasson, E., et al. (2014). Succinct Non-Interactive Arguments for a von Neumann Architecture. USENIX Security.
Ben-Sasson, E., et al. (2018). Scalable, Transparent, and Post-Quantum Secure Computational Integrity. Cryptology ePrint Archive.
Groth, J. (2016). On the Size of Pairing-Based Non-Interactive Arguments. EUROCRYPT.
Buterin, V. (2022). The Different Types of ZK-EVMs. Vitalik.eth.