Menu
← FIELD NOTESZKML 2026.07.22 · 13 min

Your zkML proof is slow because of the part that has nothing to do with the model.

On real networks the dominant zkML prover cost is not the matmuls or the activations. It is the consistency check binding the proof to the committed weights — an overhead that grows past 90% of prover time and that the single benchmark number hides.

A team has a zkML proof that is too slow, and they know exactly why. The model is a convolutional network, and the prover is dominated by the convolutions — those big dense matrix multiplies are the expensive part of any neural network, so of course they are the expensive part of proving one. So the team reaches for the obvious fix: a better circuit for the model. FFT-accelerated convolutions. Lookup tables for the ReLUs and the softmax instead of arithmetizing them. A layout optimizer that packs the gadgets into the proving system’s columns. Every one of those is a real, published technique, and every one attacks the matrix multiplies and the non-linearities — the operations the model actually performs. The team profiles the result and the proving time has barely moved.

It barely moved because most of the prover’s time was never going into the model at all. It was going into a step that is not in the architecture diagram, not in the model definition, and not in the mental model of “a neural network is matmuls and activations”: the consistency check that proves the witness the prover used really is the committed model on the committed input. Optimize the circuit as hard as you like; on a large network you can still spend most of your proving time proving you used the model you said you used.

This post is about that hidden cost term — why it exists, why the single proof-time number every zkML benchmark reports buries it, how large it gets, and why it grows to dominate precisely on the big models circuit-optimization papers target.

The proof you want is not “the model ran” — it is “the committed model ran”

Start with why this check has to exist, because if you skip that you will keep treating it as overhead to delete rather than the load-bearing part of the statement.

The whole point of zkML in the verifiable-inference setting is that the model owner does not reveal the weights — trade secret, or private, or both — but a verifier still wants assurance that a stated output is genuine. So the weights go into the proof as a private witness; the input and output are public. The trouble is immediate, and Artemis states it bluntly: Artemis: Efficient Commit-and-Prove SNARKs for zkML (arXiv 2409.12055) observes that “since the model is hidden, the verifier does not know which model the prover actually used. As a result, a ZKP of correct inference is, by itself, not generally useful in practice, as it does not ensure the computation was performed using the intended model.” A bare proof that some network mapped this input to this output is worthless: a malicious prover picks whatever weights produce the answer they want and proves that.

The fix is a commitment. The owner publishes a commitment to the weights once, up front — a short binding fingerprint that can be independently audited — and every subsequent inference proof must show that the private witness it computed on is the same model the commitment fixed. Artemis puts it plainly: “it is crucial to bind the proof to a specific model… The commitment anchors the proof to a specific model that can be independently audited.” The field survey says the same when it writes down what the statement actually is — not “this output equals some model’s output” but, in the words of A Survey of Zero-Knowledge Proof Based Verifiable Machine Learning (arXiv 2502.18535), “this prediction equals the output of the committed model on the declared input.” The word committed does all the work. Strip it and the proof certifies nothing an attacker could not forge.

So the statement has two halves. Half one: the model computation was performed correctly — the matmuls, the convolutions, the activations. Half two: the model used in half one is bit-for-bit the one the commitment fixed. Half one is what everyone optimizes; half two is the consistency check — where the time goes.

The single number on the benchmark hides the term that matters

Here is the structural reason this cost stays invisible: essentially every zkML system reports its performance as one folded number — proof time, proof size, verification time — for the whole inference. When you only see the total, you cannot see that a growing fraction of it is the binding check rather than the model. The number does not lie; it just does not decompose.

Walk the headline numbers from the systems papers and notice they are all single aggregates. zkLLM: Zero Knowledge Proofs for Large Language Models (arXiv 2404.16109) reports that “for LLMs boasting 13 billion parameters, our approach enables the generation of a correctness proof for the entire inference process in under 15 minutes,” with a proof “less than 200 kB” that verifies in “1-3 seconds.” One number for the entire inference. zkPyTorch: A Hierarchical Optimized Compiler for Zero-Knowledge Machine Learning reports proving “for the VGG-16 model in just 2.2 seconds per CIFAR-10 image using a single CPU core” and Llama-3 (8 billion parameters) at “150 seconds per token” while retaining “99.32% cosine similarity with the original floating-point model.” Per-image, per-token — single figures. ZKTorch: Compiling ML Inference to Zero-Knowledge Proofs via Parallel Proof Accumulation (arXiv 2507.07031) reports “at least a 3x reduction in the proof size compared to specialized protocols and up to a 6x speedup in proving time over a general-purpose ZKML framework.” Multipliers on the aggregate.

