LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

Zero-Knowledge Proofs Without the Math Dump

16 min read Cryptography Deep Dives
cryptographyzero-knowledgezk-snarkzk-starkprivacyblockchain
Contents

Zero-knowledge proofs are one of the more genuinely strange things in modern cryptography: a way for one party (the prover) to convince another (the verifier) that a statement is true while revealing nothing beyond its truth. Not the witness that makes it true, not the values involved, not anything beyond the fact “yes, this statement holds.” Described that way it sounds like wishful thinking, but it turns out to be a real mathematical construction that has been refined over forty years of academic research and, in the last five, has finally hit production at scale — primarily in blockchain rollups that compress thousands of transactions into a single proof, in privacy systems that let you prove you are over 18 without revealing your birthday, in identity protocols that let you prove you hold a credential without disclosing the credential itself. The technology has also generated a remarkable amount of hype, much of it disconnected from what zero-knowledge proofs actually do well in 2026. This post walks what ZK actually proves and how, without dropping into the algebra; the engineering split between zk-SNARKs and zk-STARKs and what each is good at; the trusted-setup ceremony some SNARK families require and why it is a real concern; the honest applications worth knowing about versus the ones that are mostly hype; and the surprisingly large proving and verification costs that decide whether ZK is the right tool for any given problem.

What ZK Actually Proves

The cleanest way to understand zero-knowledge is through one canonical example. Suppose you want to prove to a server that you know the password matching a stored hash, without sending the password. The normal way (send the password, server hashes it, server compares to stored hash) reveals the password to anyone watching the network or to the server itself. A zero-knowledge proof lets you instead send a proof — some bytes constructed from the password — and the server can verify the proof matches the stored hash without ever seeing the password.

What is “proved” in a zero-knowledge proof is a statement of the form:

   "I know some x such that f(x) = y"

where f is a publicly known function (here, the hash function), y is a publicly known value (the stored hash), and x is the secret witness (the password). The prover convinces the verifier that they know x without revealing x. The function f can be much more complex than a hash — it can be an arbitrary computation. The statement can be much richer than “I know the password” — it can be “I know a Tornado Cash deposit note that matches this public commitment” or “I know a valid Ethereum transaction batch that produces this state root.”

The two formal properties a ZK proof must satisfy:

  • Completeness: if the statement is true and the prover knows the witness, the verifier accepts.
  • Soundness: if the statement is false, no polynomial-time prover can convince the verifier (except with negligible probability — typically around 2^-128).
  • Zero-knowledge: a verifier learns nothing about the witness x beyond the fact that the prover knows it.

These three together are why ZK is genuinely useful. Without zero-knowledge it is just a proof. Without soundness it is just an assertion. Without completeness it is just a trick. The three properties together are what enable use cases where revealing the witness would defeat the purpose.

The original zero-knowledge proofs from the 1980s (Goldwasser, Micali, Rackoff) required an interactive dialogue between prover and verifier — multiple message rounds back and forth, with the verifier challenging the prover and the prover responding. This worked but was operationally awkward. The modern systems are non-interactive: the prover produces a single message (the proof) that any verifier can check independently, with no further communication. The mathematical trick that makes non-interactive proofs work (the Fiat-Shamir heuristic) is to derive the verifier’s “challenges” from a cryptographic hash of the prover’s earlier messages, simulating the interaction without anyone actually sitting on the other side.

The SNARK vs STARK Split

In practical 2026 deployments, almost every zero-knowledge proof system in production belongs to one of two families: zk-SNARKs or zk-STARKs. The names are unfortunate but the engineering split they describe is real.

zk-SNARK stands for zero-knowledge Succinct Non-interactive ARgument of Knowledge. The defining properties: succinct (the proof is very small — typically a few hundred bytes regardless of how complex the statement is), non-interactive, and an argument of knowledge (the prover proves knowledge of a witness, not just existence). The major SNARK construction families are Groth16 (small fast proofs, requires a circuit-specific trusted setup), PLONK (universal setup, slightly larger proofs, more flexible), and Halo2 (no trusted setup once you accept some recursive setup tradeoffs). zk-SNARKs are based on elliptic-curve pairings — they use a special class of curves where bilinear pairings exist, which lets you do polynomial commitment schemes that produce tiny proofs.

