A zero-knowledge proof is a cryptographic construction that lets one party (the prover) convince another party (the verifier) that a statement is true, without revealing anything beyond the fact that the statement is true. The classic toy example: suppose there is a cave shaped like a loop with a locked door at the far end, and the prover wants to convince the verifier that they know the key, without showing the key. The prover enters the cave, the verifier waits outside and calls out a random side (“come out on the left”), the prover emerges on the requested side, and the verifier repeats until they are satisfied. If the prover did not actually know the key, they would only succeed by luck half the time, and repeating the protocol quickly drives the probability of cheating to near zero. The prover never shows the key, but the verifier ends up convinced they have it.
This general idea — prove knowledge of something without revealing the something — generalises to all kinds of cryptographic statements. “I know a valid signature for this message.” “I have enough balance in this account to cover this transfer.” “I executed this entire smart contract and here is the correct output.” In each case, a ZK proof can be produced that is short, quickly verifiable, and reveals nothing about the underlying secret data. For a long time this was a purely theoretical construction; in the last decade it has become practical enough to run in production, and it is now one of the most important primitives in cryptography applied to blockchains.
SNARKs and STARKs
The two main families of modern zero-knowledge proofs used in crypto are SNARKs (Succinct Non-interactive Arguments of Knowledge) and STARKs (Scalable Transparent Arguments of Knowledge). Both produce short proofs of arbitrary computations, but they differ in their underlying math and their tradeoffs.
SNARKs were the first practical system, popularised by the Zerocash paper (which became Zcash) in 2014. The dominant construction is Groth16, which produces extremely short proofs (around 200 bytes) that verify quickly. The main downside is that Groth16 requires a “trusted setup” ceremony to generate the initial cryptographic parameters, and if the participants in that ceremony collude they can forge proofs. Zcash’s Powers of Tau ceremony is the canonical example of how these setups are handled in practice — many independent participants each contribute randomness, and as long as at least one was honest and destroyed their contribution, the setup is secure. Newer SNARK constructions (PLONK, Halo2, Marlin) have various improvements, including universal trusted setups that only need to be done once for any circuit.
STARKs, developed by Eli Ben-Sasson and the StarkWare team, replace the trusted setup with a different cryptographic assumption (collision resistance of hash functions, rather than elliptic curve discrete logarithm) and produce larger proofs (tens of kilobytes) that also take longer to generate but are considered post-quantum secure. STARKs power Starknet and other StarkWare products and are the main alternative to SNARKs for high-throughput ZK rollups.
The practical differences between the two families are narrowing. SNARK proving has gotten much faster with recursive constructions and better hardware, and STARK proving has gotten more efficient too. The choice between them is increasingly a matter of specific engineering tradeoffs rather than a fundamental divide, and several projects are using both in different parts of their stack.
What ZK Proofs Enable in Practice
The applications of ZK proofs in crypto split into a few broad categories.
Scalability. ZK rollups use proofs to compress many L2 transactions into a single proof that is verified on L1. Instead of L1 re-executing every L2 transaction, L1 just verifies the proof that says “this state transition is valid according to the rules”. The cost savings are dramatic — a ZK rollup can process thousands of transactions and post a single proof to L1 that verifies the whole batch. This is the use case where ZK has had the biggest production impact, and it is the reason chains like zkSync Era, Starknet, Linea, Scroll, and Polygon zkEVM exist.
Privacy. ZK proofs can let you prove facts about your state without revealing the state itself. Zcash uses this to let users transact without revealing sender, receiver, or amount. Tornado Cash used this to let users deposit and withdraw without the link between the two being public. More recent systems (Aztec, Railway, various other shielded-pool designs) extend this to arbitrary Ethereum transactions. The privacy use case is the oldest application of ZK in crypto, and it has been more politically contested than the scalability use case because privacy-preserving tools have become targets of regulation (Tornado Cash’s sanctions by OFAC being the most prominent case).
Identity and credentials. ZK proofs can let you prove things about yourself without revealing unnecessary information. “I am over 18” can be proven from a government-issued credential without revealing your exact birth date. “I am a verified customer of bank X” can be proven from the bank’s attestation without revealing your account details. “I am in a specific allowlist” can be proven from a Merkle proof without revealing which entry in the list you are. This application is still mostly in the research and early-deployment phase, but it is one of the areas where ZK could have the largest long-term impact if the tooling matures.
Cross-chain messaging. A light client for chain A running on chain B can use ZK proofs to verify chain A’s state without having to run a full node. This lets bridges and cross-chain messaging systems be trust-minimised in a way that traditional validator-based bridges are not, and several projects (Succinct, Polyhedra, zkBridge) are building in this direction.
Why ZK Took So Long
Zero-knowledge proofs were theorised in the 1980s and known to be cryptographically possible for decades before they became practical. The reason they did not reach production earlier is that the original constructions required astronomical amounts of computation to produce — minutes to hours for even simple proofs, running into terabytes of memory, on problems that were trivial by normal computer science standards. Making ZK efficient enough to be used on real systems required a long series of theoretical improvements (polynomial commitments, arithmetization techniques, better hash function choices, hardware acceleration) that only came together in the 2020s.
The current state is that ZK proving is fast enough to be used in production but still expensive enough that it dominates the cost of running a ZK rollup. Improving prover efficiency — through specialised hardware (ASIC provers), better circuits, better algorithms — is one of the most active research areas in cryptography, and costs have been dropping by roughly an order of magnitude every two years. If this trajectory continues, ZK proofs will eventually become cheap enough to be ambient — used in many places where today they are considered too expensive — and the impact on blockchain infrastructure could be substantial. That future is a few years out, but it is no longer a fantasy.