Zero-knowledge cryptography: how ZK-proofs work in 5 minutes

Before debating throughput, sequencer centralization, or liquidity across L2 ecosystems, it helps to understand what that proof actually does — and why the cryptographic system underneath it is constrained by three properties that cannot simply be negotiated away.

Zero-knowledge proofs are not a recent blockchain invention. The foundational paper, The Knowledge Complexity of Interactive Proof-Systems, was published in 1985 by Shafi Goldwasser, Silvio Micali, and Charles Rackoff. Nearly four decades later, the same three criteria still govern practical ZKP systems: completeness, soundness, and zero-knowledge.

A proof can be fast, compact, and cheap to verify. It can be embedded in a rollup or used to establish personhood. But if it fails one of those three tests, the system has a fundamental problem.

This is not a metaphor. It is a binary.

The Mathematical Foundation: Completeness, Soundness, and Zero-Knowledge

Every zero-knowledge proof has two primary participants:

• The prover, who claims to know some secret information or to have performed a computation correctly.
• The verifier, who wants to check that claim without necessarily receiving the secret itself.

The secret information is usually called the witness. A witness might be a private key, a transaction history, a set of input values, or a piece of data that satisfies a particular mathematical condition.

The prover does not merely send the witness to the verifier. Instead, it constructs a proof that demonstrates the existence of a valid witness. The verifier checks the proof against the relevant public statement and public inputs. The witness remains hidden.

That description becomes useful only when the three formal properties are separated.

Completeness

Completeness means that an honest prover can convince an honest verifier when the statement is true.

If a user really knows the private key associated with an address, a correctly constructed proof should be accepted. If a rollup has computed a state transition correctly, the proof should pass the verifier contract. If a value really falls inside a permitted range, a valid range proof should be accepted.

This sounds obvious, but completeness is where real implementations encounter practical edge cases. The circuit or proving system must encode the intended computation correctly. Inputs need to be represented in the right format. Boundary conditions need to be handled. A proof system that rejects valid statements because of an implementation mistake is not useful, even if its underlying mathematics is elegant.

For a ZK-rollup, completeness is tied to the relationship between the off-chain execution environment and the on-chain verifier. The prover may process thousands of transactions away from Ethereum. The verifier does not repeat the entire computation. It checks a compact cryptographic object that is supposed to attest that the computation followed the rules.

If the circuit omits a constraint, the proof can be complete for the wrong statement. That distinction matters: the cryptography may work exactly as designed while the design proves less than the protocol claims.

Soundness

Soundness is the opposite guarantee. If the statement is false, a dishonest prover should not be able to convince an honest verifier, except with negligible probability.

This is the property that prevents a malicious sequencer from producing a validity proof for an invalid rollup state transition. It is what stops someone who does not know a private key from proving that they know it. It is what makes a range proof meaningful rather than decorative.

The phrase “except with negligible probability” is deliberate. Cryptographic soundness is not usually expressed as an absolute impossibility. It is expressed through a security bound associated with the system’s parameters and assumptions. In many modern constructions, the intended failure probability is so small that exploiting it is computationally infeasible.

That does not mean every deployment automatically inherits the same guarantee. Soundness depends on the proof system, the circuit, the cryptographic assumptions, the implementation, and — in some SNARK systems — the security of the setup ceremony. A bug in the statement being proved can be more dangerous than a weakness in the underlying primitive.

This is also why “the math is sound” is not a sufficient description of a production protocol. The relevant question is: sound for which statement, under which assumptions, and with which implementation?

Zero-knowledge

Zero-knowledge means that the verifier learns no additional information about the witness beyond what follows from the validity of the statement and the public inputs.

That last qualification is important. A proof does not hide information that the protocol intentionally makes public. If a transaction includes a public recipient address, a public commitment, or a publicly specified range, those values remain visible. Zero-knowledge protects the private witness, not every piece of context surrounding the proof.

A user might prove that they have enough balance to authorize an operation without revealing the exact balance. A company might prove that a financial figure falls within an approved range without disclosing the underlying number. A rollup might prove that a batch of transactions was executed according to its state-transition rules without publishing every intermediate computation.