None of these is wrong, and none is hiding anything on purpose. But a single end-to-end number is a sum, and a sum tells you nothing about its terms. A team reading “2.2 seconds per image” has no way to know whether shaving the convolutions would help or whether the convolutions stopped being the problem a while ago. That is the gap our zkML library benchmark lives in too: same model, same input, one proof-time column per library, the binding check folded silently into each cell. The single number is the right thing to put in front of a customer. It is the wrong thing to optimize against, because it does not tell you which half you pay for.

The optimization effort goes everywhere except the binding check

Look at where the engineering goes, and the blind spot is structural rather than careless: the flagship zkML systems almost without exception optimize half one — the model computation — with real ingenuity, and treat half two as a fixed backend or someone else’s problem. The canonical statement of the matmul-and-activation framing is the original optimizing compiler. ZKML: An Optimizing System for ML Inference in Zero-Knowledge Proofs describes its two components as exactly that: “gadgets that perform basic operations for ML models, such as dot products, softmax, and pointwise non-linearities” plus “its circuit layouter, which optimizes the circuit layout for a given hardware target.” The model’s arithmetic, and a layout pass over it. Its reported wins are all in that territory: the optimizer improves performance “by up to 131%,” and the system constructs “proofs of ML models that are up to 5x larger than prior work… while achieving up to 5x faster verification and 22x smaller proofs.” Every one of those gains expresses the computation more cheaply.

Where does the commitment go in that paper? It is named, then folded into the proof system’s abstract guarantee. ZKML notes that “the knowledge soundness property intuitively means that the prover must know the input and the weights,” and then: “halo2 supports two underlying commitment schemes: KZG and IPA (inner-product argument).” The binding requirement is acknowledged and handed to an interchangeable backend, never accounted for as a cost line. The newer LLM-scale work makes the same move at the top of the stack. zkLLM locates its central challenge in “the persistent challenge of non-arithmetic operations in deep learning” and builds “tlookup, a parallelized lookup argument designed for non-arithmetic tensor operations” and “zkAttn, a specialized zero-knowledge proof crafted for the attention mechanism.” Its own statement of what an efficient deep-learning ZKP needs is two requirements — parallelization and “the adept handling of non-arithmetic operations” — and binding-to-committed-weights is neither. zkPyTorch accelerates convolutions with FFTs and the non-linearities — softmax, normalization — with lookup tables, and aims its remaining correctness machinery at quantization fidelity, reporting “99.32% cosine similarity with the original floating-point model” — not at proving the committed weights were used.

This is not a list of mistakes. Every one is a strong paper doing exactly what it set out to do, and FFT convolutions and lookup-based softmax are genuine advances on half one. The point is narrower and more uncomfortable: an entire research frontier has been sharpening the model-computation half of the statement, and the binding half has been treated as plumbing — a commitment scheme you select, not a cost you measure. Even the field’s bottleneck vocabulary reflects it. The 2026 survey, reviewing the whole area, lists “the main implementation bottlenecks, including limited circuit expressiveness, high proving cost, and deployment complexity.” Circuit expressiveness, proving cost, deployment — the consistency check is not on the standard list at all. It hides inside “high proving cost,” undifferentiated, exactly where the single-number benchmarks put it.

On real networks the hidden term is most of the bill

So the check is unmeasured and the optimization effort flows around it. Does that matter? Artemis decomposes the number, and its answer is stark — and it is the thesis of this post, stated by the source that measured it: recent zkML advances, Artemis writes, “have made significant improvements to the efficiency of proving ML computations, they have largely overlooked the costly consistency checks on committed model parameters and input data, which have become a dominant performance bottleneck.” Not a tax. The dominant bottleneck.

