ZKML: Zero-Knowledge Machine Learning — Verifiable Inference

ZKML: Zero-Knowledge Machine Learning — Verifiable Inference

Photo by lange x on Pexels

Quick Answer: ZKML proves that an ML inference was computed correctly without revealing the model weights, input, or output. In 2026, ZKML is production-ready for small-to-medium models (under 1B parameters) with proving times of 1-30 minutes per inference on GPU. The stack: EZKL (highest-level, TensorFlow/PyTorch → ZK circuit automatically) for rapid prototyping, Circom (manually optimized circuits) for production, Halo2/KZG for recursive proofs that aggregate multiple inferences. Critical applications: (1) Verifiable DeFi oracles — prove a price prediction model ran correctly without revealing the model; (2) Fair credit scoring — prove loan eligibility without revealing the model or applicant data; (3) Decentralized inference market — verifiable that an inference was computed correctly (Akash, Bittensor). Current limitations: proving a single Llama 3 8B inference takes ~2 hours on H100 (fastest known implementation). Breakthrough expected from: (1) lookup arguments for non-linearities (GELU, softmax), (2) GPU-optimized MSM (multi-scalar multiplication), (3) folding schemes (Nova, ProtoGalaxy) that reduce proving time by 10-100x.

What ZKML Proves

ZKML lets a prover convince a verifier of three key facts:

1. "This model was used"
   Proof: ZK-SNARK shows inference = H(weights, input)
   Verifier learns: output is correct for that model
   Verifier doesn't learn: model weights or input

2. "This output is correct for some public input"
   Proof: ZK-SNARK shows output = model(public_input)
   Verifier learns: output is correct for given input
   Model weights are hidden (private)

3. "This prediction is above/below a threshold"
   Proof: ZK-SNARK shows model(priv_input) > threshold
   Verifier learns: prediction > threshold
   Verifier doesn't learn: exact prediction or input

Use cases:
  - Oracle: "Price prediction for ETH is > $5000" (prove without revealing model)
  - Credit: "Applicant score > 700" (prove without revealing data or model)
  - DeFi: "Position is solvent" (prove without revealing full portfolio)

Photo by Markus Winkler on Pexels

Proving Performance

The Breakthrough: Folding Schemes

Folding schemes (Nova, ProtoGalaxy, HyperNova) reduce proving time by avoiding repeated circuit constructions:

Standard ZK proving for ML:
  Each inference = build circuit for ALL operations → prove → verify
  Cost: O(FLOPs) per inference (very expensive for large models)

Folding schemes:
  First inference: build circuit, prove, verify (still expensive)
  Each subsequent inference: FOLD the new step into an accumulator
  Cost: O(1) per inference after first (constant time!)

How folding works:
  1. Initial state S₀ → run inference #1 → state S₁
  2. Prove: "S₁ was correctly computed from S₀" → expensive
  3. Inference #2: fold proof into accumulator
  4. Prove: "S₂ = S₁ + fold(inference #2)" → CHEAP
  5. Final proof: accumulator proves ALL inferences were correct
  6. Verification: O(1) regardless of N inferences

Target for 2027: Fold Llama 3 8B, each additional inference < 1 minute
                  First inference still ~2 hours

Related Reads

• On-Chain AI Inference: ZK-Proofs, Trusted Execution, and Verifiable Machine Learning
• AI-Native L1s and L2s: Blockchains Built for AI Workloads
• Real-Time Machine Learning on Blockchain Data

ZKML Circuit Design: Balancing Expressiveness and Efficiency

Designing ZK circuits for machine learning requires a fundamental trade-off between expressiveness and efficiency. Arithmetic circuits—used in ZK-SNARKs like PLONK or Groth16—are limited to addition and multiplication gates, making them ill-suited for non-linear operations like ReLU, GELU, or softmax. To handle these, practitioners must either (1) approximate non-linearities with polynomials (e.g., replacing ReLU with a quadratic approximation), (2) use lookup arguments (e.g., Plookup, Caulk) to precompute and verify non-linear values, or (3) decompose operations into bitwise logic (e.g., using R1CS constraints for division). Each approach has costs: polynomial approximations introduce error, lookup arguments increase circuit size, and bitwise decomposition explodes gate counts. For example, a single GELU activation in a transformer model might require 10-20x more constraints than a linear layer, dominating proving time.

The choice of circuit design also impacts verifier costs. Publicly verifiable ZK proofs (e.g., for blockchains) must minimize on-chain verification gas, which scales with the number of constraints. Techniques like custom gates (e.g., Halo2’s lookup gates) or recursive proofs (e.g., aggregating multiple inferences into a single proof) can reduce verification costs by orders of magnitude. For instance, a CNN with 11M parameters might require 3M constraints for a single inference, but folding schemes can reduce the per-inference verification cost to near-constant time after the first proof. Practitioners must also consider the prover’s hardware constraints: circuits for large models (e.g., 8B parameters) may require terabytes of RAM to represent, making GPU acceleration (e.g., CUDA-optimized MSM) essential for practical proving times.

