Skip to main content

What is zkML

What is zkML

zkML (Zero-Knowledge Machine Learning) is a technique that uses zero-knowledge proofs to verify that a machine learning model ran its inference correctly — without revealing the model weights, the input data, or both. It provides a cryptographic guarantee: "this output was produced by this model on this input," and anyone can verify the proof without seeing the private information.

In short: zkML lets you prove an AI model ran correctly without exposing the model or the data. It is one of the approaches to verifiable AI that provides a mathematical (trustless) guarantee of correct inference, and one of the most technically challenging.

Analogy for beginners

Imagine a sealed exam. A student walks into a room, takes a test, and hands the sealed answer sheet to a proctor. The proctor can verify, through a tamper-proof seal, that the student answered every question using the approved textbook and followed all exam rules — without ever seeing the student's notes, study materials, or thought process. The proctor knows the result is legitimate, but learns nothing about how the student prepared. zkML works the same way: it proves the AI "took the test correctly" without revealing the model (the study materials) or the input data (the student's notes).

The problem it solves

In decentralized AI, trust is a core issue. When inference runs on a remote node, how does the requester know the correct model was actually used? The provider could run a cheaper model, return a cached result, or skip computation steps entirely. In centralized AI, users trust the provider by reputation. In decentralized systems, reputation alone is not sufficient — cryptographic verification fills this gap.

This problem becomes especially important when AI outputs drive high-stakes decisions. If an on-chain protocol relies on a model's output to trigger a smart contract action — say, adjusting a risk parameter or approving a transaction — there must be a way to guarantee the output is authentic. Without verification, the system is only as trustworthy as its least honest node.

How it works (simplified)

A zkML pipeline follows these general steps:

  1. Model conversion. The ML model (typically a neural network) is converted into an arithmetic circuit — a mathematical representation that ZK proof systems can work with. This step translates operations like matrix multiplications, activation functions, and normalization layers into circuit constraints.
  2. Model execution. The provider runs the ML model on the input data and produces an output (e.g., a classification, a generated text, a prediction).
  3. Proof generation. Alongside the output, the provider generates a zero-knowledge proof — a compact mathematical object that encodes the claim "this output was produced by running this specific model on this specific input." This is the computationally expensive step: the prover must demonstrate that every operation in the circuit was executed correctly.
  4. Proof verification. Anyone (the requester, a smart contract, a third party) can verify the proof. Verification is fast and cheap compared to re-running the model. If the proof is valid, the output is guaranteed to be correct.

The key property: the verifier learns nothing about the model weights or the input data beyond what the proof reveals. Privacy and verifiability coexist.

What makes proof generation expensive

The cost comes from translating ML operations into ZK circuits. Each multiplication or addition in a neural network becomes a constraint, and the prover must generate a cryptographic witness satisfying all constraints simultaneously. For a model with millions of parameters, this means millions of constraints. Current frameworks use different proof systems (SNARKs, STARKs, and hybrid approaches) with varying trade-offs between proof size, verification time, and prover cost.

Why it matters for DecAIHub

DecAIHub evaluates whether crypto AI projects have real, verifiable AI. zkML represents one approach to making AI claims cryptographically provable — a project that uses zkML can prove its model actually ran, not just claim it did. In the DecAI Fit framework, zkML-based verification contributes to the Onchain necessity dimension, demonstrating a meaningful connection between the AI pipeline and the blockchain. Projects implementing zkML appear across categories like AI/Inference and AI/Compute.

From the DecAIHub verification perspective, zkML projects present a distinctive evidence profile. When a project genuinely implements zkML, there are strong Tier-1 artifacts to evaluate: proof circuits, verification contracts on-chain, benchmark data for proving times, and documented model-to-circuit conversion pipelines. This makes zkML claims relatively easy to verify compared to vague "AI" claims — either the ZK proof works or it does not.

Connection to verifiable AI

zkML is one of several approaches to verifiable inference. The main alternatives are:

Approach How it works Trust model Trade-off
zkML Cryptographic proof that inference ran correctly Mathematical guarantee (trustless) Highest computational cost; mathematical (trustless) guarantee
TEE (Trusted Execution Environment) Inference runs in hardware-isolated enclaves that attest correctness Trust in hardware manufacturer Lower cost; depends on hardware security assumptions
Consensus / multi-provider Multiple independent providers run the same inference; results are compared Trust in honest majority Redundant computation; weaker guarantee against collusion
Optimistic verification Results are assumed correct unless challenged within a dispute period Trust in economic incentives Low cost; relies on active monitoring and rational actors

zkML offers a mathematical (trustless) guarantee — correctness is verified cryptographically, without trust in hardware, an honest majority, or economic incentives. However, it comes at the highest computational cost. In practice, many projects combine approaches: using optimistic verification for routine operations and falling back to zkML proofs only when results are challenged.

Current limitations

