Zero-Knowledge Proofs: What They Actually Prove (And What They Don't)

# Zero-Knowledge Proofs: What They Actually Prove (And What They Don't)

The term "zero-knowledge proof" has been absorbed by crypto marketing to mean roughly anything that sounds private and mathematically impressive. It's worth being more precise, because ZK technology is genuinely transformative — but what it transforms and what it doesn't are different things than most coverage suggests.

## The Core Claim

A zero-knowledge proof lets a prover convince a verifier that they know something — a secret, a computation result, a valid state transition — without revealing what that something actually is. The verifier learns only one fact: the prover's claim is true. Nothing else leaks.

This sounds almost paradoxical. How can you prove you know a secret without revealing it? The mathematics relies on the fact that some problems are easy to verify but hard to solve. If I tell you I have a solution to a Sudoku puzzle, you can verify it in seconds. Constructing the solution from scratch is much harder. ZK proofs exploit this asymmetry in more sophisticated mathematical structures — typically elliptic curves, polynomial commitments, or hash functions.

## ZK-SNARKs: Succinct, Non-Interactive, But With a Catch

SNARKs (Succinct Non-interactive ARguments of Knowledge) are what made ZK practical at scale. "Succinct" means the proof is small and fast to verify even when the underlying computation is huge. "Non-interactive" means the prover doesn't need a back-and-forth with the verifier — they generate the proof once, and anyone can check it.

The catch is the trusted setup. Most SNARK constructions require a one-time ceremony where cryptographic parameters are generated — a "common reference string" that both prover and verifier use. The dangerous bit: whoever generates this setup knows a secret (often called "toxic waste") that, if retained, would let them generate fake proofs.

Zcash's 2016 trusted setup ceremony involved six participants in different countries, destroying their intermediate parameters, generating their contribution in a tamper-evident way. The security assumption is that at least one participant destroyed their toxic waste honestly. One. If all six coordinated to keep it, they could mint arbitrary Zcash undetected.

PLONK and subsequent SNARK variants improved this with "universal" trusted setups that work across many different circuits, reducing the need for per-application ceremonies. But you're still trusting a setup process, which is a meaningful assumption.

## ZK-STARKs: Trustless But Larger

STARKs (Scalable Transparent ARguments of Knowledge) eliminate the trusted setup entirely. They're based on collision-resistant hash functions rather than elliptic curve pairings, which also makes them post-quantum resistant — a bonus that may matter in thirty years.

The tradeoff is size. STARK proofs are substantially larger than SNARK proofs — kilobytes versus hundreds of bytes. For rollup use cases where proof size directly translates to on-chain calldata cost, this matters. StarkNet uses STARKs and accepts the overhead in exchange for the transparency; zkSync Era uses SNARKs and Plonky2 (a PLONK-based hybrid) to get smaller proofs.

## What ZK Actually Proves in Practice

Here's what ZK rollups are actually doing: a sequencer executes thousands of transactions off-chain, then generates a ZK proof that those transactions were executed correctly according to the EVM rules. The Ethereum mainnet verifies the proof — not the transactions themselves. It checks a mathematical certificate of correctness.

This is a meaningful security improvement over optimistic rollups (which assume transactions are correct and rely on fraud proofs). ZK proofs don't need a challenge period; if the proof verifies, the state is valid. The finality is immediate.

What ZK doesn't prove: that the underlying transactions are good for you personally, that the sequencer isn't censoring you, or that the smart contracts you're calling have no bugs. A ZK proof that your transaction was executed correctly is not a guarantee that the contract logic it called is safe. That's a different problem.

## zkSync vs StarkNet: Two Philosophies

zkSync Era went for EVM equivalence — a ZK-EVM that runs existing Solidity code with minimal changes. The pitch to developers is: port your existing contracts. The engineering cost was enormous; the EVM's design wasn't built with ZK-friendliness in mind.

StarkNet built its own Cairo language, which is ZK-native. Cairo code compiles more efficiently to STARK proofs. The developer experience is different — you're learning a new language — but the performance ceiling is higher.

My view: ZK is real infrastructure that's changing what's possible on-chain. The privacy applications are obvious; the scalability case is already demonstrated. What it's not is a magic security layer that makes DeFi safe. It proves execution correctness. Whether what's being executed is worth executing is still your problem.

Zero-Knowledge Proofs: What They Actually Prove (And What They Don't)

// COMMENTS

ON THIS PAGE