Zero-Knowledge Proofs: Why the Technology Outruns Its Own Story

Zero-knowledge proofs are in a weird spot. On one side, cryptographers and protocol engineers treat them as a settled revolution—a primitive that solves privacy, scalability, and verifiability in a single mathematical stroke. On the other, the broader technical community still squints at the term, half-expecting a sleight of hand. The gap between what ZKPs can do and how they’re described isn’t just a branding hiccup. It’s a technical communication failure that leaves a genuinely powerful tool looking like a niche cryptographic curiosity.

Dmitri Okafor here. I spend my days deep in consensus logic and state transition functions. I’m not here to sell you a blockchain. What I care about is why a method that can prove a statement is true without revealing the statement itself gets pitched like a vitamin supplement. The technology deserves a sharper, more honest explanation. This is my attempt to provide one.

The Proof Itself: What a ZKP Actually Does

Let’s strip the jargon. A zero-knowledge proof is a protocol between a prover and a verifier. The prover demonstrates that a specific computational statement is true—without handing over the private inputs that make it true. The verifier learns nothing beyond the fact that the statement checks out. That’s the “zero-knowledge” part. The proof itself is a compact, easy-to-check string of data.

Take a classic example: proving you know the solution to a Sudoku puzzle without showing the filled-in grid. In a physical world, you might rely on a trusted referee to shuffle things around and confirm correctness. In a ZKP, mathematics replaces the referee. The prover generates a proof that a valid solution exists for a given public puzzle. The verifier checks the proof against the puzzle. The verifier never sees the solution. The proof is a cryptographic commitment that binds the prover to a valid witness without exposing it.

This is not encryption. Encryption hides data in transit or at rest, but someone eventually decrypts it to see the plaintext. A ZKP can prove properties of the plaintext without ever decrypting it. Encryption protects the channel; ZKPs protect the computation itself. That distinction is the whole game.

The Engineering Reality: SNARKs, STARKs, and the Trade-offs Nobody Mentions

Most marketing flattens all ZKPs into one indistinguishable blob. The engineering reality is a family of proving systems with sharp trade-offs. The two heavyweights are SNARKs and STARKs.

SNARKs—Succinct Non-interactive Arguments of Knowledge—produce tiny proofs, often just a few hundred bytes, and verify quickly. The catch is the trusted setup: a one-time ceremony where participants generate public parameters using secret randomness. If the secrets leak, false proofs can be forged. Projects have worked to decentralize these ceremonies, but the trust assumption lingers. SNARKs also lean on elliptic curve cryptography, which a sufficiently powerful quantum computer could break. Not an immediate threat, but a real durability concern for systems meant to last decades.

STARKs—Scalable Transparent Arguments of Knowledge—ditch the trusted setup and use hash functions that are plausibly quantum-resistant. The trade-off is proof size. STARK proofs are larger, often tens or hundreds of kilobytes, and verification, while still fast, isn’t as lean as SNARK verification. For a rollup posting data to Ethereum, a 100 KB STARK proof versus a 200-byte SNARK proof translates directly into different cost structures. The choice between them is an engineering decision about trust assumptions, proof size, and verification gas costs. It’s not about which is “better” in a vacuum.

The Marketing Problem: Selling Math as Magic

The way ZKPs get talked about in public forums often skips the hard parts. Press releases toss around phrases like “complete privacy” and “unhackable.” These aren’t just imprecise; they’re misleading. A ZKP system is only as sound as its cryptographic assumptions and its implementation. A bug in the constraint system—the arithmetic circuit that encodes the statement being proved—can produce a proof that verifies correctly but attests to a false statement. This isn’t theoretical. Vulnerabilities in ZKP implementations have been documented, including cases where missing constraints let attackers mint tokens from nothing.

The marketing also tends to conflate zero-knowledge proofs with zero-knowledge rollups, as if the two are synonymous. A ZK-rollup uses a validity proof (often a SNARK or STARK) to batch transactions and post a single proof on-chain. The “zero-knowledge” part is optional. Many rollups don’t use the privacy property at all; they use the succinctness property. Calling them “validity rollups” would be more accurate, but “ZK-rollup” has stuck because it sounds more advanced. This sloppiness obscures what the technology actually delivers and makes it harder for engineers to evaluate trade-offs.

Where the Technology Actually Bites

ZKPs are not a universal solvent. They’re a specific tool for a specific class of problems: proving computational integrity while keeping inputs private. The overhead of generating a proof is substantial. For a general computation, the prover may need to execute the equivalent of millions of CPU cycles to produce a single proof. This makes ZKPs impractical for many real-time applications unless the computation is heavily optimized or the proving work is offloaded to specialized hardware.

There’s also the question of what you’re proving. A ZKP can prove that a computation was executed correctly, but it cannot prove that the computation was the right one to execute. If a smart contract contains a logical error, a ZKP will faithfully prove that the erroneous logic was followed. The proof is only as sound as the statement it attests to. This is a subtle but critical point that gets lost when ZKPs are presented as a blanket security guarantee.