The verifier learns that the statement is valid. Depending on the design, it may also see public inputs and transaction metadata. What it does not receive is the witness itself or the hidden computation details that the proof is designed to protect.

A zero-knowledge proof does not make every part of a transaction invisible. It hides the witness while exposing the statement the protocol has chosen to verify.

The three properties work together. Completeness makes honest claims verifiable. Soundness prevents false claims from passing. Zero-knowledge limits what the verifier learns while checking the claim. Remove any one of them and the resulting system may still be a proof system, but it is no longer the kind of proof users usually mean by “zero-knowledge.”

Interactive vs. Non-Interactive Protocols: From 1985 to Modern Rollups

The original zero-knowledge framework was interactive. The prover and verifier exchanged several messages. The verifier issued a challenge, often chosen randomly. The prover responded. The verifier could then issue another challenge, and the exchange continued for several rounds.

The logic is straightforward. A prover who genuinely knows the witness can answer the verifier’s challenges consistently. A dishonest prover who is trying to fake knowledge may prepare an answer to one challenge, but cannot reliably anticipate every random challenge in advance. Repeating the process drives the probability of successful deception down.

Interactive proofs are mathematically useful, but they are a poor fit for public blockchains. Ethereum cannot ask every validator to conduct a private multi-round conversation with every rollup sequencer for every batch. The communication overhead would be significant, latency would become part of verification, and the whole process would be difficult to coordinate in a permissionless environment.

Modern blockchain systems therefore rely heavily on non-interactive proofs. The prover produces a single proof object. The verifier checks it without sending a fresh challenge back.

The Fiat-Shamir transformation

The standard route from interaction to non-interaction is the Fiat-Shamir heuristic. Instead of receiving a random challenge from the verifier, the prover derives the challenge from a cryptographic hash of the protocol’s previous messages and relevant context.

The hash acts as a deterministic substitute for verifier randomness. Anyone who receives the proof can reconstruct the challenge and verify the responses. There is no need for a live conversation between the prover and verifier.

This transformation is one of the reasons modern proof systems can operate inside smart contracts. A rollup prover can generate a proof off-chain, publish the proof and required public inputs, and let an Ethereum contract perform the verification in one transaction.

The security interpretation is more nuanced than “the hash makes the proof secure.” Fiat-Shamir is generally analyzed in a model where the hash function behaves like a random oracle. That is a powerful and widely used abstraction, but it remains an assumption about how the primitive behaves. It is not identical to the original interactive security proof in every formal setting.

For most practical blockchain work, this distinction does not make non-interactive proofs unusable. It does mean that claims about formal guarantees should identify the model and assumptions behind them.

What changes in a rollup

A ZK-rollup separates execution from verification.

The rollup processes transactions off-chain and updates its own representation of state. A prover then generates a proof that the batch followed the protocol’s rules. Ethereum does not need to execute every transaction again. It checks the proof against the previous state commitment, the new state commitment, and other public inputs.

The proof does not say that the transactions were economically sensible. It says that the specified computation was performed correctly according to the constraints encoded by the system. Questions about data availability, censorship, bridge design, upgrade keys, and sequencer control sit beside the proof rather than inside it.

That separation is central to understanding what ZK technology can and cannot guarantee. A validity proof can establish computational correctness. It cannot independently prove that the protocol has no privileged administrator, that users can always withdraw, or that the data needed to reconstruct state is available.

SNARKs vs. STARKs: Trusted Setups and Quantum Resistance

The two families most often discussed in blockchain are zk-SNARKs and zk-STARKs. Both can provide completeness, soundness, and zero-knowledge. Their tradeoffs are different enough to shape an entire protocol’s architecture.

The table is a map, not a universal law. “SNARK” and “STARK” describe broad families, and specific systems can make different engineering choices. A serious comparison has to look at the actual proving system, not just the acronym.

SNARKs and the trusted setup question

Many widely used SNARK constructions require a trusted setup. Participants generate a Common Reference String, or CRS, containing public parameters used by the prover and verifier. During the ceremony, participants contribute secret randomness.