zkML is early-stage technology with significant practical constraints:

  • Computational cost. Generating a ZK proof for model inference is orders of magnitude more expensive than the inference itself. For large models, proof generation can take minutes to hours. This makes real-time applications impractical for anything beyond small models.
  • Model size limits. Current zkML frameworks work with relatively small models (thousands to low millions of parameters). Running zkML on a full LLM with billions of parameters is not yet practical. Research is active in techniques like model quantization, proof aggregation, and recursive proofs to push these limits higher.
  • Framework maturity. zkML tooling (e.g., EZKL, Modulus, Giza, Risc Zero for ML) is under active development. APIs, documentation, and developer experience are evolving rapidly, and breaking changes are common.
  • Limited production deployments. Few projects have zkML running in production at scale. Most implementations are research prototypes or demonstrations on small models.
  • Accuracy trade-offs. Converting floating-point ML operations to fixed-point arithmetic (required for ZK circuits) can introduce small numerical differences. These differences are usually negligible for classification tasks but may matter for precision-sensitive applications.

These limitations define the current frontier. The technology is advancing rapidly, and constraints that exist today may be significantly reduced within a few years.

Practical state of zkML today

Despite the limitations, zkML has moved beyond pure theory. The current state includes:

  • Small model proofs are functional. Models with up to low millions of parameters (image classifiers, small language models) can be proven. Proof generation takes seconds to minutes depending on model size.
  • On-chain verification works. ZK verifier contracts that check ML inference proofs have been deployed on Ethereum and other chains.
  • Tooling is improving. Frameworks like EZKL allow developers to convert ONNX models to ZK circuits with relatively few lines of code.
  • Hybrid approaches are emerging. Some projects prove only the most critical inference steps, or generate proofs asynchronously for later verification.

What zkML does not prove

  • Even with a valid ZK proof, the underlying model could be bad, biased, or irrelevant. zkML proves the model ran correctly — it does not prove the model is good.
  • zkML proves computation integrity, not data quality. If the input data is garbage, the output is verified garbage.
  • zkML does not prove a token is necessary. A project can implement zkML without needing a blockchain or a token for the verification to work.
  • zkML does not prove decentralization. A single centralized provider can generate ZK proofs for its own inference. The decentralization comes from the system architecture, not from zkML itself.
  • zkML does not prove that the model is the one claimed unless the model commitment (a hash of the weights) is anchored to a trusted reference. Without this binding, the prover could use any model.

Do not confuse with

  • Inference — the process of running a model. zkML adds a verification layer on top of inference; it does not replace it.
  • ZK (zero-knowledge proofs) in general — ZK is used across crypto for privacy, scaling, and identity. zkML is the specific application of ZK to ML inference.
  • Inference as an AI component — describes how inference appears in DecAIHub project cards. zkML is one mechanism that makes inference verifiable.
  • Model encryption — encrypting a model protects it from being read, but does not prove it ran correctly. zkML provides a proof of correct execution, which is a fundamentally different guarantee.
  • Federated learning — a technique for training models across distributed data sources without sharing raw data. It solves a different problem (privacy during training, not verification during inference).

Frequently asked questions

How does zkML work?

zkML converts a machine learning model into a mathematical circuit, runs the model to produce an output, and generates a cryptographic proof that the circuit was executed correctly. The proof is compact and can be verified quickly by anyone — including a smart contract — without re-running the model or seeing the model weights or input data. The technical challenge is that each ML operation must be represented as a circuit constraint, making proof generation computationally expensive for larger models.

Is zkML practical today?

For small to medium models (up to low millions of parameters), yes — proof generation works and on-chain verification is functional. For large models like modern LLMs with billions of parameters, zkML is not yet practical due to the enormous computational cost of proof generation. The technology is advancing rapidly: frameworks are improving, proof systems are becoming more efficient, and hybrid approaches (proving only critical steps) are extending the practical range. For DecAIHub evaluation purposes, a project that implements zkML on a small model has a verifiable AI component, even if the same approach cannot yet scale to the largest models.

Why would a crypto project use zkML?

The primary motivation is trustless verification. In a decentralized system, no single party should be blindly trusted. If an AI model's output triggers on-chain actions (risk scoring, transaction approval, reward distribution), the users and the protocol need a guarantee that the model actually ran as claimed. zkML provides this guarantee without requiring trust in the compute provider. Secondary motivations include privacy (proving a model ran without exposing proprietary weights) and composability (other smart contracts can verify AI outputs on-chain and build on them). In the DecAI Fit framework, zkML-based verification strengthens both the AI reality and the Onchain necessity dimensions.

Is zkML the only way to verify AI in crypto?

No. Alternatives include TEEs (trust in hardware), consensus-based verification (trust in honest majority), and optimistic verification (trust in economic incentives). Each has different trust assumptions, costs, and limits. Many projects combine approaches. DecAIHub records the verification mechanism in the project card so readers can assess the trust model for themselves.

External references

See also

No comments to display

Back to top