Why proving modern AI on-chain forced cryptography to get architecture-aware, and what that means for anyone building AI agents on Ethereum.
Every deep learning curriculum teaches roughly the same progression: perceptron, MLP, CNN, RNN/LSTM, attention, Transformer, ViT, CLIP. It's usually taught as a story about capability. Each generation gives models a better way to represent information, capture dependencies, or work across modalities.
There's another story hidden in that same progression: verifiability.
As models got more capable, their computations also got more complex. That distinction only starts to matter once a model's output stops being something a human just reads, and becomes something another system has to act on.
Picture an AI agent that can trade an asset, release a payment, authorize a transaction, or choose a robotic action. The question stops being "did the model produce an answer" and becomes:
How can I verify that this exact model, with these exact parameters, actually produced this result from this input?
That's the problem zkML (zero-knowledge machine learning) exists to solve. And the interesting story in 2026 isn't that Transformers are impossible to prove. They aren't. The interesting story is that proving them efficiently forced cryptographic systems to become aware of how modern AI models are actually built, rather than treating every model as a generic pile of math.
The problem is verifiable inference, not inference
Running a model is easy. The hard part is proving the result actually came from the computation the protocol expected.
A normal AI pipeline looks like this:
Input → Model → Output
If an application just needs an answer displayed to a person, that's enough. But once the output controls money, permissions, or a physical action, you need another layer:
Input → Model → Decision → Verification → On-chain action
A smart contract can verify signatures, balances, and deterministic state transitions on its own. It cannot automatically know whether the claimed model actually produced the output, whether the correct weights were used, or whether the operator running the model just fabricated a plausible-looking result. Without an additional verification mechanism, the protocol is trusting the machine that ran the model, full stop. Fine for a lot of ordinary applications. A very different problem the moment an AI agent gets to act on a protocol's behalf.
What zkML actually proves
At a high level, zkML tries to prove one statement: this model, given this input, produced this output. Instead of asking the verifier to re-run the entire model, the prover runs it once and generates a cryptographic proof of the computation. The verifier checks the compact proof instead of repeating the inference.
The hard part is turning a machine learning computation into something a proving system can efficiently handle. Different zkML systems make different trade-offs here. Some compile a model's computation graph into arithmetic circuits. Others use techniques like sumcheck or lookup arguments to handle large matrix operations and non-linear functions more efficiently. Most of this article is really about one question: why does the architecture of the AI model matter so much to the cost of proving it?
Why ordinary ML arithmetic doesn't translate cleanly into ZK
Machine learning models are built around operations that are convenient for GPUs: floating-point multiplication, matrix operations, normalization, non-linear activation functions. Cryptographic proving systems work differently. They're built around algebraic operations that can be efficiently constrained and checked. So before a model can be proven, its computation has to be re-expressed in a form the proving system actually understands. Some operations translate cleanly. Others don't.
That translation gap is a big reason zkML can be dramatically more expensive than ordinary inference. Large matrix multiplications are costly but manageable. Non-linear functions like softmax, GELU, and LayerNorm tend to introduce disproportionate extra proving overhead relative to how cheap they are to run on ordinary hardware.
Where quantization helps, and where it doesn't. Quantization swaps high-precision weights and activations for lower-precision representations, which usually makes the computation cheaper to prove. But there's no universal accuracy penalty and no single "best" bit width; the effect depends heavily on the model, the task, and the calibration method used. It's also worth separating two different claims that get conflated a lot: proving that a quantized model produced a given output is not the same as proving that the quantized model behaves identically to the original floating-point model. Those are genuinely different statements, and only the first one is what a typical zk proof actually gives you.
Re-reading the architecture progression through proving cost
The evolution of deep learning can also be read as an evolution in the structure that a cryptographic prover has to handle.
Perceptron and small MLPs
Early zkML experiments focused heavily on relatively regular feed-forward networks.
Modulus Labs' 2023 The Cost of Intelligence benchmark explored this regime across several proving systems and reported proving an 18-million-parameter MLP in roughly 50 seconds with Plonky2 under its benchmark conditions.
That result is important historically, but it is often misquoted. It was an MLP experiment, not a universal limit for CNNs or zkML.
CNNs
CNNs apply the same convolutional operations repeatedly across an image.
That regularity makes their computation relatively structured from a proving perspective. CNNs therefore became an important next target for practical zkML systems.
RNNs and LSTMs
RNNs introduce something different: sequential dependency.
Each state depends on the previous state:
hₜ = f(hₜ₋₁, xₜ)
LSTMs add several gates and non-linear operations on top of that dependency.
This makes the computation less naturally parallel than a CNN and adds more operations that have to be represented inside the proof.
Transformers
Transformers change the problem again.
Self-attention allows every token to interact with other tokens:
Q = XWQ
K = XWK
V = XWV
Attention = softmax(QKᵀ / √dₖ)V
The challenge is not softmax alone.
A Transformer combines large matrix multiplications, global token interactions, normalization, non-linear functions, residual connections, and many repeated layers.
That combination creates a much larger and more complex proving workload.
ViT and CLIP
Vision Transformers apply the same basic Transformer machinery to image patches, while CLIP combines image and text encoders in a shared embedding space.
So the proving problem does not disappear when the modality changes.
Instead, the computational graph becomes even more interesting: more encoders, more representations, and potentially more components that need to be bound to the proof.
The broader lesson is simple:
Every architectural improvement in AI changes the shape of the computation that a prover has to understand.
It's not just about parameter count
A common mistake is treating parameter count as the main predictor of proving cost. It isn't. Two models with identical parameter counts can have wildly different proving costs. A more useful mental model:
Proving cost ≈ model size + operation types + non-linearities
+ precision + memory requirements + architecture + proving system
A generic compiler treats a model as a pile of unrelated operations. A proving system designed around a model's actual structure can exploit repetition, sparsity, and natural layer boundaries instead. That difference is exactly what changed the field between 2023 and 2026. The real question isn't "how big is the model," it's "how does the model compute."
The 2023-2024 baseline that exposed the bottleneck
Before looking at what changed, it's worth seeing what the problem looked like a couple of years earlier. A 2024 survey of decentralized inference methods reported the following latency figures across different verification approaches:
| Approach | Reported latency | Model | Guarantee |
|---|---|---|---|
| Proof of Quality (lightweight assessor) | ~50 ms | MobileNet v2 | Statistical plausibility, under 70% accuracy at that speed |
| TEE (Intel SGX) | ~230 ms | VGG-16 | Hardware attestation |
| Homomorphic encryption | ~788 s | SqueezeNet | Cryptographic hardness of the encryption scheme |
| Halo2 ZK-SNARK | ~2,457 s | MobileNet v2 | Cryptographic soundness |
| Optimistic ML (opML) | ~3.6 hours (incl. challenge window) | ResNet-50 | Economic incentives + a challenger |
| General ZKML | 24+ hours | ResNet-50 scale | Cryptographic soundness, severe latency cost |
These numbers come from different implementations, hardware, and proof statements, so treat them as directional rather than a controlled comparison. What matters is the scale of the problem they show: even proving CNN-level inference could take minutes to hours depending on the approach, and full Transformer-scale proving simply wasn't being reported as a practical, working regime at all.
The bottleneck moved
For a long time, the main problem in zkML was simply scale.
Large neural networks could be represented as circuits in principle, but proving those circuits was often far too expensive to be practical. The important change between 2024 and 2026 was that researchers stopped treating the model as just a generic computation graph. Instead, they began designing proving systems around the structure of the model itself.
That shift produced several very different approaches.
DeepProve: proving the Transformer directly
DeepProve, developed by Lagrange Labs, uses a sumcheck/GKR-based approach rather than relying entirely on traditional arithmetic-circuit representations.
The important idea is not just that it uses a different proof system. It is that the prover can take advantage of the regular structure of neural-network computation, including large matrix operations and Transformer-specific components.
In August 2025, DeepProve-1 demonstrated a full zero-knowledge proof of GPT-2 inference, including the Transformer computation needed to produce the model's output. Later releases expanded the system to additional Transformer models.
Lagrange has also reported substantial speedups over circuit-based baselines. Those numbers come from Lagrange's own benchmarks, however, so they should be treated as vendor-reported performance figures, not as universal comparisons across all proving systems.
The important result is therefore bigger than any individual speedup:
A Transformer-scale model was no longer merely theoretically provable. It became a practical target for specialized proving systems.
zkPyTorch: bring ordinary ML models into ZK
zkPyTorch, developed by Polyhedra Network, takes a different approach.
Instead of requiring developers to redesign their models around cryptographic primitives, it provides a compiler that takes models written in PyTorch and converts them into ZK-compatible computations using Polyhedra's Expander proving infrastructure.
Their published benchmarks report approximately 2.2 seconds per proof for VGG-16 on CIFAR-10 on a single CPU core. They also report approximately 150 seconds per token for Llama-3 8B under their stated benchmark conditions.
The second number is still far from normal LLM serving latency. But that is not the point. The important change is that LLM-scale inference had entered the measurable proving regime rather than remaining purely theoretical.
Jolt Atlas: make non-linear operations lookup-friendly
Jolt Atlas, from ICME Labs, attacks another major source of proving cost.
Many neural-network operations are awkward to represent directly as arithmetic constraints, particularly non-linear functions. Jolt Atlas therefore builds on Jolt's lookup-centric proving approach, applying lookup arguments and sumcheck techniques to ONNX tensor operations.
This allows expensive functions to be represented through lookup structures rather than forcing every operation into a conventional arithmetic-circuit representation.
Their published benchmarks include experiments on both small Transformer models and GPT-2. For example, their current benchmark reports roughly 38 seconds of end-to-end proving for GPT-2 at 125 million parameters on a MacBook Pro M3 under their stated setup.
Again, the exact number should not be treated as a universal benchmark. Different proving systems use different hardware, implementations, proof systems, and measurement boundaries.
But the direction is clear: Transformer inference is becoming something that can be measured in seconds rather than being dismissed as impractical by default.
NanoZK: don't prove the whole Transformer at once
NanoZK takes the idea of architecture-awareness in a different direction.
Instead of treating the Transformer as one enormous computation, it breaks inference into independently provable layers connected through commitments.
That matters because a Transformer already has a natural repeated structure: attention and feed-forward blocks are applied layer after layer. Rather than fighting that structure, NanoZK uses it.
The paper reports constant-size layer proofs and approximately 22 ms verification time per layer under its experimental setup. It also uses lookup-table approximations for operations such as softmax, GELU, and LayerNorm.
The important idea is not simply that the proofs are smaller. It is that the architecture itself becomes part of the proving strategy.
Four systems, one important change
These systems do not solve the problem in the same way:
| System | Main idea | What it exploits |
|---|---|---|
| DeepProve | Sumcheck / GKR-style proving | Repeated neural-network computation and Transformer structure |
| zkPyTorch | ML-to-ZK compilation | Standard PyTorch model structure |
| Jolt Atlas | Lookup-centric proving | Tensor operations and non-linear functions |
| NanoZK | Layerwise proving | The natural repeated structure of Transformers |
The common pattern is more important than the individual benchmarks.
None of these systems made Transformer proving free. They changed where the optimization happens.
Instead of asking:
“Can we turn this enormous AI model into a circuit?”
the field increasingly asks:
“What does this architecture do repeatedly, and how can the proving system exploit that structure?”
That is the real bottleneck shift.
The challenge is no longer simply whether a Transformer can be represented inside a cryptographic proof system. It can.
The harder questions are now about proving cost, memory, latency, proof size, verification cost, model fidelity, and whether the resulting proof is economical enough for the application that needs it.
In other words, zkML has moved from “is this model provable?” toward “what proving architecture makes this model worth proving?”
That is a much more interesting problem.
Proof granularity is a protocol design decision, not a technical afterthought
One of the most important questions in zkML isn't how to prove a model, it's what actually needs to be proven. NanoZK's layerwise approach makes this especially clear: a protocol doesn't necessarily need a cryptographic proof of an entire model's inference to get a useful guarantee.
At the top of that spectrum sits the strongest, most general statement a protocol could ask for: this specific model produced this specific output from this specific input. That statement can also be extremely expensive to prove. Moving down the stack shrinks the computation and the cost, but the guarantee gets narrower and more application-specific too. Instead of proving an entire LLM's reasoning trace, an agent protocol might only need to prove that a proposed transaction stays under a spending limit or belongs to an approved set of actions.
That trade-off matters because the most technically impressive proof isn't automatically the most useful one. If an application only needs a safety constraint verified, proving millions of model operations underneath it adds enormous cost without a proportional gain in the actual guarantee the protocol receives. Proof granularity is a protocol design decision. The right question isn't "how much of the AI can we prove," it's "what is the smallest statement the protocol actually needs to trust." That answer determines what gets proven, how expensive verification becomes, and what security property the protocol actually ends up with.
Model identity and input binding are part of the security model
There's a problem that's easy to miss once inference itself can be proven: a proof is only useful if you know exactly what was proven. Suppose a prover hands the verifier a perfectly valid proof for "model A, given input X, produced output Y." If the application expected model B, that proof is still cryptographically valid, it's just proving the wrong computation. The same issue exists on the input side. A proof generated for one transaction or context shouldn't be silently reusable in a different one.
That makes model identity and input binding part of the actual security model, not metadata bolted on afterward. ERC-7992, currently a Draft Ethereum proposal, addresses exactly this. Its ModelCommitment binds a model to hashes of its weights and architecture, the proving circuit, and the verifying key, plus an identifier for which proof system is in use.
A verifier can then work with a model identifier and an input commitment instead of treating a proof as a floating, context-free object. The input commitment matters specifically for preventing replay: without it, a valid proof from one context could be copied into another where it was never meant to apply. ERC-7992 recommends domain separation and a nonce or salt in input commitments to bind a proof to the context it's actually meant for.
This is still a Draft, not an adopted standard, so it shouldn't be treated as settled infrastructure yet. But the direction matters. As zkML moves from isolated demos toward protocols that actually consume model outputs, the ecosystem needs shared answers to questions like: which model produced this, which version, which proving system, can this proof be replayed elsewhere, and what happens when the model gets upgraded. These aren't secondary implementation details, they define what the proof actually means at the protocol level.
Large model proposes, small verifier proves
For most AI agents, the practical architecture isn't proving the entire model. It's letting the large model reason off-chain, and proving only the small decision the protocol actually needs to trust.
An AI agent might propose a transaction. The protocol probably doesn't need to prove every token prediction that led to that proposal, it just needs to prove the action stays within a spending limit, that the destination is allowed, or that a required safety condition holds. That can shrink an enormous AI computation down to a small, cheap-to-verify statement.
There's an important limit worth being blunt about: this architecture doesn't prove the AI made a good decision, it proves the proposed action passed a policy check. If the policy is incomplete, a perfectly valid proof can still wave through a bad action. Policy design and proof design have to be considered together, not separately, and a cryptographically sound proof of a sloppy policy is still a weak guarantee overall.
It's also worth being precise about a distinction that gets blurred: account abstraction (ERC-4337) answers who is allowed to act, by giving smart accounts custom authorization logic. It says nothing about whether the decision that triggered the action actually came from the model the agent claims to run. Authorization and inference integrity are two separate layers, and treating them as the same thing is a common design mistake.
Robotics sharpens the same trade-off
Robotics makes the latency problem obvious in a way finance doesn't. A VLA (vision-language-action) model might spend seconds reasoning about a high-level task, while a low-level controller needs fresh decisions every few milliseconds. There's no single verification strategy that fits both ends of that range at once.
The high-level planner can afford to use a powerful, slower model with heavier verification. The safety layer underneath it checks a much smaller set of bounded conditions instead: is the target inside the permitted workspace, is velocity under a limit, is force under a threshold, is the action allowed given the current state. The idea is the same one from the financial-agent case: you don't need to prove the entire intelligence pipeline to make the critical action verifiable, you need to isolate the smallest thing that actually has to be trusted and prove that.
Top comments (0)