Skip to main content

What is ZK (zero-knowledge)

What is ZK (zero-knowledge)

Zero-knowledge proofs (ZK proofs) are a cryptographic technique that allows one party (the prover) to convince another party (the verifier) that a statement is true — without revealing any information beyond the truth of the statement itself. In blockchain, ZK proofs are used for three major purposes: privacy (hiding transaction details while proving they are valid), scaling (compressing many transactions into a single proof that is verified on-chain), and verifiable computation (proving that an off-chain computation was performed correctly).

In short: ZK proofs let you prove something is true without showing how or why. In crypto, they enable private transactions, scalable rollups, and verifiable AI inference — all without requiring trust in the prover.

The core idea

The concept is counterintuitive: how can you prove you know something without revealing it? A classic analogy helps.

Imagine a cave with two paths (left and right) that meet at a locked door in the back. You claim to know the password to the door. To prove it without revealing the password, a verifier stands at the cave entrance, and you enter via a random path. The verifier then shouts which path they want you to exit from. If you know the password, you can always exit from the requested side — you walk through the door if needed. If you do not know the password, you can only exit from the side you entered. After many rounds, the verifier becomes convinced you know the password, yet never learns what the password is.

ZK proofs formalize this intuition mathematically. They satisfy three properties:

  • Completeness. If the statement is true and both parties follow the protocol, the verifier will be convinced.
  • Soundness. If the statement is false, no cheating prover can convince the verifier (except with negligible probability).
  • Zero-knowledge. The verifier learns nothing beyond the fact that the statement is true.

How ZK proofs work (simplified)

A ZK proof system involves these steps:

  1. Statement formulation. The claim to be proven is expressed as a mathematical statement — typically as a circuit (a series of arithmetic operations) or a set of polynomial equations.
  2. Witness. The prover has private information (the "witness") that makes the statement true. For example, the witness might be the inputs to a computation that produces a known output.
  3. Proof generation. The prover uses the witness and the statement to generate a proof — a compact mathematical object. This is computationally expensive for the prover.
  4. Proof verification. The verifier checks the proof against the statement. Verification is fast and does not require the witness. If the proof is valid, the verifier is convinced the statement is true without learning the witness.

The proof is typically much smaller than the witness, and verification is much cheaper than re-executing the computation. This asymmetry is what makes ZK proofs useful for blockchain scaling and verification.

zk-SNARKs and zk-STARKs

Two major families of ZK proof systems dominate the blockchain space:

zk-SNARKs

Succinct Non-interactive Arguments of Knowledge. SNARKs produce very small proofs (a few hundred bytes) that are cheap to verify. They are "non-interactive" — the prover generates the proof in one step without back-and-forth with the verifier. Most SNARK constructions require a trusted setup — a one-time ceremony that generates public parameters. If the setup is compromised, the soundness guarantee breaks. Modern SNARKs (such as PLONK and its variants) use a universal trusted setup that works for any circuit, reducing but not eliminating this concern.

zk-STARKs

Scalable Transparent Arguments of Knowledge. STARKs do not require a trusted setup — they are "transparent." They also offer post-quantum security (resistant to attacks by quantum computers). The trade-off is that STARK proofs are larger than SNARK proofs and verification is somewhat more expensive. STARKs are particularly suited for large computations because their prover time scales quasi-linearly with computation size.

Comparison

Property zk-SNARKs zk-STARKs
Proof size Small (hundreds of bytes) Larger (tens to hundreds of kilobytes)
Verification cost Low Moderate
Trusted setup Required (most constructions) Not required (transparent)
Post-quantum security No (most constructions) Yes
Prover cost Moderate Higher, but scales better for large circuits

In practice, many projects use SNARK-based systems for their small proof sizes and low verification costs, while STARKs are gaining adoption where transparency and post-quantum security are priorities.

ZK in blockchain: major applications

Privacy

ZK proofs enable private transactions on public blockchains. A user can prove their transaction is valid (correct balances, no double-spending) without revealing the sender, receiver, or amount. Privacy-focused protocols use this to create confidential transfers on otherwise transparent chains.

Scaling (zk-rollups)

ZK-rollups are Layer 2 scaling solutions that execute transactions off-chain, batch them, and generate a ZK proof that the entire batch was processed correctly. Only the proof and a summary of state changes are posted to the base layer (Layer 1). The L1 smart contract verifies the proof and accepts the state update. This compresses thousands of transactions into a single proof verification, dramatically increasing throughput while inheriting the security of the base layer. Major zk-rollup implementations include zkSync, StarkNet, Polygon zkEVM, Scroll, and Linea.

For more on Layer 2 scaling, see L2.

Verifiable computation and zkML

ZK proofs can verify that any computation was performed correctly. This extends to AI: zkML uses ZK proofs to verify that a machine learning model produced a specific output from a specific input, without revealing the model weights or the input data. A smart contract can verify the proof on-chain, creating a trustless guarantee that the AI inference was computed correctly.

