The question zkML answers is one that ordinary infrastructure cannot: how does a party who cannot see your computation know that you performed the one you claimed? Signatures prove who sent a result. Attestation proves what hardware ran. Neither proves that the arithmetic was the arithmetic promised.
A zero-knowledge proof does, and it does so without revealing the inputs. That combination is why the idea keeps attracting attention, and why the gap between what it promises and what it currently delivers is worth being precise about.
What exactly is being proved?
Three separate claims travel under the same word, and conflating them is the most common error in the space.
| Claim | What it establishes | State of the art |
|---|---|---|
| Correct execution | This model, on this input, produced this output | Achievable for small models; the ordinary case |
| Input privacy | The verifier learns the output without seeing the input | Achievable, and usually free once you have the proof |
| Model privacy | The verifier learns the output without seeing the weights | Possible, but the commitment scheme and key management dominate the design |
Most real deployments want the first and second. The third is what people imagine when they hear the term, and it is the one that changes the architecture rather than just the cost.
Why is prover cost the constraint?
Because the asymmetry runs the other way from intuition. Verifying a proof takes under a millisecond in modern schemes, and proofs are kilobytes. Producing the proof is where the work is, and it scales with the size of the computation being proved.
That is why progress in this field is reported as prover time rather than as accuracy or capability. The work this desk has covered over the past year is all pointed at the same number: proving costs fell 40% and changed which systems were shortlisted; a SHA-256 circuit was folded in 91 milliseconds; and a commitment scheme published this month reduced the evaluation phase to 167 milliseconds at a polynomial of size two to the twentieth, a 4.4 times speedup, with total prover time of 808 milliseconds.
Those numbers are for circuits, not for models, and the distance matters. A transformer forward pass is many orders of magnitude larger than a hash. Improvements of four times compound usefully over years; they do not close a gap of that size in one.
What makes a model hard to prove?
- Non-linearities. Multiplication and addition are cheap in a circuit. Softmax, exponentials and comparisons are not, and a naive encoding of an activation function can cost more than the matrix multiply it follows.
- Floating point. Circuits work over finite fields, so real-valued arithmetic has to be quantised and the quantisation becomes part of what is proved. The proved model is the quantised model, not the original.
- Size. Cost scales with the computation, and a frontier model's forward pass is not a computation anybody is proving today.
- Hashing inside the circuit. Committing to weights or inputs means hashing them, and a hash function chosen for CPU speed is often the single most expensive component once it is expressed as constraints.
The last of those has been one of the more productive lines of work: keeping the hash function out of the circuit, rather than making it cheaper inside, removes the cost instead of reducing it.
Where is it genuinely useful?
In settings where a small model makes a consequential decision and somebody has a right to know the decision was made as described.
- An eligibility or scoring decision where the applicant may verify the model was applied as published, without the operator disclosing it and without the applicant disclosing their data.
- An oracle that reports a derived value — a risk score, a classification — where consumers need assurance the stated pipeline produced it.
- Compliance checks where a party must demonstrate a rule was applied without revealing the data the rule was applied to.
- Provenance: proving that a published output came from a specific committed checkpoint rather than something else. Our reporting has found checkpoint provenance to be mostly unverified in practice, which is the gap this addresses.
What these share is that the model is small, the decision is high-stakes, and the alternative to a proof is trust in the operator. Where any of those three is absent, the cost is difficult to justify.
What are the alternatives, and when are they better?
| Approach | Trust required | Cost | Fails when |
|---|---|---|---|
| zkML proof | Mathematics and the circuit | High to produce, negligible to verify | The circuit does not encode the model you think |
| Trusted execution | The hardware vendor | Low | The enclave is broken, which has happened repeatedly |
| Reproduce the run | Access to model and input | Low, but reveals both | The parties cannot share the inputs |
| Attestation and logs | The operator | Negligible | The operator is the adversary |
Trusted execution is the honest competitor: it is far cheaper and it works, as long as the hardware holds and you are content to trust its vendor. zkML replaces a vendor with mathematics, and pays for the substitution in prover time.
Where the risk actually is
Not in the cryptography, which is well studied. In the circuit. A missing constraint does not cause a proof to fail — it causes a proof to succeed for a computation that should have been rejected, and there is no runtime error to observe.
This desk has argued before that circuit bugs are the new contract bugs, and the comparison holds in the specific way that matters: both are silent, both are found by review rather than by testing, and both produce a system that appears to work perfectly while accepting things it should not.
A proof is only as meaningful as the statement it proves. The question to ask of any zkML deployment is not whether the proof verifies — it will — but what exactly the circuit asserts, and whether that is the claim you needed.
What to expect next
Prover cost continues to fall, and the falls are real and measured rather than promised. Hardware proving has consolidated around a small number of designs, which is what usually precedes cost curves flattening into something predictable enough to build on.
What that buys is larger small models, not frontier ones. Anybody describing proofs about a frontier system as near-term is describing a research direction rather than a product, and the honest version of this field's pitch does not need the exaggeration — proving a small model in a high-stakes decision is already a thing nothing else can do.
Questions
- What is zkML?
- The application of zero-knowledge proofs to machine learning: producing a cryptographic proof that a specific model, run on a specific input, produced a specific output, which can be verified by someone who sees neither the model nor the input.
- Can you prove what a large language model did?
- Not at frontier scale, and not close to it. Proving cost scales with the size of the computation, and a large model's forward pass is orders of magnitude beyond what current systems prove. Realistic deployments involve small models making consequential decisions.
- What is the main cost in zkML?
- Producing the proof. Verification takes under a millisecond and proofs are kilobytes; the prover carries essentially all of the work, which is why progress in the field is measured in prover time rather than proof size.
- Why are non-linear functions expensive to prove?
- Circuits express computation as addition and multiplication over a finite field. Softmax, exponentials and comparisons have no cheap expression in those terms, so an activation function can cost more to encode than the matrix multiplication preceding it.
- Is zkML better than running the model in a secure enclave?
- It depends on whom you are willing to trust. An enclave is far cheaper and requires trusting the hardware vendor and the enclave's integrity, which has been broken repeatedly. zkML replaces that trust with mathematics and pays for it in prover time.
- What is the biggest risk in a zkML system?
- A bug in the circuit. A missing constraint does not make a proof fail — it makes a proof succeed for something that should have been rejected, silently. The cryptography is well studied; the encoding of the model into constraints is where the errors are.