Verifiable AI: Proving Model Integrity with zkML and EZKL

The Black Box Problem in Regulated AI

As machine learning models move from experimental labs to the core of our financial, medical, and legal infrastructure, we face a significant engineering challenge: the 'Black Box' problem. In a regulated environment, it is not enough for an AI to be accurate; its operations must be verifiable.

Traditionally, if a bank uses a model to deny a loan, or a healthcare provider uses one to suggest a treatment, the only way to 'verify' the result is to trust that the company ran the specific model they claimed to run, on the specific data provided, without tampering with the weights or the logic. In high-stakes environments, 'trust me' is a failing architectural pattern.

This is where Zero-Knowledge Machine Learning (zkML) enters the stack. By combining cryptography with neural networks, we can generate a mathematical proof that a specific output was generated by a specific model and input, without necessarily revealing the model's proprietary weights or the user's private data. This article explores how to implement this using EZKL, one of the most robust libraries for bringing ONNX models into the world of Zero-Knowledge Proofs (ZKPs).

Understanding the zkML Primitive

To a software engineer, a Zero-Knowledge Proof is essentially a digital signature for computation. If we have a function $y = f(x)$, a ZKP allows a 'Prover' to convince a 'Verifier' that they know an $x$ and a model $f$ such that the output is $y$, without revealing $x$ or the internal parameters of $f$.

In the context of ML, we are proving Computational Integrity. We want to prove that:

1. The model architecture used was exactly what was promised (e.g., a specific ResNet-50).
2. The model weights used are the ones that were audited or registered with a regulator.
3. The inference was performed correctly according to the rules of mathematics, with no 'man-in-the-middle' tweaking the results.

Why EZKL?

Implementing ZKPs from scratch is notoriously difficult. It involves translating high-level logic into 'arithmetic circuits'—polynomial equations that a ZK-backend like Halo2 or Plonky2 can understand.

EZKL (pronounced 'Ezekiel') acts as a compiler. It takes an ONNX (Open Neural Network Exchange) file—the industry standard for model interoperability—and converts it into a zk-SNARK circuit. This allows data scientists to work in familiar frameworks like PyTorch or TensorFlow, export to ONNX, and then hand the model over to the EZKL engine for proof generation.

The EZKL Workflow

The lifecycle of a verifiable inference typically follows these steps:

1. Model Definition & Training: Train your model as usual in PyTorch.
2. Quantization: ZK circuits operate over finite fields (integers), while ML models use floating-point numbers. We must scale and discretize the model.
3. Export to ONNX: Standardize the computation graph.
4. Setup (SRS): Generate or fetch the Structured Reference String (the 'common' cryptographic material).
5. Proving: The Prover runs the inference and generates a proof (a small file, usually a few kilobytes).
6. Verification: The Verifier (a regulator, a client, or a smart contract) checks the proof against the public settings.

Practical Implementation: A Regulated Credit Scoring Example

Imagine a fintech company that must prove to a regulator that their credit scoring AI doesn't use prohibited features (like ethnicity or zip code) and that the model hasn't been modified to favor specific individuals.

1. Preparing the Model

First, we define a simple MLP in PyTorch. The key here is ensuring we use operations supported by EZKL (which covers most standard layers: Conv2D, Linear, ReLU, etc.).

import torch
import torch.nn as nn

class CreditModel(nn.Module):
    def __init__(self):
        super(CreditModel, self).__init__()
        self.layers = nn.Sequential(
            nn.Linear(10, 32),
            nn.ReLU(),
            nn.Linear(32, 1)
        )

    def forward(self, x):
        return self.layers(x)

model = CreditModel()
model.eval()

# Export to ONNX
dummy_input = torch.randn(1, 10)
torch.onnx.export(model, dummy_input, "model.onnx")

2. Quantization and Calibration with EZKL

