Zero-knowledge proofs of inference

How it works

A zero-knowledge proof of inference lets a prover convince a verifier that an output came from a specific model on a specific input, without revealing the model's weights ⁷. A survey describes ZKPs as letting one party certify that a training, testing or inference result "was produced by the claimed computation without revealing sensitive data or proprietary model parameters" ⁷.

The protocol has two steps:

1. The prover publishes a cryptographic commitment to the weights once. For LLaMa-2-13B, zkLLM's commitment took 986 seconds ¹.
2. For each query, the prover proves that the output equals the committed model applied to the input ^{1 3}. The verifier checks the proof without the weights and without rerunning the model ¹.

Only the weights are hidden. In zkLLM's setting the verifier submits the prompt and receives the output with its proof ¹. South et al. likewise keep weights private and inputs and outputs public ⁵.

Systems turn the network's operations into arithmetic over a finite field, with tensors as fixed-point numbers ^{3 1}. Softmax, GELU and normalisation need special handling:

• zkLLM uses a parallel lookup argument (tlookup) and an attention-specific protocol (zkAttn) ¹.
• NanoZK uses 16-bit lookup tables ⁴.

Proof systems differ:

• ZKML compiles models to halo2 circuits with either KZG commitments, which need a trusted setup, or transparent IPA commitments ³.
• zkLLM uses sumcheck-based protocols with Hyrax commitments ¹.
• NanoZK proves each transformer layer separately and links the layers with a chain of SHA-256 commitments ⁴.
• Attestable reports a prover whose security rests "only on the security of cryptographic hash functions" ⁸.

Proofs over many inputs can be packaged into attestations that a model with fixed private weights reaches a stated benchmark score ⁵.

What it establishes

What it can establish.

• A valid proof shows that the output follows from the committed weights, the public architecture and the input ^{1 3}. This bears directly on The declared model is the one being served.
• The weights stay confidential against a verifier that follows the protocol. zkLLM's zero-knowledge theorem shows that such a verifier's view reveals nothing about the weights beyond the output ¹.
• Attestable proposes proofs that an accounted workload "used an approved, unchanged model rather than a newly trained replacement", which bears on This compute runs inference, not training ⁹.

What it cannot establish.

• Which model the commitment is. The proof does not tie the committed weights to an outside identity such as "the declared model". Proven benchmark results over the committed weights are one way to link them ⁵. Committed weights can also be hollow. Weights with the declared architecture and parameter count can route the work through a much smaller model and still yield valid proofs ¹².
• Work that was not proven. Attestable notes that "a proof of some computation is not a proof of all computation", and that a proof cannot find an undeclared datacenter ⁹.
• Every output, when only some are proven. Assurance from sampling is probabilistic. Attestable proposes selecting outputs at random for proof after they have been committed ¹⁰. NanoZK bounds the chance of detecting tampering when auditors check a subset of layers ⁴.
• The floating-point model. What is proven is a fixed-point approximation of the model ¹. Attestable reports 8-bit integer matrix multiplications ⁸.
• A hidden architecture. ZKML requires the architecture to be revealed ³, and zkLLM assumes it is publicly known ¹.

Threat model

Soundness rests on computational assumptions against a cheating prover:

• zkLLM proves its lookup argument sound: a cheating probabilistic polynomial-time prover succeeds only with negligible probability. The rest of its protocol applies sumcheck and proofs of opening for commitments whose binding rests on discrete-log hardness ¹.
• NanoZK assumes a polynomial-time adversary that controls the inference infrastructure and may substitute models or fabricate outputs. It relies on discrete-log hardness over the Pallas curve and SHA-256 collision resistance ⁴.
• Attestable reports 100-bit security, and post-quantum security because it avoids public-key cryptography ⁸.

Confidentiality rests on further assumptions:

• zkLLM assumes a semi-honest verifier, which "accurately reports the outcome of the proof verification" but tries to learn the weights. Its zero-knowledge theorem also assumes zero-knowledge variants of the sumcheck protocols ¹.
• NanoZK leaves side channels, denial of service and hiding the input from the provider out of scope ⁴.
• Attestable treats physical-access and metadata channels as separate threats ¹⁰.

Evidence

• ZKML. It proved a distilled 81.3-million-parameter GPT-2 in 3,651.67 seconds on a 128-vCPU, 1 TB machine. This was the largest model its authors could prove with under 1 TB of RAM ³.
• South et al. They used ezkl to prove evaluations of small models. A 250,000-parameter nanoGPT took 2,781 seconds to prove and needed a 219 GB proving key ⁵.
• zkLLM. It proved OPT models up to 13B and LLaMa-2 models of 7B and 13B, each proof covering one 2,048-token forward pass on one A100 GPU. LLaMa-2-13B took 803 seconds to prove and 3.95 seconds to verify, with a 188 kB proof ¹. Its code is public ².
• NanoZK. It reports proofs of 3.2 to 3.7 KB per attention or MLP sub-circuit, about 83 KB in total for 12 layers. From per-component timings, it projects that a 12-layer GPT-2 would take about 14 minutes to prove sequentially on CPU ⁴.
• Attestable. It reports proving a 31-billion-parameter Gemma model at 53 tokens per second for one 16K-token sequence on one H100 GPU, with 4.35 to 7.92 MiB proofs and 157 to 648 ms CPU verification. No code or paper accompanies these results ⁸.
• Independent audit of ezkl. Trail of Bits reviewed the ezkl library in January 2025, at its developer's request. It reported three high-severity circuit soundness issues and four ways to bypass data attestation in ezkl's smart contracts. Its fix review found every high-severity finding resolved ⁶.
• Hollow-LLM attack. Researchers at the University of Southern California ran a ghost-weight attack through zkGPT's proof procedure on a 6-layer, 512-dimensional transformer declared as up to 12 layers and 1,024 dimensions. Outputs were unchanged and serving cost stayed at the small model's level ¹².

A verification system design for AI agreements lists ZKPs as a "tentative plan B" that could "remove the need for secure computing hardware setups" ¹¹.

Limitations

Cost.

• zkLLM needs about 12 to 13 minutes per 2,048-token forward pass at 13B scale on one A100 ¹.
• The verification system design calls the overhead "heavy" ¹¹.
• The survey names "limited circuit expressiveness, high proving cost, and deployment complexity" as the main implementation bottlenecks ⁷.

Expressiveness. ZKML does not support branching or variable-length loops, so language models need fixed-length inputs ³. Floating-point emulation remains open ¹¹. Attestable reports a 16K-token context limit ⁸.

Implementation soundness. In ezkl, Trail of Bits found circuits with missing constraints that "would allow a malicious prover to convince a verifier of incorrect calculations"; these were fixed ⁶. The zkLLM README says its code "has NOT undergone security auditing and is NOT ready for industrial applications". It also says prover and verifier run side by side, and that a deployment would need Fiat–Shamir to be non-interactive ².

Quantisation. Trail of Bits also built a ResNet-18 backdoor that is dormant in the full-precision model and active after ezkl's quantisation. Whether it persists through proving was left for further investigation ⁶.

Coverage. A proof covers only the outputs proven ⁹. For accounting of other work, see Proofs of useful work and resource exhaustion. A proof also does not show how much computation produced an output. In the Hollow-LLM attack, weights with the declared architecture let a much smaller model do the work, and the proofs remain valid ¹².