Zero-Knowledge Proof of Model Inference

Description

A zero-knowledge proof of model inference lets the owner of a model show an outside party that one specific model, fixed in advance, turns a particular input into a particular output, without revealing the model's weights. The owner publishes a commitment to the weights, a short cryptographic fingerprint such as a hash that binds them without disclosing them, together with a verification key that fixes the model's architecture. The model's arithmetic is converted to whole numbers (quantised) and written as a system of equations called a circuit, and for each input a proving system produces a proof, of a few kilobytes to a few hundred kilobytes, that this circuit, run with weights matching the commitment, turns that input into that output; the input can be public or committed in the same way. Anyone holding the verification key can check the proof in milliseconds to seconds: it shows that the committed model gives that output for that input, while keeping the weights hidden, and says nothing about whether that model is accurate, fair or safe. Unlike homomorphic encryption, which lets a server compute on data it cannot read but gives the caller no evidence of which computation was run, and unlike model signing, which lets someone who holds a model's files check who released them, it lets someone who never sees the weights check individual outputs against them.

Example Use Cases

Transparency

A credit-scoring vendor publishes the weight commitment in the report of an independent bias and accuracy audit, which was run on the quantised model bound to that commitment. When a refused applicant complains, the lender's complaints team asks the vendor for a proof for that decision and checks it against the published commitment, to confirm that the audited model gives the same refusal on the applicant's data before it reviews the decision itself.

A hospital trust buying chest X-ray triage results from a cloud provider writes into the contract that its clinical engineering team may challenge a random sample of each month's results. For each sampled case the provider must return a proof against the commitment to the model the trust validated, and the team treats a failed or missing proof as evidence that a different model was served, which triggers the contract's audit clause.

An online-safety regulator inspecting the age-estimation service a platform relies on submits its own test images and asks for a proof with each estimate. Its inspectors check each proof against the commitment registered when an accredited laboratory certified the vendor's model, to decide whether the service in use is the certified model, without the vendor handing its proprietary weights to the regulator.

Limitations