Because ZKPs work in finite fields, we can't just pass 0.5672. We need to scale these values. EZKL handles this through a settings file. We 'calibrate' the model to find the best scale factor that maintains accuracy while fitting within the circuit's constraints.

import ezkl
import os

model_path = "model.onnx"
settings_path = "settings.json"
data_path = "input.json"

# Define the circuit settings
# 'scale' determines the precision of fixed-point arithmetic
run_args = ezkl.PyRunArgs()
run_args.input_visibility = "public"
run_args.param_visibility = "private" # Weights are hidden
run_args.output_visibility = "public"

ezkl.gen_settings(model_path, settings_path, py_run_args=run_args)
ezkl.calibrate_settings(data_path, model_path, settings_path, "resources")

3. The Setup and Proving Phase

This is the computationally expensive part. The Prover must generate the proof. In a real-world scenario, this might happen on a high-memory server.

# Generate the cryptographic keys (pk = proving key, vk = verifying key)
ezkl.compile_circuit(model_path, "model.compiled", settings_path)
ezkl.get_srs(settings_path)
ezkl.setup("model.compiled", "pk.key", "vk.key")

# Generate the proof
res = ezkl.prove(
    "input.json",
    "model.compiled",
    "pk.key",
    "proof.json",
    "single"
)

4. Verification

The verification step is incredibly fast (milliseconds) and can be done by anyone with the public vk.key. This is the 'aha!' moment: the regulator doesn't need to see your 500MB model file or your private customer data. They only need the proof.json and the small verification key.

verified = ezkl.verify("proof.json", "settings.json", "vk.key")
assert verified is True

Engineering Constraints and Trade-offs

While zkML is powerful, it is not a 'drop-in' replacement for standard inference. As a senior engineer, you must weigh several constraints:

Prover Overhead

Generating a ZK proof for a neural network is orders of magnitude slower than standard inference. A model that takes 10ms to run on a CPU might take 30 seconds to 'prove.' This makes zkML currently unsuitable for real-time applications like autonomous driving, but perfect for asynchronous processes like auditing, insurance claims, or financial reporting.

Memory Requirements

Compiling large models into circuits requires significant RAM. A medium-sized model might require 64GB or 128GB of RAM during the setup and prove phases. Techniques like 'model compression' and 'pruning' become essential tools in the zkML engineer's kit.

Numerical Precision

Converting from 32-bit floating point to fixed-point integers (quantization) introduces a 'quantization error.' You must validate that your model's performance doesn't degrade below acceptable thresholds after being transformed into a circuit.

Real-World Architectural Patterns

How do we deploy this in production? We usually see two patterns:

1. The Auditor Pattern: The company runs inference normally for the customer. Once a day, it batch-processes high-stakes decisions through EZKL and posts the proofs to a transparency log or a blockchain for regulators to audit.
2. The Privacy-Preserving Inference Pattern: A user wants to run a proprietary medical model on their private health data. The company provides the compiled model; the user runs the inference locally and sends back only the result and the proof. The company knows the result is valid, and the user knows their data never left their device.

Actionable Conclusion

Verifiable AI is the bridge between the 'move fast and break things' culture of AI and the 'zero-trust' requirements of regulated industries. To begin implementing this in your organization:

1. Identify High-Risk Models: Start with models where auditability is a legal or trust requirement, not just a 'nice to have.'
2. Audit Your Operations: Ensure your model architectures use operations supported by the ONNX-to-ZK pipeline (standardize on ONNX opsets).
3. Experiment with EZKL: Use the EZKL Python bindings to benchmark the 'Prover Time' for your specific models. Use this data to decide if you need to prune your models for efficiency.
4. Plan for Hardware: If you intend to run zkML at scale, look into GPU-accelerated proving (EZKL supports CUDA) to reduce latency.

By adopting zkML today, you aren't just adding a security feature; you are future-proofing your AI infrastructure against the inevitable wave of 'Algorithmic Accountability' regulations.