Glossary

Zero-Knowledge Proof (ZKP)

A cryptographic method allowing one party to prove they know something without revealing the underlying information.

Key Takeaways

  • A zero-knowledge proof lets one party (the prover) convince another party (the verifier) that a statement is true without revealing any information beyond the validity of the statement itself.
  • Two major ZKP systems dominate blockchain applications: ZK-SNARKs (small proofs, fast verification, but require a trusted setup) and ZK-STARKs (no trusted setup, quantum resistant, but produce larger proofs). Both are used to build rollups and privacy-preserving protocols.
  • ZKPs are increasingly relevant to Bitcoin Layer 2 scaling: projects like Citrea use ZK rollups to batch thousands of transactions into a single validity proof verified on the Bitcoin base layer.

What Is a Zero-Knowledge Proof?

A zero-knowledge proof is a cryptographic protocol that allows one party to prove to another that they possess certain knowledge or that a statement is true, without conveying any information apart from that single fact. The concept was introduced in 1985 by Shafi Goldwasser, Silvio Micali, and Charles Rackoff in their paper "The Knowledge Complexity of Interactive Proof-Systems," which laid the mathematical foundations for modern cryptography and earned the authors the 2012 ACM Turing Award.

A simple analogy: imagine you want to prove to a friend that you know the combination to a locked safe without actually telling them the combination. You could open the safe in front of them, demonstrate that it contains a specific item they placed inside earlier, and close it again. Your friend is now convinced you know the combination, but they learned nothing about the actual numbers. Zero-knowledge proofs formalize this intuition into rigorous mathematics that computers can execute.

In blockchain systems, ZKPs serve two primary purposes: privacy (hiding transaction details while proving validity) and scalability (compressing many computations into a single compact proof that is cheap to verify on-chain).

How It Works

Every zero-knowledge proof system must satisfy three fundamental properties:

The Three Properties

  • Completeness: if the statement is true and both parties follow the protocol honestly, the verifier will always be convinced. A valid proof always succeeds.
  • Soundness: if the statement is false, no cheating prover can convince the verifier it is true, except with negligible probability. Fake proofs cannot pass verification.
  • Zero-knowledge: if the statement is true, the verifier learns nothing beyond the fact that the statement is true. Formally, a simulator could produce transcripts indistinguishable from real interactions without ever accessing the prover's secret.

The classic illustration is the Ali Baba Cave problem (introduced by Jean-Jacques Quisquater et al.): a cave splits into two paths that meet at a door requiring a secret word to open. The prover enters and picks a path. The verifier waits outside and shouts which path the prover should emerge from. If the prover knows the secret, they can always comply. After many repetitions, the verifier becomes statistically convinced the prover knows the secret, yet the secret word itself is never revealed.

Interactive vs. Non-Interactive Proofs

The original zero-knowledge proofs were interactive: prover and verifier exchange multiple rounds of messages (commitments, challenges, and responses). This works well between two live parties but is impractical for blockchains, where there is no live verifier to send challenges.

The Fiat-Shamir heuristic (Amos Fiat and Adi Shamir, 1986) solved this by replacing the verifier's random challenge with the output of a cryptographic hash function applied to the prover's commitment. Because a hash function is deterministic yet unpredictable, it serves as a credible substitute for live randomness. The result is a non-interactive zero-knowledge proof (NIZK): a single message from prover to verifier that anyone can check independently. Nearly all blockchain-deployed ZK systems use non-interactive proofs derived through this technique.

Types of Zero-Knowledge Proofs

ZK-SNARKs

ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) produce very small proofs that are fast to verify. The most widely deployed scheme, Groth16 (2016), generates proofs of only about 200 bytes, regardless of the computation's complexity. A newer scheme called PLONK introduced a universal trusted setup (one ceremony works for any circuit) at the cost of somewhat larger proofs.

ZK-SNARKs rely on elliptic curve cryptography, specifically bilinear pairings on curves like secp256k1 and BN254. This dependency means they require a trusted setup ceremony to generate initial parameters. If the secret randomness from this ceremony (sometimes called "toxic waste") is not properly destroyed, the system's soundness can be compromised. ZK-SNARKs are also vulnerable to quantum computers, which could break the underlying elliptic curve assumptions.

ZK-STARKs

ZK-STARKs (Zero-Knowledge Scalable Transparent Arguments of Knowledge), introduced by Eli Ben-Sasson and collaborators at StarkWare in 2018, take a fundamentally different approach. Instead of elliptic curves, they rely on collision-resistant hash functions and use the FRI (Fast Reed-Solomon Interactive Oracle Proof of Proximity) protocol for proof generation.

This design eliminates the need for a trusted setup: all randomness is publicly verifiable, making STARKs "transparent." Because they depend only on hash functions rather than algebraic structures vulnerable to Shor's algorithm, STARKs are considered resistant to quantum computing attacks. The tradeoff is larger proof sizes (typically 45 to 200 KB compared to SNARK's 200 bytes), though verification remains efficient. For a deeper look at quantum threats to cryptographic systems, see post-quantum cryptography and Bitcoin.