zk-STARK stands for zero-knowledge Scalable Transparent ARgument of Knowledge. The defining properties: scalable (proving time scales quasi-linearly in computation size), transparent (no trusted setup at all — only public random values), and the same argument-of-knowledge nature. STARKs are based purely on cryptographic hash functions — they use polynomial commitment schemes called FRI (Fast Reed-Solomon Interactive Oracle Proofs) that produce larger proofs (tens or hundreds of kilobytes) but require no trusted setup and are post-quantum secure because they rest only on hash collision resistance rather than elliptic curve assumptions.

The engineering trade-offs are real and consequential:

Property zk-SNARK (Groth16/PLONK) zk-STARK
Proof size ~200-1500 bytes ~50-300 kilobytes
Verification time ~2-10 ms ~10-100 ms
Prover time Heavy but optimized Faster per proof
Trusted setup Required (Groth16); universal (PLONK) None
Cryptographic basis Elliptic curve pairings Hash functions only
Post-quantum security No (vulnerable to Shor’s) Yes (hash-based)
Mature implementations Many Fewer but growing
Used by Zcash, Filecoin, Mina, Polygon zkEVM, zkSync, Tornado Cash Starknet, Polygon Miden, RISC Zero

For a developer choosing in 2026:

  • For on-chain verification where gas cost matters: zk-SNARKs are dramatically better. The proof is hundreds of bytes; verification fits in a normal Ethereum transaction. The trusted setup is a real concern but well-trodden.
  • For applications wanting post-quantum security or transparency: zk-STARKs win. No setup ceremony to coordinate; security rests only on hashes.
  • For very large computations (proving billions of operations): zk-STARKs scale better. The asymptotic proving time is friendlier.
  • For small simple statements (just proving knowledge of a preimage): SNARKs are smaller and faster end-to-end.

The two families are not converging; they coexist and the right answer depends on application priorities.

The Trusted Setup Problem

The most operationally awkward thing about classical zk-SNARKs (Groth16 in particular) is the trusted setup. Before any proofs can be produced or verified, someone has to run a one-time setup ceremony that generates a structured reference string (SRS) containing public parameters. The math requires that during this ceremony, certain secret values (called “toxic waste”) be generated, used, and destroyed. If anyone retains the toxic waste, they can forge proofs that verify but correspond to false statements — total break of the soundness property.

A single party generating the toxic waste and destroying it is asking the world to trust that party. In real deployments, multi-party computation ceremonies are used: many participants each contribute randomness, the final toxic waste is the combination of all contributions, and the security guarantee is that as long as at least one participant honestly destroys their share, the setup is secure. The Zcash original ceremony (2016) used a six-person multi-party protocol; their Powers of Tau ceremony for subsequent updates was open to thousands of participants. Filecoin’s setup ran in 2020 with hundreds. Polygon zkEVM’s setup was a multi-party Groth16 ceremony in 2023.

These ceremonies are real cryptographic events with real coordination overhead. They generate suspicion among security-conscious users (justifiably — you have to trust the ceremony organizers and at least one participant). The PLONK construction reduced this concern somewhat by making the trusted setup universal — one ceremony covers all circuits up to a given size, rather than needing a fresh ceremony for each application. Halo and Halo2 went further with recursive SNARKs that do not require a permanent setup at all.

STARKs avoid the whole issue. The setup is purely public randomness — typically derived from a hash of public values, which has no secret to destroy. This is structurally cleaner and is one of the main arguments for STARKs in adversarial environments where you cannot trust ceremony organizers. For a system like Starknet that wants to support any computation without a per-circuit setup, STARKs are the natural choice.

How a ZK Proof Actually Gets Built

