How zero-knowledge proofs work and why they matter for privacy

You can prove you are over 18 without revealing your birthday. You can prove you have enough money for a transaction without revealing your balance. You can prove a computation was performed correctly without revealing the inputs. Zero-knowledge proofs make all of this possible, and they are quietly becoming the most important cryptographic primitive in blockchain since the hash function.

Most introductions to zero-knowledge proofs start with the Ali Baba cave analogy, where someone proves they know the secret word to open a door by consistently exiting from the side a verifier requests, without ever revealing the word. The analogy is charming and completely useless for understanding why ZK proofs matter in practice. It tells you that such a proof is possible. It does not tell you why anyone would need one on a blockchain.

The practical starting point is simpler. Every blockchain faces the same tension: transparency enables trust, but transparency also destroys privacy. Bitcoin’s ledger is public. Every transaction, every balance, every address is visible to anyone. Ethereum is the same. This transparency is what makes the system auditable and trustworthy, but it also means that anyone who learns which address belongs to you can see every transaction you have ever made, every token you hold, and every protocol you have interacted with.

Zero-knowledge proofs resolve this tension. They let you prove facts about your data without revealing the data itself. You can prove your account balance exceeds a threshold without revealing the exact balance. You can prove a transaction is valid without revealing the sender, recipient, or amount. You can prove you are not on a sanctions list without revealing your identity.

The mathematics behind this are deep. The applications are immediate.

The three properties every ZK proof must have

Every zero-knowledge proof system must satisfy three properties, and understanding them is essential for evaluating any ZK-based protocol.

Completeness. If the statement is true and both the prover and verifier follow the protocol, the verifier will always be convinced. A valid proof never fails to verify. If you genuinely know the secret, the proof will always work.

Soundness. If the statement is false, no cheating prover can convince the verifier that it is true, except with negligible probability. A dishonest prover cannot fabricate a valid proof. The probability of a false proof passing verification is so small (typically less than one in 2^128) that it is effectively impossible.

Zero-knowledge. The verifier learns nothing beyond the fact that the statement is true. The proof does not leak any information about the secret itself, any intermediate computation, or any data used to generate the proof. The verifier’s knowledge after seeing the proof is identical to what it would be if someone simply told them the statement was true.

The third property is what makes ZK proofs useful rather than merely correct. Standard digital signatures prove that a message was signed by a specific key, but they reveal the message content. Standard hash commitments prove that a value was committed, but they reveal the value when opened. ZK proofs prove that a relationship holds between secret values without revealing those values at any point.

How zk-SNARKs and zk-STARKs differ

The two dominant ZK proof systems in blockchain are zk-SNARKs and zk-STARKs. They solve the same problem with different tradeoffs.

zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) produce small proofs that are fast to verify. A typical zk-SNARK proof is around 200 to 300 bytes and can be verified on chain for approximately 200,000 to 300,000 gas on Ethereum. The verification time is constant regardless of how complex the computation being proved is. A proof that verifies a single transaction takes the same time to check as a proof that verifies ten thousand transactions.

The cost of this succinctness is a trusted setup. Most zk-SNARK systems require a one time ceremony where random parameters are generated and the randomness is destroyed afterward. If the randomness from this ceremony is not properly destroyed, an attacker could forge proofs. Zcash conducted one of the most elaborate trusted setup ceremonies in cryptographic history (the “Powers of Tau” ceremony) involving hundreds of participants worldwide, where the security assumption is that at least one participant honestly destroyed their randomness.

Newer SNARK systems like PLONK and Halo 2 have reduced or eliminated the trusted setup requirement, but the perception persists. Some projects avoid SNARKs specifically because of the trusted setup concern, even when the implementations they would use do not require one.

zk-STARKs (Zero-Knowledge Scalable Transparent Arguments of Knowledge) eliminate the trusted setup entirely. They derive their security from hash functions rather than elliptic curve assumptions, which makes them transparent (no secret parameters) and theoretically quantum resistant (hash based cryptography is believed to be secure against quantum computers, while elliptic curve cryptography is not).

The tradeoff is size. STARK proofs are significantly larger than SNARK proofs, typically tens to hundreds of kilobytes compared to hundreds of bytes. On a blockchain where data storage costs gas, larger proofs mean higher verification costs. StarkWare, the primary developer of STARK technology, addresses this by using recursive proof composition: proving that a proof is valid, then proving that the proof of the proof is valid, compressing the final on chain footprint.

