A zero-knowledge proof (ZKP) lets one party, the prover, convince another party, the verifier, that a statement is true without revealing the secret information that makes it true. In blockchain systems, this can protect selected data or let a network verify a large computation from a much smaller proof.
“Zero knowledge” does not mean the verifier learns literally nothing. The verifier learns that the stated condition holds, and metadata such as timing or the public inputs may still be visible. The proof also does not establish that the real-world premise is honest. It proves a mathematically encoded statement under specified cryptographic assumptions.
An accessible example: the locked color rooms
Imagine two locked rooms, Red and Blue, connected by a private corridor. Each room has its own public entrance. Peggy claims she has a secret key that opens the door inside the corridor, allowing her to move between rooms. Victor wants evidence without seeing the key.
Peggy enters one room while Victor looks away. Victor then randomly calls “come out through Red” or “come out through Blue.” If Peggy has the corridor key, she can always comply: she either stays in the chosen room or unlocks the internal door and crosses. If she has no key, she can comply only when Victor happens to name the room she entered—a one-half chance.
They repeat the challenge many times. After 20 successful rounds, a keyless Peggy’s chance of guessing every request is about one in 1,048,576, assuming fair independent challenges. Victor gains confidence that Peggy can open the internal door, but he never sees the key. A real cryptographic protocol replaces rooms with mathematical commitments and challenges and is designed so transcripts do not reveal the secret witness.
Three core properties
Completeness means an honest prover with a valid witness can convince the verifier. Soundness means a dishonest prover should not be able to convince the verifier of a false statement except with negligible probability. Zero knowledge means the proof reveals no additional information about the witness beyond the truth of the statement, according to a formal simulation definition.
The public statement might be “this transaction preserves balances and follows all rules.” The private witness might include account balances, signatures, and intermediate computation. A proof system turns the rules into an arithmetic circuit or another constraint representation. The prover demonstrates that it knows values satisfying those constraints; the verifier checks the proof using public inputs.
Interactive and non-interactive proofs
The room story is interactive because Victor sends fresh random challenges. Blockchains generally need non-interactive proofs that can be posted once and checked by anyone. Techniques such as the Fiat-Shamir transform derive challenges from a cryptographic hash in the random-oracle model, removing live back-and-forth for many constructions.
A concise proof can be much smaller and cheaper to verify than repeating the underlying computation. Generating it may still require substantial time, memory, specialized algorithms, or hardware. “Succinct verification” does not mean free computation; it changes who performs the expensive work and how many verifiers repeat it.
zk-SNARKs and zk-STARKs
A SNARK is a succinct non-interactive argument of knowledge. Many SNARK constructions produce small proofs with fast verification, qualities useful for blockchains. Some require a trusted setup that creates public parameters. If secret setup material—often called toxic waste—is retained and the system’s construction allows it, an attacker may be able to forge proofs without detection.
Multi-party ceremonies reduce this risk: the setup remains safe if at least one participant contributes randomness honestly and destroys its secret contribution. Universal or updatable setups can support many circuits or allow future contributions. Other proof systems avoid trusted setup but make different trade-offs in proof size, speed, and assumptions.
STARKs are scalable transparent arguments of knowledge. “Transparent” indicates that they avoid a secret trusted setup, typically relying on public randomness and hash-based cryptography. STARK proofs are often larger than some SNARK proofs, while offering attractive scalability and assumptions commonly described as resistant to known quantum attacks. Exact performance depends on the workload and implementation; acronyms alone do not determine the best system.
Privacy applications
A private payment system can prove that inputs are authorized, values follow range rules, and no money is created, without publicly revealing all amounts or links. Identity credentials can prove “over 18” without revealing a birth date. A compliance system might prove that a screening policy was applied without publishing the complete customer record.
Privacy depends on more than the proof. Network addresses, deposit and withdrawal amounts, timing, wallet behavior, and the size of the anonymity set can reveal links. A user who deposits and withdraws a unique amount minutes later may be identifiable even if the internal proof is sound. Privacy claims should therefore describe the complete system and its threat model.
Validity proofs and blockchain scaling
A zero-knowledge rollup executes many transactions outside Ethereum, calculates a new rollup state, and submits a validity proof plus required commitments and data. An Ethereum verifier contract checks the proof. If it is valid, the contract accepts that the batch followed the encoded transition rules without re-executing every operation on the base layer.
This amortizes verification and posting costs across many users. The proof may protect private transaction details in some designs, but scaling rollups are not automatically private. Many publish transaction data so anyone can reconstruct state. “ZK” refers to the proof technology; the application decides which inputs are public or hidden.
Data availability remains separate. A validity proof can establish that a new state root was computed correctly, yet users may need transaction or state-difference data to know their balances and create future transactions. Rollups publish data to Ethereum or use another stated availability model. Withheld data can block independent reconstruction even when the proof is valid.
Risks and limitations
The circuit may prove the wrong rules. A missing range check, incorrect signature constraint, or mismatch between source code and circuit can allow invalid application behavior while every generated proof verifies correctly. Proof-system libraries, compilers, setup ceremonies, verifier contracts, and upgrade keys all become security-critical.
Cryptographic assumptions may fail or implementation bugs may leak witnesses. Side channels in proving software can expose secrets through memory, timing, or hardware behavior. Complex systems need audits, test vectors, formal reasoning where practical, reproducible setup procedures, and clear upgrade governance.
Proving cost can also centralize operation. If only a few well-funded entities can generate proofs quickly, they may dominate sequencing even though anyone can verify. Projects are developing faster provers, aggregation, recursion, and specialized hardware, but operational concentration should be measured rather than assumed away.
How to evaluate a ZK claim
Ask for the exact statement being proved, which inputs are public, what remains private, and where the underlying data is available. Identify the proof system, cryptographic assumptions, trusted setup, circuit audits, and upgrade authority. For scaling, examine sequencer failure and base-layer exit paths. For privacy, examine metadata and anonymity-set limitations.
Zero-knowledge proofs are powerful because they separate doing or knowing from revealing every detail. They do not replace sound application design, data availability, governance, or operational security. Used carefully, they can give blockchains both selective confidentiality and efficient verification at a scale that direct re-execution cannot match.