zk-SNARKs

What Are zk-SNARKs?

A zero-knowledge proof is a way of convincing someone that a statement is true without revealing why it is true. The concept was introduced by Goldwasser, Micali, and Rackoff in 1985, but practical applications had to wait for decades of research to make the proofs small and fast enough to be useful. zk-SNARKs, formalised in their modern form by a 2012 paper from Nir Bitansky and colleagues, were the first construction efficient enough to be deployed at scale on a public network.

The most concrete example comes from privacy-preserving cryptocurrencies. Zcash, launched in October 2016, was the first major deployment of zk-SNARKs in production. A Zcash transaction can prove that the sender owns enough funds, that the inputs match the outputs, and that no double-spend is occurring — all without revealing who is sending what to whom.

Beyond privacy, the second major application is scalability. A zk-rollup is a Layer 2 system that processes thousands of transactions off-chain and submits a single zk-SNARK to the main blockchain proving that all those transactions were valid. The main chain verifies one small proof — through a verification smart contract — instead of replaying every transaction, which compresses computational cost dramatically while preserving the security guarantees of the underlying chain. zkSync, Starknet, Polygon zkEVM, and Linea all use variants of this approach.

How Do zk-SNARKs Work?

The high-level recipe has three steps. First, the statement to be proved is encoded as a mathematical circuit — a fixed sequence of additions and multiplications over a large prime field that returns “true” if and only if the statement is true. Second, the prover runs the computation and produces a proof that combines the inputs, intermediate values, and a set of cryptographic commitments. Third, the verifier checks the proof against a small piece of public data (called the verification key) and accepts or rejects without ever seeing the inputs.

Consider a worked example. Suppose you want to prove you know the password to an account without revealing it. You construct a circuit that takes the password as input, hashes it, and checks whether the hash matches the publicly known hash on file. You run the circuit privately, producing a zk-SNARK proof. The verifier checks the proof in a fraction of a second using only the verification key and the known hash; the proof confirms that you ran the computation with some input producing the correct hash, without revealing what that input was. The same structure scales to far more complex statements — for example, “I executed 10,000 valid Ethereum transactions and the resulting state root is X.”

The “succinct” property is what makes zk-SNARKs practical. A proof is typically 200 to 300 bytes and takes milliseconds to verify, regardless of how much work was originally proved. Generating the proof, by contrast, is expensive — sometimes thousands of times more than running the original computation — but this asymmetry is precisely what makes the technology useful for blockchains, where many verifiers need to check work done once by a single prover.

The Trusted Setup Problem

The biggest historical concern with zk-SNARKs is the trusted setup. The proving and verification keys are generated together at the start of the system, using random values that must then be permanently destroyed. If any participant in the setup ceremony retains those values, they can forge proofs that the verifier will accept as valid. Zcash’s original setup used six participants in a ceremony designed so that the system is safe as long as at least one participant honestly destroyed their values. Subsequent setups have used hundreds of participants to make collusion implausible, but the requirement remains a real downside and is part of why zk-STARKs — which require no trusted setup — emerged as an alternative.

Why Are zk-SNARKs Important for Traders?

For anyone using crypto markets at scale, zk-SNARKs are quietly becoming part of the infrastructure they trade on. zk-rollups process the majority of Ethereum-compatible transaction volume on major Layer 2 networks, and the validity guarantees those rollups inherit from the underlying chain — secured by proof-of-stake after Ethereum’s transition — come directly from zk-SNARK verification. Funds deposited into a zk-rollup are protected by the property that the rollup’s state transitions are mathematically proved correct — not just attested to by a small group of operators. This is a stronger guarantee than the fraud-proof model used by optimistic rollups.

The structural limitation is that zk-SNARK proving remains computationally expensive. Generating a proof for a complex circuit can require specialised hardware and significant time, which limits how quickly some applications can produce them. This has practical consequences: zk-rollups typically batch transactions over minutes before producing a single proof, meaning user transactions are not immediately final on the underlying chain. The trade-off — strong security with delayed settlement — is different from optimistic rollups, and choosing between them depends on what the application prioritises.

The wider implication is that proof systems are improving rapidly. Each generation — Groth16, PLONK, Halo, Halo 2, recent successors — has reduced proving cost, eliminated or weakened the trusted setup requirement, and broadened the range of computations that can be proven efficiently. For practical purposes, the security and cost differences between major Layer 2 networks already matter less than a year ago, and assuming today’s trade-offs will persist is a mistake when modelling longer-term risk.

Key Takeaways

• zk-SNARKs are cryptographic proofs that demonstrate knowledge of a secret or correct execution of a computation, without revealing the secret or requiring the verifier to redo the work.
• The acronym stands for Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge — succinct because the proof is small (around 200 bytes) and non-interactive because no back-and-forth with the prover is needed.
• The first major production deployment was Zcash in October 2016, which uses zk-SNARKs to hide sender, receiver, and amount on a public blockchain while still proving that the transaction is valid.
• The largest current use is in zk-rollups — Layer 2 networks like zkSync, Starknet, Polygon zkEVM, and Linea that compress thousands of transactions into a single small proof verified on the underlying chain.
• The main historical drawback is the trusted setup: a one-time ceremony generates the keys, and any participant who retains their random values can forge proofs — which is why modern setups use hundreds of participants and why zk-STARKs, which need no trusted setup, exist as an alternative.