In practice, the distinction matters less than it did five years ago. Modern proof systems increasingly blend techniques from both families, and the engineering focus has shifted from which proof system to use to how fast the prover can generate proofs and how cheaply the verifier can check them.

ZK proofs for blockchain scaling

The scaling application of ZK proofs is conceptually straightforward. A rollup executes a batch of transactions off chain, generates a proof that the batch was executed correctly, and posts the proof to Ethereum. The Ethereum verifier contract checks the proof in a single operation and accepts the new state.

What makes this powerful is the asymmetry between proving and verifying. Generating the proof for a batch of 10,000 transactions might take a powerful machine several minutes. Verifying the proof takes a fraction of a second and costs a fixed amount of gas regardless of how many transactions are in the batch. This asymmetry is what allows ZK rollups to compress thousands of transactions into a single Ethereum verification.

The major ZK rollups each take a different approach to this architecture.

zkSync Era uses a custom virtual machine (zkEVM) that is compatible with Solidity at the language level but compiles to a different instruction set optimized for ZK proof generation. Existing Ethereum contracts can be recompiled for zkSync with minimal changes.

StarkNet uses the Cairo programming language and STARK proofs. Cairo is a purpose-built language designed specifically for provable computation, which gives it performance advantages but requires developers to learn a new language and paradigm.

Polygon zkEVM aims for EVM equivalence, meaning it can execute the same bytecode as Ethereum without recompilation. This maximizes compatibility but introduces engineering complexity in making every EVM opcode provable.

Scroll also targets full EVM equivalence and uses a community-driven approach to its zkEVM implementation, with the goal of being the most Ethereum-compatible ZK rollup.

The competition between these approaches is ultimately a competition between compatibility and performance. The more compatible a ZK rollup is with existing Ethereum tooling, the easier it is for developers to migrate. The more the rollup optimizes its instruction set for provability, the faster and cheaper its proofs become.

ZK proofs for privacy

The privacy application is where ZK proofs become most consequential and most controversial.

A standard Ethereum transaction reveals the sender address, the recipient address, the amount transferred, and the smart contract called. This information is permanently public. Chain analysis firms like Chainalysis and Elliptic have built entire businesses on tracing transaction flows across the transparent ledger, linking addresses to real world identities through exchange KYC data, known entity labels, and behavioral patterns.

ZK privacy protocols break this chain of visibility. In a ZK-based private transaction, the user generates a proof that their transaction is valid (the sender has sufficient funds, no double spending occurs, the amounts balance) without revealing who sent it, who received it, or how much was transferred. The proof is posted on chain and verified by the network, but the underlying transaction details remain encrypted.

Zcash was the first major implementation of this concept, launching in 2016 with shielded transactions using zk-SNARKs. A Zcash user can choose between transparent transactions (identical to Bitcoin’s public ledger) and shielded transactions (where the sender, recipient, and amount are hidden behind a ZK proof). In practice, shielded transaction adoption on Zcash has been lower than proponents hoped, with the majority of ZCash transactions still using the transparent pool.

Newer protocols are building programmable privacy, where not just token transfers but arbitrary smart contract logic can execute privately. Aztec Network is building a privacy-first layer 2 on Ethereum where all transactions are private by default. Aleo is building a layer 1 blockchain with native ZK support for private smart contracts. Both use ZK proofs to verify state transitions without revealing the computation or data involved.

The potential for privacy extends beyond individual transactions. ZK proofs can enable private voting (prove you voted without revealing your choice), private identity verification (prove you are a citizen of a specific country without revealing your passport number), and private DeFi (provide liquidity to a pool without revealing your address or position size).

The regulatory collision

Privacy in crypto occupies a contested legal space that is still being defined.

In August 2022, the U.S. Treasury’s Office of Foreign Assets Control (OFAC) sanctioned Tornado Cash, an Ethereum-based mixer that used ZK proofs to break the link between deposit and withdrawal addresses. The sanctioning of open source smart contract code, rather than a person or company, was unprecedented and sent shockwaves through the crypto privacy community.

In May 2024, Alexey Pertsev, one of Tornado Cash’s developers, was convicted by a Dutch court of money laundering facilitation. The conviction established a legal precedent that writing privacy-preserving code can carry criminal liability if the tool is used for illicit purposes, regardless of whether the developer personally facilitated the illegal activity.

These actions have shaped the direction of ZK privacy development. The current generation of privacy protocols is building around regulatory constraints rather than ignoring them.