And the number is larger than “overhead” suggests. For prior approaches to commitment consistency on large models, “more than 90% of the prover’s time” goes, in Artemis’s words, on “these checks rather than on ML computations.” Read that against the systems papers and the dissonance is the whole story: zkPyTorch is shaving milliseconds off convolutions with FFTs, zkLLM is building a bespoke proof for attention — and on a large enough network, the convolutions and the attention together are the under-10% slice. Ninety percent of the prover is off doing the thing none of those optimizations touch.

The concrete blow-up factor makes it tangible. On VGG, Artemis reports that existing commitment-consistency machinery imposes an 11.5× overhead on the proof — the binding check costs more than eleven times what it nominally should — which Artemis’s own commit-and-prove construction cuts to roughly 1.1×, “for the VGG model, we reduce the overhead associated with commitment checks from 11.5x to 1.1x.” Sit with the 11.5× in light of the opening scene. Even FFT-accelerating the convolutions to free leaves it untouched, because that overhead was never in the convolutions. The optimization the team can see is attacking the part that is not the problem.

And the cruelty is in which models. The check dominates “for larger models” — the consistency term grows with the model, faster than the share of attention you were paying it. The circuit-optimization papers target large models too; that is where the matmuls hurt and where the cleverness pays. So the binding check crosses into dominance on exactly the networks the matmul-and-activation work is aimed at: the bigger the model, the more the FFT convolutions and lookup-table softmax matter, and the larger the fraction of the prover those techniques cannot reach. The two curves point the same direction, and the one the field has been optimizing is the one that stops mattering first.

Where this is fair, and where it is not

A sharp argument loses the reader who knows the field if it overstates. Four qualifications are load-bearing.

First, the 11.5× and the “more than 90%” are Artemis’s numbers for prior commitment-consistency approaches — the very thing Artemis exists to fix, cutting the VGG overhead to about 1.1×. So the honest claim is not “zkML is permanently bottlenecked on the binding check”; it is that the check was the dominant cost under the standard approaches, it was invisible in the single-number benchmarks, and a paper had to specifically attack it to surface and shrink it. The bottleneck is real and addressable — and the fix is recent, and lives in a layer the circuit-optimization papers do not work in. Two layers, two research efforts; progress on one does not move the other.

Second, “more than 90%” and “11.5×” are model-dependent, and Artemis is careful that they bite on larger models. On a small MLP — the 14-layer, 3.4M-parameter network in our library benchmark — the consistency check is a much smaller slice, and a team there is right that the model computation dominates. This post is not “the binding check always dominates”; it is that the check grows to dominate precisely as the model grows, which is precisely where the matmul optimizations are aimed, so the framing fails right where it is most relied on. Place your own model on that axis before deciding which half to optimize.

Third, none of the systems papers is wrong, and none conceals the binding cost — the consistency check sits inside their aggregate numbers honestly, summed in, not omitted. The blind spot is in the framing one layer up: the folk model that a zkML proof’s cost is the model’s arithmetic, so a better circuit for the arithmetic is how you make it cheaper. The papers are the rigorous part; the model built on top of them hides the term.

Fourth, the consistency check is not free to delete, because it is the half of the statement that makes the proof mean anything. This is not waste — it is the binding that turns “some network produced this” into “the committed network produced this,” which the survey and Artemis both insist is the only version a verifier can use. The goal is not to remove the check but to count it: to stop reporting one folded number, know what fraction of the prover is binding versus computing, and optimize the half that is actually large for your model. A cheaper consistency check is the fix; pretending the check is not there is not.

Reading list

The team’s instinct was not stupid. A neural network is matmuls and activations, the convolutions were on top of the profile, and a better circuit for them is a real win on a small model. But the proof a useful zkML system produces is not “the model ran” — it is “the committed model ran,” and the second half of that sentence is a cost that grows with the model until, on the networks the circuit-optimization papers are built for, it is more than 90% of the prover and the matmuls are the rounding error. The single proof-time number on every benchmark sums the two halves and shows you neither. So decompose it before you optimize — because on a large enough network, the slow part has nothing to do with the model.

NEW ENGAGEMENT · INTAKE

Tell us about it.

The more specific you are, the more useful our first reply.

SERVICE AREA
↩ ENCRYPTED IN TRANSIT
ASK THE FIELD NOTES BETA