Zero-knowledge proofs of training constraints

Zero-knowledge proofs of training would let an AI developer prove that a model was trained as declared, on a committed dataset and within agreed rules such as a compute limit, without showing the weights or the data.

Peer-reviewed systems prove training on committed data for small models. Kaizen proves a 10-million-parameter model's training iterations, at batch size 16, in 15 minutes each. ZkAudit proves single training steps of small image and recommender models and estimates full-run costs.

A peer-reviewed 2026 paper proves single-sample steps that fine-tune only low-rank adapters of 13-billion-parameter language models. Proving cost is the biggest obstacle. A 2026 preprint proposes frontier-scale verification, including compute-threshold attestations, by proving only randomly challenged training steps, anchored by network observations.

It is unbuilt, and its overheads are estimates. The frontier design's biggest known weakness is that sparse challenges give probabilistic detection, and its network anchor misses traffic inside a server.

On this page

How it works

A zero-knowledge proof of training (zkPoT) lets a party prove "that they have correctly trained a committed model based on a committed dataset", revealing nothing further about the model or the data 1. A survey calls this verifiable training: certifying that updated parameters result from the declared procedure 5.

Small-scale protocols. Published systems follow three steps:

  1. The prover commits to the dataset 1 2.
  2. It fixes the data order using verified randomness 2.
  3. It proves each gradient-descent step: the forward pass, the backward pass and the weight update 2.

Kaizen adds three techniques 1:

  • sumcheck-based proofs specialised for gradient descent;
  • recursive composition, so that proof size and verifier time do not grow with the number of iterations;
  • aggregatable polynomial commitments.

ZkAudit adds proofs of arbitrary audit functions over the committed data and weights 2.

A frontier-scale design. Peigné et al. propose a design for frontier training with four parts 4:

  • Commitment. Before training, the trainer publishes a hashed commitment that combines the architecture specification, a Merkle root of the dataset and the root of the initial weights 4.
  • Hash chain. During training, the GPUs compute Merkle roots of per-layer tensors at every step and publish them in a hash chain 4.
  • Network anchor. An auditor-controlled network tap, or an attested SmartNIC, records hashes of traffic between nodes as an independent anchor 4 (see Network taps and certifiers).
  • Challenges. After the chain is frozen, the auditor challenges sampled steps. The trainer re-executes those steps, and a zero-knowledge virtual machine, with native precompiles mostly for floating-point operations, checks them against the committed roots 4.

The design also includes genesis proofs and "ex-ante" attestations that enforce policy invariants, such as compute thresholds 4.

What it establishes

What it can establish.

  • A zkPoT shows that the committed weights resulted from the declared training procedure on the committed dataset 1 2. This bears on whether a training run stayed within declared limits.
  • Peigné et al. aim to verify further claims: that training faithfully executed a pre-committed specification, how much compute it consumed, its training regime and data-content filters 4.

What it cannot establish.

  • That the data is acceptable. A proof binds data to a commitment but does not vet it. ZkAudit does not protect against data poisoning 2.
  • Every step, in the frontier design. Sparse auditing is "detection-grade, not universal" 4.
  • Full confidentiality. ZkAudit reveals the model architecture 2.

Threat model

The small-scale systems assume a cheating prover bounded by cryptographic assumptions, and a public training algorithm and architecture 1 2. The frontier design adds trust anchors 4:

  • deterministic GPU execution;
  • a physical network tap, or secure boot and device identity for the SmartNIC tier;
  • the soundness of the zkVM;
  • a public proof-checker binary.

It does not cover traffic inside a server, and its SmartNIC tier is weaker against supply-chain adversaries 4.

Implementations

Search

Full search page