The concern is usually described as “toxic waste.” If the secret information associated with the setup were retained and later misused, an attacker might be able to generate convincing proofs for false statements. The security model therefore depends on the ceremony being performed correctly and on at least one participant destroying their secret contribution.

Multi-party computation ceremonies are designed to reduce this trust assumption. A participant does not need to trust every other participant. The usual requirement is that one participant acted honestly and securely erased their contribution. The larger and more transparent the ceremony, the more credible that assumption may become, but it does not disappear as a category of risk.

The setup question also has to be separated from the circuit question. A perfectly executed ceremony cannot fix an incorrectly designed circuit. Conversely, a correct circuit can still be paired with a setup process whose assumptions users cannot verify.

SNARKs offer a powerful benefit in exchange: compact proofs and efficient verification. Small proof objects are valuable on Ethereum because data posted to the network and computation performed by contracts both have costs. In many applications, the ability to verify a compact proof is worth the complexity of setup management.

STARKs and transparent proving

STARKs avoid the traditional trusted setup ceremony. Their security relies primarily on hash functions and publicly verifiable randomness generated within the protocol. There is no secret parameter whose destruction is required to prevent proof forgery.

That transparency changes the risk profile. It does not eliminate all risk: the hash function, the algebraic protocol, the implementation, and the statement being proved still matter. But the system does not ask users to accept the same ceremony-based assumption as a typical pairing-based SNARK.

The tradeoff is proof size. A STARK proof can be orders of magnitude larger than a compact SNARK proof. In an Ethereum environment, that affects calldata and verification costs. Large proof data consumes block space and competes with other activity for scarce network resources.

STARK systems can respond with recursion and aggregation. One proof can attest to the validity of other proofs, allowing many computations to be compressed into a smaller number of verification steps. The engineering advantage is substantial, but it comes with more complicated prover infrastructure and a different performance profile.

Quantum resistance is not a marketing synonym

SNARKs built on elliptic-curve assumptions are vulnerable to a sufficiently capable quantum computer running Shor’s algorithm. That does not mean an ordinary attacker can break them today, nor does it make every SNARK deployment immediately unsafe. It means the long-term security assumption is different from that of hash-based systems.

STARKs are often described as quantum-resistant because their core security does not depend on the same discrete-logarithm problem. Even here, the phrase should be used carefully. Quantum resistance is a property of the complete construction and its parameters, not a decorative label attached to every system that uses the word STARK.

For a protocol designed to secure assets or records over a long time horizon, the choice is architectural. A project may prioritize compact proofs and lower verification overhead now, or transparent setup and a different long-term cryptographic posture. Neither choice is automatically correct for every workload.

The choice between SNARKs and STARKs is not aesthetic. It is a tradeoff between setup assumptions, proof size, gas costs, prover complexity, and long-term cryptographic risk.

Real-World Implementation: From ING Range Proofs to World ID

Zero-knowledge proofs became prominent in blockchain, but their underlying use cases are broader. The common pattern is simple: a verifier needs to establish that a hidden value satisfies a condition, while the prover has a reason not to reveal the value itself.

ING and range proofs

ING Bank demonstrated a zero-knowledge range-proof application for financial information. The idea was to let an applicant prove that income fell within an acceptable range without disclosing the exact amount.

A lender may need to know whether an applicant is above a threshold or inside a permitted band. It may not need the precise salary, the full account history, or every other financial detail that would normally be bundled into a conventional document-based process.

A range proof encodes the condition mathematically. The prover commits to a hidden value and demonstrates that the value lies between two public bounds. The verifier checks the proof without learning the value itself.

This is a more demanding use of zero knowledge than simply encrypting a document. Encryption controls who can read the underlying data. A zero-knowledge proof is designed to let the verifier check a particular claim without receiving the underlying data at all.

The difference matters in financial systems. If the verifier only needs to know that a value meets a requirement, collecting the exact value creates additional storage, access-control, and breach risks. The proof narrows the information exchanged to the decision the verifier actually needs to make.

World ID and proofs of personhood