Selective disclosure allows a user to prove specific facts about their identity or transaction history without revealing everything. A user could prove they passed KYC with a licensed exchange, prove they are not on the OFAC sanctions list, or prove their funds did not originate from a sanctioned address, all using ZK proofs that reveal nothing beyond the specific claim being verified.

Privacy pools, a concept formalized by Vitalik Buterin and others, allow users to prove that their withdrawal from a privacy set belongs to a clean subset of deposits. Instead of mixing all deposits together indiscriminately, the protocol maintains association sets that exclude known illicit addresses. Users prove membership in the clean set without revealing which specific deposit they are withdrawing.

Whether these compromises satisfy regulators remains to be seen. The fundamental tension, that privacy and surveillance are architecturally incompatible, will not be resolved by technology alone. ZK proofs give policymakers a tool they have never had before: the ability to verify compliance without requiring disclosure. Whether they choose to use it is a political question, not a cryptographic one.

The proving cost has concrete implications for which applications adopt ZK technology first. High value financial transactions, where the cost of generating a proof is negligible relative to the transaction size, have been the earliest adopters. Institutional cross-chain transfers, large DeFi positions, and enterprise settlement systems can absorb a proving cost of several dollars per transaction without affecting their economics. Consumer applications, where individual transactions may be worth only a few dollars, need proving costs to fall by another order of magnitude before ZK privacy becomes practical for everyday use. The hardware acceleration efforts by companies building ZK-specific ASICs are directly targeting this cost barrier.

The convergence of scaling and privacy applications is perhaps the most underappreciated aspect of ZK technology. A ZK rollup that processes transactions privately would combine the throughput benefits of off chain execution with the confidentiality benefits of encrypted state transitions. Users would get fast, cheap transactions that are also invisible to chain analysis. Several projects, including Aztec and Polygon Miden, are building exactly this combination, though the engineering complexity of merging both capabilities into a production system remains substantial.

What this does not cover

This article does not cover the mathematics of polynomial commitments, elliptic curve pairings, or Fiat-Shamir transformations that underpin ZK proof systems. Understanding these requires graduate level abstract algebra and is not necessary for evaluating ZK-based protocols as a user or investor.

This article does not cover ZK machine learning (zkML), an emerging field that uses ZK proofs to verify that a machine learning model produced a specific output without revealing the model’s weights or training data. This application is experimental and its practical implications are still being studied.

This article does not address the hardware acceleration race for ZK proof generation. Companies like Cysic, Ingonyama, and Fabric Cryptography are building custom ASICs and FPGAs specifically for ZK proving, which could reduce proving costs by orders of magnitude. The hardware landscape is moving too quickly for static analysis.

Practical checks before using a ZK-based protocol

Verify the proof system’s audit status. ZK proof systems are mathematically complex and implementation errors can be catastrophic. A bug in the circuit (the mathematical representation of the computation being proved) could allow an attacker to forge proofs and mint tokens or steal funds. Check whether the proof system and its circuits have been audited by firms specializing in ZK cryptography, not just general smart contract auditors.

Understand what is actually private. Not all ZK-based protocols provide the same level of privacy. Some hide transaction amounts but reveal addresses. Some hide addresses but reveal amounts. Some hide everything. Read the protocol’s documentation to understand exactly what information is concealed and what remains visible. Metadata such as transaction timing, gas patterns, and interaction frequency can often deanonymize users even when the core transaction data is hidden.

Check the trusted setup status. If the protocol uses zk-SNARKs, determine whether it required a trusted setup and how that setup was conducted. Multi-party computation ceremonies with hundreds of participants are more trustworthy than small ceremonies with a handful of known entities. Protocols using STARKs, PLONK with universal setup, or Halo 2 do not require trusted setups at all.

Assess the regulatory risk. Privacy protocols operate in a legally uncertain environment. Consider whether the protocol has a compliance mechanism (selective disclosure, privacy pools, opt-in compliance proofs) and whether that mechanism has been tested against actual regulatory scrutiny. Using a privacy protocol that is later sanctioned could complicate your ability to move or sell assets.

Test the proving time. Generating a ZK proof is computationally intensive. On a mobile device, proving a simple transaction might take 30 seconds to two minutes. On a desktop, it might take a few seconds. If the proving time is too long for your use case, the protocol may not be practical for frequent transactions. Some protocols offload proving to dedicated servers, which is faster but introduces a trust assumption that the server does not learn your private data.

Disclaimer: This article is for informational and educational purposes only. It does not constitute financial, investment, or legal advice. Cryptocurrency markets are volatile and carry significant risk. Always conduct your own research before making investment decisions.