TEE-based AI agents are having a moment, but they inherit trust assumptions that make me uncomfortable—you're trusting Intel or AMD attestation, trusted hardware supply chains, and sidechannel-free implementations. ZKML offers a different path: prove the inference was computed correctly, mathematically, without trusting any hardware.
The problem is cost. And with the Ethereum Foundation prioritizing quantum-resistant cryptography for 2029, ZKML teams need to think about which proof systems will survive that transition.
Summary
ZKML generates zero-knowledge proofs that a machine learning inference was computed correctly. You prove "this model, given this input, produces this output" without revealing the model weights or the input. The core constraint: proving ML inference is 1000-10000x more expensive than just running the inference. Until that gap closes, ZKML is limited to high-value, low-frequency use cases.
What is ZKML?
Traditional ML inference is a trust-me operation. You send input to an API, you get output back, and you hope the provider actually ran the model they claimed on the data you provided.
ZKML makes inference verifiable:
Traditional ML Inference:
User → Input → [Black Box Model] → Output → User
Trust: "I guess this is GPT-4 output?"
ZKML Inference:
User → Input → [Model] → Output + ZK Proof → User
Verification: Proof confirms output came from claimed model
Proof statement:
"There exists model weights W and intermediate activations A
such that forward_pass(W, input) = output
and hash(W) = published_model_commitment"The proof is succinct—kilobytes regardless of model size—and verification is fast. The expensive part is generating the proof.
The Proving Cost Constraint
Here's the number that matters: ZKML proving costs are roughly 1000-10000x the cost of raw inference.
Cost Comparison (approximate):
GPT-4 scale model:
- Raw inference: ~$0.01 per 1K tokens
- ZKML proof: ~$10-100 per 1K tokens
- Ratio: 1000-10000x
Smaller model (1B parameters):
- Raw inference: ~$0.0001
- ZKML proof: ~$0.10-1.00
- Ratio: 1000-10000x
The ratio is roughly constant across model sizes.
Proving cost scales with inference compute.This isn't a temporary engineering problem—it's fundamental to how ZK proofs work. You're converting floating-point neural network operations into arithmetic circuits, then proving those circuits. Every matrix multiplication becomes millions of constraint satisfactions.
Impact
High-value, low-frequency use cases work today. Proving that a credit scoring model made a fair decision? Worth $10-100 if it prevents litigation. Proving a trading bot followed its stated strategy? Worth it for institutional compliance.
AI agents with onchain autonomy become possible. An agent that can prove "I evaluated these options using this model and chose this action" can operate without human approval loops. The proof is the accountability.
But real-time applications are out of reach. Chatbots, recommendation engines, anything user-facing with latency requirements—ZKML can't touch these at current costs.
The quantum question looms. Most ZKML implementations use SNARKs with trusted setups or STARKs with hash-based assumptions. The EF's 2029 quantum deadline means teams should be thinking about which proof systems are post-quantum safe.
Failure Modes
Floating-Point Precision Attacks: ML models use floating-point arithmetic. ZK circuits use finite field arithmetic. The conversion introduces precision differences. A malicious prover might find inputs where the circuit-version of the model produces different outputs than the actual model.
Model Extraction via Proofs: Proofs are zero-knowledge about the model weights, but they reveal information about the model's behavior. Enough proofs on diverse inputs might let an attacker reconstruct significant portions of the model.
Circuit Bugs in Operator Implementations: Every ML operator—attention, convolution, normalization—needs a circuit implementation. A bug in any operator is a soundness bug in every proof that uses it. The attack surface is huge.
Proof System Assumptions: SNARKs with trusted setups require trusting the setup ceremony. STARKs avoid this but have larger proofs. Groth16 is efficient but the setup is single-use. Each choice has tradeoffs that aren't always made explicit.
What I'd Change
Start with verifiable aggregation, not inference. Proving that 1000 model outputs were aggregated correctly is much cheaper than proving each individual inference. Build use cases around aggregation first—voting systems, ensemble decisions, federated learning coordination.
Build quantum-safe from the start. New ZKML projects should use STARKs or other hash-based systems that don't depend on discrete log hardness. Retrofitting post-quantum security is harder than building it in.
Standardize operator circuits. The ZKML ecosystem has multiple teams implementing the same operators. Audit costs are duplicated. Build a shared, heavily-audited library of operator circuits that everyone uses.
Publish precision bounds explicitly. Every ZKML system should document exactly how floating-point to field arithmetic conversion works and what precision is lost. Make it easy for auditors to check whether the circuit model matches the inference model.
Lessons
-
Proving cost is the binding constraint. Everything else—model size support, proof size, verification time—is secondary. Until proving costs drop 100x, ZKML is a niche tool.
-
High-value, low-frequency is the beachhead. Don't try to compete with raw inference on latency-sensitive use cases. Find applications where verification is worth 1000x the compute cost.
-
AI agents are the killer app. Autonomous onchain agents need accountability mechanisms. ZKML proofs are that mechanism—"here's cryptographic evidence of what I computed."
-
The quantum clock affects proof systems. SNARK assumptions aren't all post-quantum safe. Teams building ZKML infrastructure today need to think about 2029.
-
Circuit implementations are the new smart contracts. Every ZKML operator circuit is security-critical code. The audit and formal verification practices from smart contracts need to migrate to circuit development.
ZKML isn't ready for mainstream applications yet. But if you're building AI agents that need provable behavior—compliance bots, autonomous treasuries, verifiable oracles—the infrastructure is maturing fast. Start prototyping now.