Without dropping into the algebra, here is the rough shape of a ZK proof’s lifecycle:

   ZK PROOF LIFECYCLE (engineer's eye view)

   1. Write the statement as an arithmetic circuit:
      "I know x such that hash(x) = 0xdeadbeef..."

      The circuit is the function f(x) expressed as a series
      of additions and multiplications modulo a prime.

      Real ZK circuits range from thousands to millions of gates.

   2. Compile the circuit into a prover-friendly form:
      - For SNARKs: R1CS (Rank-1 Constraint System) or PLONKish
        custom gates
      - For STARKs: an AIR (Algebraic Intermediate Representation)

   3. PROVER side:
      - Take secret witness x
      - Compute all intermediate wire values in the circuit
      - Encode them as a polynomial
      - Commit to the polynomial (polynomial commitment scheme)
      - Run a few rounds of opening at challenge points
      - Bundle commitments + openings as the proof

   4. Send proof to verifier (a few hundred bytes for SNARK,
      ~100 KB for STARK).

   5. VERIFIER side:
      - Receive proof
      - Recompute the challenge values via Fiat-Shamir hashing
      - Check that polynomial commitments open consistently
      - Accept or reject

   Verification is independent of the original computation's
   size; the verifier does not have to redo the computation.

This is what makes ZK so interesting for blockchain rollups. A rollup operator processes thousands of transactions off-chain, computes the resulting state change, and generates a ZK proof that the state change is correct. The Ethereum L1 receives the proof and verifies it in milliseconds — without redoing the thousands of transactions. The asymmetry between the prover (does enormous work to produce the proof) and the verifier (does tiny work to check it) is exactly the value proposition.

The same asymmetry shows up in privacy applications. A privacy-preserving identity system might have a circuit like “prove you hold a credential signed by issuer Y where the credential’s age >= 18.” The prover (your phone) runs the circuit using your actual credential as the witness; the verifier (a website) checks the proof in a few milliseconds without learning your birthday, your credential, or your identity. The website learns only “this user holds a valid age-gating credential.”

Real Applications and Honest Hype

The genuinely working zero-knowledge applications in 2026:

Zcash and the original privacy coin family. Zcash (since 2016) uses zk-SNARKs to enable fully shielded transactions where amounts and parties are hidden but proofs verify the transaction is valid. The deployment has worked for nearly a decade. The privacy-coin segment is small in the overall crypto market but established.

zkEVM rollups on Ethereum. Polygon zkEVM, zkSync, Scroll, Starknet, Linea — these compress thousands of EVM transactions into a single proof verified on Ethereum L1, dramatically reducing per-transaction cost. This is the largest production use of ZK technology by far. Transaction volume on zkSync alone often exceeds Ethereum L1’s own volume.

Filecoin’s proof of replication. Filecoin uses ZK proofs to verify that storage providers are actually holding the data they claim to. The proofs are large and slow but enable a trust-minimized decentralized storage market.

Tornado Cash (and similar mixers). A controversial application: users deposit ETH, receive a secret note, and later prove they own a valid note without revealing which deposit it came from. Sanctioned by OFAC in 2022; mathematically still works. The use case (financial privacy) and the application (sanctions-evading mixer) are separable questions; the underlying tech is solid.

Identity and credential systems. The European Digital Identity wallet specification (EUDI), W3C’s decentralized identifiers, and the Polygon ID system all use ZK proofs to enable selective disclosure of credential attributes. “Prove you are an EU citizen over 18 to access this site without revealing identity” is the model use case. Production deployments are starting in 2026 across EU member states.

Privacy-preserving voting in a few experimental deployments (Vocdoni, MACI). Functional but small.

zkML — verifiable machine learning inference. A prover proves that a specific neural network was run on a specific input, producing a specific output. Useful for verifying AI service providers without trust. Currently slow (proving even a small model takes minutes) but actively researched.

The honest hype:

  • “Zero knowledge will fix all of crypto’s problems.” No. ZK is a tool that solves specific problems (privacy with verifiability, scaling via batched verification). It does not fix custody, doesn’t fix oracle problems, doesn’t fix smart contract bugs.
  • “ZK identity will replace passwords.” Unlikely as stated. ZK identity is real and useful for credential-based authorization, but for ordinary “log in to my email” there is no real privacy benefit — the service already knows who you are.
  • “ZK-rollups make Ethereum scale infinitely.” They make it scale a lot more, but the underlying ZK proving costs are still substantial, the proofs settle on a base layer with finite throughput, and the security model still depends on the base layer.
  • “ZK protects you from surveillance.” Partially. A ZK proof reveals nothing about the witness, but metadata (when you submit a proof, your IP address, the gas you paid) leaks. A complete privacy system needs more than ZK.

The Cost: Proving Is Expensive, Verifying Is Cheap

The single most important practical thing to know about ZK is that proving is much more expensive than verifying, by many orders of magnitude. The marketing-friendly side of ZK is the tiny proof and fast verification; the unmarketed side is the prover’s compute, memory, and time cost.

Rough numbers in 2026:

  • Proving time for a small statement (proving a single hash preimage with Groth16): ~10-100 ms on a modern CPU.
  • Proving time for an Ethereum rollup batch (millions of transactions): minutes to hours on specialized hardware, often using GPU clusters or FPGAs. Polygon zkEVM and zkSync each maintain proving farms.
  • Memory required: SNARK proving for large circuits can require tens or hundreds of gigabytes of RAM, which is why dedicated proving infrastructure exists.
  • Energy cost: a single zkEVM batch proof can cost several dollars of electricity at current GPU energy rates.
  • Verification time: 2-10 ms for SNARKs, 10-100 ms for STARKs, on any commodity CPU.
  • On-chain verification gas: Groth16 verification on Ethereum is roughly 200,000 gas. PLONK is somewhat higher. STARK verification on chain is typically 500K-1M gas.

The cost asymmetry is exactly the value proposition for rollups: a rollup operator pays the proving cost once, distributes it across thousands of transactions, and pays only a small per-batch verification cost on the base layer. For an application that just wants to prove a single statement once, the prover overhead may dwarf the benefit.

The active research frontier is reducing proving cost. Custom proving hardware (Ulvetanna, Cysic, Ingonyama) is targeting 10-100x speedups for specific operations. Recursive proofs (a SNARK that verifies another SNARK) allow batching proofs together. Lookup arguments (Plookup, cq) speed up common operations like range checks. The field is moving fast; in five years, proving costs may be an order of magnitude lower than today.

For a working engineer evaluating ZK for an application, the honest checklist:

  • Do you need privacy with verifiability, or just privacy? If privacy alone suffices, simpler tools (encryption, signed assertions) are dramatically cheaper.
  • Do you need a small proof, or can you afford bandwidth? If you can ship 100 KB of proof, STARK with no setup is cleaner; if you need ~200 bytes, SNARK with trusted setup is required.
  • Are you producing many proofs from a single setup, or a single proof? ZK pays back when amortized over many proofs.
  • Can you tolerate the proving cost? Many ZK applications fail because the proving infrastructure is too expensive to operate sustainably.
  • Does the security model require post-quantum security? If yes, STARK. If not, SNARK is fine for at least a decade.

The same post-quantum-cryptography concerns that are pushing migration in other corners of cryptography also apply here: zk-SNARKs based on elliptic curve pairings would be broken by a sufficiently large quantum computer, while zk-STARKs based on hashes would not. For long-lifetime applications, this is a real consideration. For most applications today, it is a manageable risk.

Verdict

Zero-knowledge proofs are a real cryptographic primitive that does what the name suggests — lets one party prove knowledge of something to another while revealing nothing beyond the fact of knowledge — and after forty years of academic refinement, they finally hit production scale in the last five years through blockchain rollups, privacy coins, and credential systems. The engineering split that matters is zk-SNARKs versus zk-STARKs: SNARKs deliver tiny proofs (hundreds of bytes) and fast verification but require a trusted setup ceremony and rest on elliptic-curve assumptions that are not post-quantum, while STARKs require no trusted setup and are post-quantum secure but produce much larger proofs and slower verification. The trusted setup ceremony — common to Groth16 and other SNARK families — is a real operational concern in adversarial environments and has motivated multi-party computation ceremonies with hundreds or thousands of participants; STARKs avoid the issue by construction. The honest production applications are blockchain rollups (the biggest by volume), privacy coins (Zcash and family), verifiable storage (Filecoin), credential systems (EUDI, Polygon ID), and a handful of experimental voting and zkML deployments; the honest hype includes most claims that ZK will replace passwords, fix surveillance comprehensively, or scale blockchains infinitely. The single most important practical thing to know about ZK is the prover-versus-verifier cost asymmetry: proving is many orders of magnitude more expensive than verifying, which is exactly why ZK pays back for rollups (amortize proving across thousands of transactions) and is questionable for single-statement applications. The technology is moving fast — custom proving hardware, recursive proofs, lookup arguments are all reducing prover costs steadily — and an application that is too expensive today may be feasible in two years. For working engineers evaluating ZK in 2026, treat it as a powerful tool whose costs are real, whose mathematical guarantees are solid, and whose appropriate use cases are narrower than the marketing suggests. Where it fits, it is remarkable; where it does not, simpler tools are dramatically cheaper, and choosing the right one is the working engineer’s actual job.

Sources

Comments