A valid proof shows that the committed weights turn this input into this output. It does not show that the model is accurate, fair or safe, that the input was genuine, or that the service ran the committed model: a different model giving the same output passes too, so spot checks catch a substituted model only on inputs where the two disagree. A commitment carries assurance only if an audit was run on the model it binds.
Proving costs far more than running the model. Published figures: 88 seconds per prediction of a 15-million-parameter VGG16 on CIFAR-10 images (zkCNN), about 41 minutes for an ImageNet-scale MobileNet on a large cloud server (Kang et al.), and about 13 minutes for one 2,048-token pass of a 13-billion-parameter language model on a data-centre GPU, after a one-off 16-minute commitment (zkLLM). Proving every output of a busy service is impractical, so protocols prove sampled or disputed outputs.
The proof covers a quantised, whole-number version of the model, not the floating-point model that was trained and perhaps audited, and the two can give slightly different outputs. Published attacks plant backdoors that stay dormant at full precision and activate only after quantisation, which EZKL's security notes flag. Audits and accuracy tests must therefore be run on the quantised model that is actually proved, or the commitment and the audit describe different models.
The guarantee depends on configuration. If the weights are private inputs with no published commitment, a proof shows only that some weights for the stated architecture give the output. Hashing the weights inside the proof keeps them hidden but costs about as much again as proving the inference. EZKL's cheaper settings, including its Python default, bind the weights without fully hiding them, and its notes warn they can be recovered from enough proofs. The architecture is normally disclosed.
Soundness rests on the software as well as the mathematics. A compiler error that leaves the equations under-constrained can let a false proof verify, a risk EZKL's documentation names, and EZKL's proofs rely on public parameters from a multi-party set-up ceremony. Audits cover specific releases (EZKL's covered version 21), so verifiers should fix which tool versions and parameters they accept. EZKL, the most used tool, has had no open-source licence since January 2024.

Resources

Research Papers

Zero Knowledge Proofs for Decision Tree Predictions and Accuracy

Jiaheng Zhang et al.•Oct 30, 2020

zkCNN: Zero Knowledge Proofs for Convolutional Neural Network Predictions and Accuracy

Tianyi Liu, Xiang Xie, and Yupeng Zhang•Nov 12, 2021

Software Packages

ezkl

Oct 10, 2026

Compiles a model exported to ONNX into a Halo2 circuit and proves and verifies its inference from a command line or Python. Source-available, not open source: the Apache-2.0 licence file was removed on 7 January 2024 and the repository now states only "Copyright (c) 2026 Zkonduit Inc.", with contributions taken under a contributor licence agreement.

Tutorials

hashed-ezkl: hashing the model inputs and parameters inside the circuit (EZKL example notebook)

ezkl is an engine for doing inference for deep learning models and other computational graphs in a zk-snark (ZKML). Use it from Python, Javascript, or the command line. - zkonduit/ezkl

Documentations

EZKL Documentation: Getting Started

Let's briefly preview the steps to generate and verify a model:

Related Techniques

Name	Description	Assurance Goals
Model Signing	Model signing lets the publisher of a machine-learning model attach a cryptographic signature to the model's files, so that anyone who later loads them can check who released them and that no file has changed since. Under the Open Source Security Foundation's Model Signing (OMS) specification and its reference tool, model-signing, the publisher computes a hash (a short fingerprint that changes if a single byte of the file changes) of every file in the model directory, such as weights, configuration, tokeniser and any dataset files kept with them, lists the hashes in a sorted manifest and signs the manifest, producing a detached signature file kept beside the model. The signature can be made with the publisher's own key, with a certificate from an organisation's certificate authority, or through Sigstore, which issues a short-lived certificate tied to a verified online identity, such as a person's account or a build pipeline's, and records each signing event in a transparency log, an append-only record that can be inspected afterwards. Before loading, the consumer verifies the signature against the signer it expects, recomputes every hash and rejects the model if any listed file differs or is missing or, unless that check is switched off, an unlisted file has appeared, so the evidence is a pass or fail tied to a named signer and an exact set of files. Unlike the unsigned file hashes kept by data-versioning tools, it shows who stands behind the files, and unlike a watermark, which is trained into the weights so that it survives in an altered copy, it is broken by any change; it says nothing about how the model behaves or what it was trained on.	Security
Deep Ensembles	Deep ensembles estimate how uncertain a neural network's predictions are by training several copies of the same network independently and comparing what they predict. Each copy starts from different random initial weights, sees the training data in a different random order, and is trained to output a full predictive distribution, such as a probability for each class or a predicted value with its spread, rather than a single answer. The ensemble's prediction is the average of its members. Where members agree the prediction is usually more reliable, though agreement alone is no guarantee, and where they disagree the model is showing uncertainty about which answer is right, known as epistemic or model uncertainty. In the original study, ensembles of about five networks were better calibrated than single networks, meaning their stated confidence matched how often they were right, and expressed higher uncertainty on inputs from classes absent from the training data.	Reliability Transparency
Trigger-Set Model Watermarking	Trigger-set model watermarking lets the owner of a trained classifier show later that a suspect model was copied from theirs, by planting a secret behaviour that only the owner can demonstrate. Before release, the owner chooses a small secret trigger set (in the originating scheme, 100 abstract images), gives each input an arbitrary label unrelated to its content, and trains or fine-tunes the model to return those labels while keeping its accuracy on the real task. In the originating scheme the owner also records cryptographic commitments to the trigger inputs and their labels, which fix the watermark at release so that a trigger set cannot be invented once a dispute has begun. To verify, the owner, or an arbiter shown the opened commitments, sends the trigger inputs to the suspect model through its ordinary prediction interface and counts how many return the assigned labels; an independently trained model matches them at about chance level, so a match rate above a preset threshold is evidence of copying. The technique produces the watermarked model, the commitments and, for each verification, the suspect model's trigger-set accuracy against the threshold.	Security