zkML represents one of the most technically ambitious applications of ZK in crypto AI. It provides a mathematical (trustless) guarantee of correct inference but is currently limited to small models due to the computational cost of proof generation.

Why ZK matters for crypto AI

ZK proofs address two critical needs in decentralized AI:

  • Verifiable AI. When AI inference runs on untrusted third-party hardware, ZK proofs can guarantee the result is correct without re-running the computation. This is essential for on-chain applications where AI outputs trigger smart contract actions.
  • Privacy. ZK proofs enable AI computations where the model, the input, or both remain private. A user can get an AI-generated result without the compute provider seeing the query, and a model owner can prove their model was used without revealing the weights.

In the DecAIHub evaluation framework, ZK-based verification serves as an indicator of genuine on-chain AI integration — it creates a mathematically verifiable link between off-chain AI computation and on-chain state.

Where it appears in DecAIHub project cards

ZK-related features surface in several places:

  • AI component — values like "zkML inference," "ZK-verified computation," or "zero-knowledge proof of inference" indicate ZK-based AI verification.
  • Category — projects using ZK for AI may appear in AI/Inference or AI/Compute categories with ZK as the verification mechanism.
  • Evidence table — Tier-1 evidence for ZK includes deployed verifier contracts, published proof benchmarks, circuit implementations, and on-chain verification transactions.
  • On-chain artifacts — ZK verifier contracts on-chain are concrete evidence of real ZK integration, contributing to the Onchain necessity dimension.

What ZK does not prove

  • ZK proves a computation ran correctly — it does not prove the computation is useful, the model is good, or the data is accurate. Verified garbage is still garbage.
  • ZK does not prove that a token is necessary. ZK proofs work without a blockchain; the decision to put verification on-chain is an architectural choice.
  • ZK does not prove decentralization. A centralized provider can generate ZK proofs for its own computations.
  • ZK does not prove that the model is the one claimed unless the model commitment (a hash of the weights) is publicly anchored and the proof is bound to that commitment.
  • A project mentioning ZK in its whitepaper does not mean ZK is implemented. Look for deployed verifier contracts, proof benchmarks, and circuit code as evidence.

Do not confuse with

  • Privacy — privacy is the broader goal. ZK is one tool for achieving it. Other privacy mechanisms include TEE, MPC, and homomorphic encryption.
  • TEE (Trusted Execution Environment) — TEE provides hardware-based confidentiality. ZK provides mathematical proofs. Both can be used for verifiable AI, with different trust assumptions and performance trade-offs.
  • zkML — the specific application of ZK proofs to machine learning inference. ZK is the general cryptographic technique; zkML is the specialized use case.
  • Encryption — encryption hides data. ZK proofs prove statements about data without revealing it. They are different operations: encryption transforms data into an unreadable form, while ZK proofs generate mathematical evidence about data without exposing it.
  • Optimistic verification — assumes results are correct and uses fraud proofs only when challenged. ZK proactively proves correctness upfront. These are complementary approaches used in different L2 designs (optimistic rollups vs zk-rollups).

Frequently asked questions

What is the difference between zk-SNARKs and zk-STARKs?

Both are families of zero-knowledge proof systems, but they differ in key properties. zk-SNARKs produce smaller proofs and have lower verification costs but typically require a trusted setup — a one-time ceremony to generate system parameters. zk-STARKs do not require a trusted setup (they are transparent) and offer post-quantum security, but their proofs are larger and more expensive to verify. The choice depends on the application: SNARKs are preferred when proof size and verification cost are critical (e.g., on-chain verification), while STARKs are preferred when transparency and long-term security are priorities.

How are ZK proofs used for blockchain scaling?

ZK-rollups execute transactions off-chain in batches, then generate a single ZK proof that the entire batch was processed correctly. This proof is submitted to the Layer 1 blockchain along with a compressed summary of state changes. The L1 smart contract verifies the proof — which is much cheaper than re-executing all the transactions — and accepts the state update. This allows the L1 to process the effect of thousands of transactions by verifying one proof, dramatically increasing throughput.

What is the connection between ZK and AI?

ZK proofs can verify that an AI model inference was performed correctly without revealing the model or the input data. This application, called zkML, enables trustless AI verification on-chain: a smart contract can confirm that a specific model produced a specific output. Currently, zkML is practical only for small models due to the computational cost of converting model operations into ZK circuits and generating proofs. As proof systems improve, the range of verifiable AI models will expand.

Are ZK proofs computationally expensive?

Proof generation is expensive — significantly more so than the underlying computation. Generating a ZK proof for a computation can take ten to a thousand times longer than simply running the computation. However, proof verification is cheap and fast. This asymmetry is by design: the prover does the heavy work once, and any number of verifiers can check the result efficiently. For blockchain applications, this means the expensive proof generation happens off-chain while the cheap verification happens on-chain.

External references

See also

No comments to display

Back to top