World ID applies a related idea to personhood. The system is designed to let a participant demonstrate eligibility as a unique human without presenting a conventional identity document to every application. The Orb is part of the enrollment and verification process used to establish that a participant corresponds to a real, distinct person.

The zero-knowledge layer is intended to let an application verify an eligibility claim without receiving the user’s biometric data as part of each individual action. That does not mean the entire identity system can be summarized as “biometrics disappear.” The upstream collection process, device security, data handling, enrollment model, and deletion or custody policies are separate parts of the system and require separate scrutiny.

There is another important qualification: the system does not guarantee universal unlinkability in every context.

A nullifier is not the proof itself. It is a value used alongside the proof to prevent a credential from being reused in a forbidden way. In a typical design, the nullifier is derived in relation to a particular scope — for example, an application, group, action, or other protocol context. The same person may therefore produce a different nullifier in a different scope, while repeated use within the same defined scope can be detected.

The practical purpose is anti-reuse, not universal anonymity. If an application wants to stop the same verified human from claiming a reward twice, it can use a scope-specific nullifier as part of that rule. But the privacy properties depend on how scopes are defined and what information applications, relayers, or other participants can observe. A nullifier may be unlinkable across separate scopes under the intended design, while remaining deliberately linkable within the same scope.

So the accurate statement is narrower:

A user can generate a zero-knowledge proof of eligibility or personhood, accompanied by a scope-limited nullifier that helps prevent repeated use in that application or action context. The verifier need not receive the user’s biometric data or underlying identity for that check, but the system should not be described as guaranteeing universal unlinkability between all sessions.

That distinction is not pedantic. It is the difference between a privacy claim that describes a protocol and one that describes an idealized user experience.

The architectural concern is therefore split in two. The ZKP can protect the witness used in an application-level verification. The enrollment and biometric pipeline determine how the credential was created and what data was handled before the proof existed. Cryptography solves one part of the problem. Hardware, governance, data custody, and scope design solve others.

ZK-rollups

ZK-rollups remain the largest commercial application of the technology in crypto. Their objective is to move transaction execution away from Ethereum while retaining a validity guarantee anchored to Ethereum.

The rollup executes a batch, computes a new state commitment, and generates a proof that the transition from the old state to the new state followed the protocol’s rules. The Ethereum verifier contract checks the proof. If it accepts, the batch is considered valid under the rollup’s verification logic.

The proof does not contain every transaction computation in a readable form. It is a compressed certificate that the computation satisfies the circuit or constraint system. That is why the distinction between the protocol’s intended rules and the circuit’s actual rules is so important. If an operation is not constrained, the proof cannot enforce it.

Different rollups make different choices. Some use SNARK-oriented systems, some use STARKs, and others use hybrid or evolving architectures. zkSync Era, StarkNet, Polygon zkEVM, Scroll, and Linea each have their own proving stacks and operational assumptions. The shared pattern is off-chain computation combined with on-chain verification, but the details determine costs, upgrade risks, proof latency, and decentralization constraints.

The Economics of Privacy: Gas Costs and Scalability on Ethereum

Proof verification is only one part of ZK economics, but it is a visible one. Every proof posted to Ethereum consumes resources. The rollup spreads those costs across the transactions included in the batch.

Suppose a SNARK verification costs approximately 500,000 gas. If a batch contains 1,000 transactions, the proof component alone works out to roughly 500 gas per transaction before accounting for calldata, state differences, deposits, withdrawals, and other overhead. If the same fixed verification cost is spread across 10,000 transactions, the proof component falls to roughly 50 gas per transaction.

The arithmetic explains why batching matters. A fixed proof cost becomes more attractive as more valid computation is compressed behind it. But the rollup cannot increase batch size without limit. Prover time, data availability, block constraints, withdrawal latency, and operational risk all enter the equation.

The cost is also not just “verification gas.” A rollup has to publish enough data for users or independent operators to reconstruct relevant state and verify what happened. Compression can reduce the amount of data, but data availability remains a core part of the security model. A proof can demonstrate that a hidden computation was correct; it does not automatically make unavailable transaction data recoverable.