Then there’s the data availability problem. A ZKP can prove that a state transition is valid, but it cannot prove that the data needed to reconstruct the state is available. If a rollup operator publishes a proof but withholds the transaction data, users cannot know their balances or force an exit. This is why modern rollup designs couple validity proofs with data availability layers. The ZKP is one component in a larger system, not a standalone solution.

Why the Abstraction Gap Matters

The gap between what ZKPs can do and how they’re described has consequences. When a technology is oversold, the inevitable failures—a broken circuit, a trusted setup compromise, a performance bottleneck—erode confidence not just in the specific implementation but in the entire primitive. Engineers who might build useful applications become skeptical. Funding flows to projects with the best narratives rather than the soundest architectures.

There’s also a missed opportunity in education. ZKPs are genuinely interesting. The idea that you can prove you know a secret without revealing it, or that you can compress a large computation into a tiny, verifiable proof, is a profound result in computer science. It deserves to be explained with precision, not buried under buzzwords. A technically accurate description of a SNARK—a polynomial commitment scheme combined with a cryptographic pairing check—is more compelling to the right audience than “a revolutionary privacy layer.”

What Better Communication Looks Like

Better marketing for ZKPs doesn’t mean dumbing them down. It means being specific about what they do, what they cost, and where they break. A good technical description answers four questions:

• What is the exact statement being proven? Is it “I know a private key corresponding to this public key” or “this batch of transactions is valid according to these state transition rules”? The difference matters.
• What are the trust assumptions? Is there a trusted setup? If so, how was it conducted and who participated? If the setup is transparent, what is the cryptographic hardness assumption?
• What are the performance characteristics? Proving time, verification time, proof size, memory usage. These are not afterthoughts; they determine feasibility.
• What happens when things go wrong? What are the failure modes? Can a malicious prover generate a false proof if a constraint is missing? What is the recovery path?

Answering these questions doesn’t require a PhD. It requires a commitment to treating the audience as capable of understanding trade-offs. The engineers and architects evaluating ZKP-based systems are not looking for magic. They’re looking for a clear specification.

ZKPs in Practice: Identity, Scaling, and Machine Learning

ZKPs are not a solution in search of a problem. They’re already deployed in several domains, though the details are often glossed over.

In digital identity, ZKPs enable selective disclosure. A user can prove they’re over 18 without revealing their exact birthdate, or prove they’re a citizen of a specific country without showing a passport number. The proof is a mathematical statement about a signed credential. The verifier checks the proof and the issuer’s signature, learning nothing else. This isn’t a hypothetical; it’s the architecture behind systems like the EU Digital Identity Wallet’s technical specifications.

In blockchain scaling, validity proofs allow a single node to execute a batch of transactions, generate a proof of correct execution, and post that proof on-chain. Every other node verifies the proof instead of re-executing the transactions. This shifts the computational burden from the entire network to a single prover, enabling higher throughput. The trade-off is that proof generation is resource-intensive and may require specialized hardware, creating centralization pressures on the proving side.

In machine learning, ZKPs can attest that a model was trained on a specific dataset or that an inference was computed correctly, without revealing the model weights or the input data. This is early-stage work. The proving overhead for large neural networks is still prohibitive, but the direction is clear: verifiable computation for proprietary models.

FAQ

What is the difference between a ZKP and a validity proof?

A validity proof is a broader concept: it’s any proof that a computation was executed correctly. A ZKP is a specific type of validity proof that also hides the witness (the private inputs). Many “ZK-rollups” actually use validity proofs without the zero-knowledge property. They’re more accurately called “validity rollups.” The confusion arises because the same underlying proving systems (like SNARKs and STARKs) can be used in both modes.

Are ZKPs secure against quantum computers?

It depends on the proving system. STARKs rely on collision-resistant hash functions, which are believed to be quantum-resistant. SNARKs typically rely on elliptic curve pairings, which are vulnerable to Shor’s algorithm on a sufficiently powerful quantum computer. There are also lattice-based ZKP constructions that are quantum-resistant. The answer isn’t a simple yes or no; it depends on the cryptographic primitives used.

Why don’t we use ZKPs for everything if they’re so powerful?

Proving overhead is the main bottleneck. Generating a ZKP for a general computation can be thousands or millions of times slower than executing the computation directly. This makes ZKPs impractical for many real-time or resource-constrained applications. Additionally, expressing a computation as an arithmetic circuit is a specialized skill, and the tooling is still maturing. ZKPs are powerful but not free, and they’re not a drop-in replacement for all forms of verification.

What is the difference between a SNARK and a STARK?

SNARKs (Succinct Non-interactive Arguments of Knowledge) produce very small proofs and fast verification but typically require a trusted setup and use elliptic curve cryptography, which is not quantum-resistant. STARKs (Scalable Transparent Arguments of Knowledge) eliminate the trusted setup, use hash functions that are plausibly quantum-resistant, and scale better to large computations, but produce larger proofs. The choice between them is an engineering trade-off based on the specific requirements of the system.