Hybrid ZKML-TEE Architectures: Trustless Verification with Practical Throughput

While ZKML offers trustless verification, its computational overhead makes it impractical for high-throughput applications like real-time fraud detection or large-scale recommendation systems. Hybrid architectures combining ZKML with Trusted Execution Environments (TEEs) can bridge this gap. In this model, TEEs (e.g., Intel SGX or AMD SEV) handle the bulk of inference computations, while ZKML is used selectively to verify critical steps or final outputs. For example, a DeFi oracle might use a TEE to run a price prediction model but generate a ZK proof for the final output (e.g., “ETH price > $5000”) to ensure verifiability without revealing the model. This reduces ZKML’s overhead to a single proof per inference batch, rather than proving every layer.

The hybrid approach also enables “verifiable confidentiality”: TEEs ensure data privacy during computation, while ZK proofs provide cryptographic guarantees of correctness. This is particularly valuable for regulated industries like healthcare or finance, where both privacy and auditability are required. For instance, a credit scoring system could use a TEE to process sensitive applicant data (e.g., transaction history) and generate a ZK proof that the score exceeds a threshold (e.g., “score > 700”) without exposing raw inputs or model weights. The trade-offs are nuanced: TEEs introduce hardware trust assumptions, but ZKML’s overhead is limited to the final proof. Key challenges include:

• Proof generation latency: Even with TEEs, generating a ZK proof for the final output may take seconds to minutes, limiting real-time use cases.
• Key management: TEEs require secure enclave attestation, which adds operational complexity.
• Side-channel risks: TEEs are vulnerable to physical attacks (e.g., power analysis), though ZKML can mitigate this by verifying outputs.

ZKML for Model Governance: Proving Compliance Without Disclosure

ZKML can enable verifiable model governance—proving that a model adheres to regulatory or ethical constraints without revealing its internals. This is critical for applications like algorithmic fairness, where organizations must demonstrate compliance with laws like the EU AI Act or GDPR. For example, a bank could use ZKML to prove that its loan approval model does not discriminate based on protected attributes (e.g., race, gender) while keeping the model weights private. The proof would verify that the model’s outputs satisfy fairness constraints (e.g., demographic parity) for a given input distribution, without exposing the model or sensitive data.

The technical challenge lies in expressing governance rules as ZK constraints. Common approaches include:

• Threshold proofs: Prove that a model’s output for a protected subgroup meets a fairness threshold (e.g., “approval rate for Group A > 80% of Group B’s rate”).
• Counterfactual fairness: Prove that the model’s output is invariant to changes in protected attributes (e.g., flipping the “gender” bit in the input does not change the output).
• Regulatory compliance: Prove that a model’s risk score adheres to Basel III or other financial regulations (e.g., “capital requirement < 10% of assets”).

These proofs are computationally intensive, as they often require simulating counterfactual inputs or evaluating the model on synthetic data. However, folding schemes can amortize costs: a bank might generate a single ZK proof for a batch of 1,000 loan applications, reducing the per-application overhead to seconds. For high-stakes use cases (e.g., healthcare diagnostics), ZKML can also prove that a model was trained on a specific dataset (e.g., “this model was fine-tuned on FDA-approved clinical trials”) without revealing the training data or weights. The key limitation is that ZKML can only prove properties that are expressible as arithmetic constraints—complex governance rules may require simplifying assumptions or approximations.

Key Takeaways

• ZKML enables verifiable ML inference without revealing model weights, input, or output, making it viable for small-to-medium models (<1B parameters) with proving times of 1-30 minutes per inference on GPU in 2026.
• Use EZKL for rapid prototyping (TensorFlow/PyTorch → ZK circuit automation) and Circom for production (manually optimized circuits), with Halo2/KZG for recursive proofs aggregating multiple inferences.
• Critical applications include verifiable DeFi oracles (prove price predictions without revealing models), fair credit scoring (prove eligibility without exposing data), and decentralized inference markets (e.g., Akash, Bittensor).
• Proving a single Llama 3 8B inference currently takes ~2 hours on H100; folding schemes (Nova, ProtoGalaxy) could reduce subsequent inference times to <1 minute by 2027, though the first inference remains expensive.
• Bottlenecks include MSM (GPU-optimized multi-scalar multiplication), non-linearities (GELU/softmax), and memory constraints (8B-parameter models require terabytes of RAM), with lookup arguments and folding schemes as key optimizations.
• TEEs (Intel TDX) are more practical today for high-throughput use cases (2-5% overhead vs ZKML’s 100-1000x), but ZKML is trustless—ideal for high-stakes applications like oracles or financial settlement.