Comparing ZK-SNARKs and ZK-STARKs

PropertyZK-SNARKsZK-STARKs
Trusted setupRequiredNot required (transparent)
Quantum resistanceVulnerableResistant
Proof size~200 bytes (Groth16)~45 to 200 KB
Verification speedVery fast (constant time)Slightly slower
Cryptographic basisElliptic curve pairingsHash functions
ScalabilityGood for small circuitsBetter for large computations

In practice, many production systems now use hybrid approaches. Polygon zkEVM, for example, first generates an eSTARK proof, then compresses it into a smaller SNARK proof via recursive composition, optimizing both proving cost and on-chain verification efficiency.

Use Cases

Privacy in Cryptocurrency

The earliest major application of ZKPs in blockchain was Zcash (launched 2016), which uses zk-SNARKs to enable shielded transactions. In a shielded transaction, the proof demonstrates that inputs are valid, outputs are correctly computed, and no coins are created or destroyed, all without revealing sender, receiver, or amounts. Monero takes a different approach, using Bulletproofs (a ZKP system optimized for range proofs) within its RingCT confidential transaction scheme.

ZK Rollups for Scalability

ZK rollups are Layer 2 scaling solutions that execute transactions off-chain and post a compact validity proof on the base layer. Instead of requiring every node to re-execute every transaction, nodes need only verify the proof, which is orders of magnitude cheaper.

On Ethereum, zkSync Era (SNARK-based), StarkNet (STARK-based), and Polygon zkEVM (hybrid STARK-to-SNARK) collectively process hundreds of millions of transactions with sub-dollar fees and multi-second confirmation times. For a comparison of scaling approaches across ecosystems, see the Bitcoin Layer 2 comparison.

Identity Verification

ZKPs enable proving attributes about your identity without exposing the underlying data. Rather than sharing a full passport scan to prove you are over 18, a ZK proof can cryptographically attest to the fact without revealing your birthdate, name, or document number. Bhutan's national digital identity system uses ZKPs so citizens can prove facts like citizenship or age to service providers while keeping personal data private.

ZK Proofs on Bitcoin

Bitcoin's script language is intentionally limited, making on-chain ZK proof verification a significant technical challenge. However, several breakthroughs have made it possible:

  • BitVM (introduced by Robin Linus in 2023) enables complex computation verification on Bitcoin without protocol changes, using an optimistic verification model where verifiers can challenge false claims through a fraud-proof game
  • Citrea, Bitcoin's first ZK rollup, uses a zkVM built with RISC Zero to batch thousands of transactions, produce validity proofs, and verify them on Bitcoin via a BitVM-based verifier
  • In July 2024, multiple projects (StarkWare, BitcoinOS, BitVMX) achieved historic first ZK proof verifications on Bitcoin, demonstrating that ZK scaling is technically feasible without soft forks

The potential reactivation of OP_CAT could further simplify on-chain ZK verification. StarkWare has demonstrated STARK proof verification using OP_CAT-based covenants on Signet, and the OP_CAT covenant debate remains an active area of discussion in the Bitcoin community.

Why It Matters

Zero-knowledge proofs address two of the hardest problems in blockchain design: how to scale without sacrificing security, and how to provide privacy without enabling abuse. As Bitcoin Layer 2 solutions mature, ZKPs offer a path to verify complex off-chain computation with minimal on-chain footprint.

For Bitcoin L2 platforms like Spark, ZK technology represents a frontier for trustless verification: proving that off-chain state transitions are valid without requiring every participant to re-execute them. Combined with threshold signatures and Taproot-enabled script paths, ZKPs can enable expressive self-custodial systems that remain anchored to Bitcoin's security guarantees.

Risks and Considerations

Trusted Setup Risk

ZK-SNARK systems that require a trusted setup ceremony depend on the assumption that the secret parameters ("toxic waste") were properly destroyed. If any participant in the ceremony retained this data, they could forge proofs for false statements. Multi-party computation ceremonies (where only one honest participant is needed) mitigate but do not eliminate this concern. ZK-STARKs avoid this issue entirely through their transparent design.

Computational Cost

Generating ZK proofs is computationally intensive. Proving times can range from seconds to minutes depending on circuit complexity, and prover hardware requirements are significant. This cost is a barrier to decentralization: running a prover node for a ZK rollup requires far more resources than running a standard validator. Specialized proving infrastructure and marketplaces (like Fermah) are emerging to address this bottleneck.

Quantum Vulnerability

ZK-SNARKs based on elliptic curve cryptography are vulnerable to quantum attacks via Shor's algorithm. While practical quantum computers capable of breaking these systems do not yet exist, the threat motivates ongoing research into lattice-based and hash-based alternatives. ZK-STARKs, relying solely on hash functions, are already considered quantum-resistant.

Complexity and Auditability

ZK proof systems involve highly specialized mathematics. Bugs in circuit design or constraint generation can be subtle and catastrophic: a soundness error could allow forged proofs, while a completeness error could lock valid users out. Formal verification of ZK circuits remains an active research area, and the small pool of qualified auditors creates bottlenecks for projects relying on custom circuits.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.