STARK-based systems face a different balance. Their proofs can be much larger, increasing the cost of publishing proof data and processing it on-chain. Recursive proofs and aggregation can reduce the number of separate verification operations, but recursion adds engineering complexity and prover workload.

This creates several competing optimization targets:

• Proof generation time: A proof that takes too long to produce can increase withdrawal delays and make the system difficult to operate at peak demand.
• Verification cost: The verifier must fit within Ethereum’s gas and block constraints.
• Data publication: State differences and transaction data still need an availability strategy.
• Batch size: Larger batches amortize fixed costs but require more computation and may introduce latency.
• Hardware requirements: If proving requires specialized infrastructure, the prover set may become more centralized.
• Upgrade and governance risk: A transparent proof system can still be controlled by privileged keys or upgrade mechanisms outside the circuit.

The cheapest proof is not automatically the best proof. A protocol that minimizes gas by accepting a fragile setup, opaque upgrade path, or highly concentrated proving market may be shifting costs rather than eliminating them.

There is a similar issue with privacy applications. A proof may reduce the amount of personal information a verifier receives, but generating and verifying it still has a computational cost. On-chain privacy systems must account for proof size, circuit complexity, witness generation, and the amount of public context that remains visible. In some cases, the privacy guarantee is worth the overhead. In others, a simpler commitment or signature scheme may be sufficient.

Ethereum’s economics therefore shape ZK design at every layer. A proof system is not evaluated in a vacuum. Its cryptographic properties interact with calldata pricing, block capacity, prover hardware, sequencing architecture, and the value users place on confidentiality.

What the Proof Does — and What It Does Not

The most useful way to read a ZKP architecture is to ask what statement is being proved.

A proof may establish that:

1. A prover knows a secret associated with a public commitment.

2. A hidden value lies within a permitted range.

3. A set of transactions produces a particular new state.

4. A credential belongs to a valid group without revealing the credential itself.

5. A participant has not already used a credential within a defined scope.

Those claims are precise. They should not be expanded into broader promises without examining the surrounding system.

A ZK-rollup proof does not by itself guarantee instant finality, censorship resistance, data availability, or decentralized sequencing. A proof-of-personhood system does not by itself guarantee that its enrollment hardware, biometric processing, governance, and application integrations are risk-free. A nullifier does not mean universal unlinkability; it is an anti-reuse mechanism whose privacy behavior depends on scope.

This is where many product explanations become misleading. “The data is private” can mean that a witness is hidden from a verifier. It does not necessarily mean that no participant in the wider pipeline sees metadata, that sessions cannot be linked in a defined application context, or that public inputs vanish.

The cryptographic claim should remain the size of the cryptographic claim.

Verdict

Zero-knowledge proofs are not one technology and not a synonym for total privacy. They are a class of protocols built around three formal properties: completeness, soundness, and zero-knowledge. Those properties remain the right starting point whether the application is a range proof, a proof of personhood, or a validity proof for a rollup.

SNARKs and STARKs then introduce the engineering tradeoffs. Compact SNARKs can make on-chain verification efficient, but some constructions require trusted setup assumptions and rely on cryptography vulnerable to future quantum advances. STARKs offer transparent setup and a different long-term security profile, but their larger proofs and heavier proving workloads affect Ethereum economics.

The same precision is necessary when discussing privacy. World ID-style systems can use zero-knowledge proofs to limit what an application learns, while scope-specific nullifiers help prevent repeated use of a credential in a defined context. That is a meaningful privacy design. It is not a promise that every action is unlinkable everywhere.

The technology works because the claims are narrow enough to verify mathematically. The deployment succeeds or fails according to everything built around those claims: the circuit, the setup, the prover infrastructure, the data-availability model, the hardware, and the disclosure of assumptions.

Evaluate the proof system. Evaluate the statement it proves. Evaluate the scope of its nullifiers, the cost of verification, and the parts of the architecture that sit outside the proof. If a project hides any of those details, the risk is not necessarily in zero-knowledge cryptography itself. It is in the distance between what the proof establishes and what the marketing says it establishes.