How to Implement Zero-Knowledge Proofs for Model Integrity

Zero-knowledge proofs (ZKPs) allow one party, the prover, to convince another party, the verifier, that a statement is true without revealing any information beyond the validity of the statement itself. For model integrity, this means you can prove a model made a specific prediction from a given input, or that it was trained correctly on a private dataset, without exposing the model's weights or the sensitive training data. This is critical for trustless verification in decentralized AI, confidential inference, and proving compliance with training regulations. The two primary cryptographic systems used are ZK-SNARKs (Succinct Non-interactive Arguments of Knowledge) and ZK-STARKs (Scalable Transparent Arguments of Knowledge).

The implementation workflow involves three core steps. First, you must arithmetize your model's computation, converting operations like matrix multiplications and activation functions into a constraint system a ZKP can understand, often using a framework like circom for SNARKs. Second, you generate the proving and verification keys. For a SNARK, this requires a trusted setup ceremony to create a Common Reference String (CRS), while STARKs avoid this need. Finally, you run the proving algorithm on the private inputs (model weights, data) and public inputs/outputs to generate a proof, which the verifier can check using only the verification key and the public data.

For a concrete example, consider proving a simple linear regression prediction y = w*x + b. Using the circom compiler, you would write a circuit that defines this computation as constraints. After compiling, you use snarkjs to perform the trusted setup, generate proofs, and verify them. The prover would supply the private w and b, while x and the resulting y could be public. The verifier receives only the proof and the public values, gaining cryptographic certainty that y was computed correctly from x using some consistent w and b, whose values remain hidden.

Key challenges include managing the proving overhead. ZKPs add significant computational cost; proving time and proof size are non-trivial for large models. Techniques like model quantization, pruning, and using recursive proofs can help. Furthermore, not all operations (e.g., non-arithmetic functions) are ZKP-friendly. Libraries like zkml and EZKL are emerging to help compile common ML frameworks like PyTorch into ZK circuits. When choosing between SNARKs and STARKs, consider trade-offs: SNARKs have smaller proofs and faster verification but require a trusted setup; STARKs are post-quantum secure and transparent but generate larger proofs.

Practical applications are growing. In decentralized inference, a model owner can serve predictions on-chain with a ZKP, allowing smart contracts to trustlessly use AI. For model auditing, a training institution can prove a model was trained on compliant data without leaking the dataset. In federated learning, participants can prove they performed a correct training step. To start, experiment with frameworks like circom and snarkjs for SNARKs or starkware-libs/cairo for STARKs, beginning with small models to understand the proof generation pipeline and gas costs for on-chain verification.

Implementing zero-knowledge proofs (ZKPs) for model integrity, often called ZKML, requires a specific technical stack. You'll need a working knowledge of a high-level ZKP framework like Circom, Noir, or Halo2. For this guide, we'll focus on Circom, a popular domain-specific language for writing arithmetic circuits, which is the foundation of ZK proofs. You must also have Node.js (v18 or later) and npm installed. The core tool is the Circom compiler, which you can install globally via npm install -g circom. This setup allows you to compile your circuit logic into the constraints that a ZK proving system will use.

Beyond the compiler, you need a proving backend. SnarkJS is the essential companion library for Circom, handling trusted setup ceremonies, proof generation, and verification. Install it with npm install -g snarkjs. For model-related computations, you'll interact with a Python environment using libraries like NumPy or PyTorch to export model weights and generate inputs. A critical preparatory step is designing the circuit logic: you must decide which part of your model's inference you want to prove—such as a single layer's computation or a hash of the final weights—and express it as a series of arithmetic operations.

Finally, set up a project structure to keep your components organized. A typical ZKML project has directories for: circuits/ (your .circom files), build/ (compiler outputs), inputs/ (JSON files containing test inputs for the circuit), and scripts/ for automation. Start by writing a simple circuit, like one that proves knowledge of a model weight and an input that yields a specific output, to validate your toolchain. Ensure you understand the flow: 1) Write the circuit, 2) Compile it, 3) Perform a Powers of Tau ceremony, 4) Generate proving/verification keys, 5) Compute a witness, and 6) Generate and verify a proof.

In Zero-Knowledge Machine Learning (zkML), integrity and privacy are distinct but complementary properties. Model integrity refers to the ability to prove that a specific, untampered model produced a given output for a given input. This is crucial for applications like verifiable inference on-chain or proving fair execution of an AI agent. In contrast, model privacy involves keeping the model's weights, architecture, or training data secret. This tutorial focuses on the foundational task of proving integrity, which is often the first step before adding privacy-preserving layers.

The core mechanism for proving integrity is a zk-SNARK (Succinct Non-interactive Argument of Knowledge). You construct an arithmetic circuit that represents your model's forward pass. For a simple model like a linear regression with weights w and bias b, the circuit would compute y = w * x + b. A zk-SNARK proof demonstrates that you know private inputs (w, b, x) that satisfy this public circuit, producing a public output y. The verifier only receives the proof and the output y, confirming the computation was correct without learning the private inputs.

To implement this, you typically use a zkDSL (Domain-Specific Language) like Circom or a library such as gnark. First, you define your model's computation as constraints. For example, in Circom, a circuit for a single neural network layer with a ReLU activation might involve multiplication, addition, and a comparison to zero. The prover then generates a witness (the actual values for all signals in the circuit) and uses it to create a proof. This proof is small and can be verified on an Ethereum Virtual Machine (EVM) compatible chain using a verifier smart contract.

A practical use case is verifiable inference for DeFi. Imagine a lending protocol that uses a credit risk model to determine loan terms. By putting the model's integrity proof on-chain, the protocol can guarantee to all users that the score was calculated fairly using the approved model, preventing manipulation by the protocol's operators. The model itself can remain private off-chain. Frameworks like EZKL and zkml are emerging to streamline this process, allowing you to export models from PyTorch or TensorFlow directly into zk-SNARK circuits.

When implementing, key challenges include circuit size and proving time. Complex models with millions of parameters create massive circuits, making proof generation computationally expensive. Techniques like model quantization, pruning, and using lookup tables for activations are essential for feasibility. The choice of proving backend (e.g., Groth16, PLONK) also affects performance and trust assumptions. Always benchmark with a simplified version of your model first to understand the computational trade-offs.

To get started, explore the Circom documentation to learn circuit writing, or use a higher-level tool like EZKL. The fundamental workflow remains: 1) Define your model as a circuit of constraints, 2) Generate a proof for a specific input/output pair, and 3) Deploy a verifier contract to validate proofs on-chain. This establishes a trustless guarantee of computational integrity, forming the bedrock for more advanced zkML applications that also incorporate data and model privacy.

A model commitment is a cryptographic fingerprint, typically a hash, that uniquely represents a machine learning model's architecture and parameters. This commitment is published on-chain or to a public bulletin board, serving as an immutable reference point. Before any inference can be proven, the prover must demonstrate they are using the exact model defined by this commitment. This prevents a malicious prover from swapping in a different, potentially biased or backdoored model after the fact. Tools like Giza, EZKL, and RISC Zero provide libraries to serialize and hash model weights from frameworks like PyTorch and TensorFlow.

The commitment process involves serializing the model state into a deterministic byte array. This includes the model architecture definition (e.g., the number and type of layers) and all trainable parameters (weights and biases). Any non-determinism in this serialization, such as random floating-point rounding or unordered data structures, will cause verification to fail. Best practice is to export parameters to a fixed-point integer representation, as ZK circuits operate natively in finite fields. The resulting hash, such as a Poseidon or SHA-256 digest, becomes the public Model ID.

In practice, generating this commitment is often integrated into the model training pipeline. For example, after training a ResNet-20 model on CIFAR-10, you would use a script to export the finalized state_dict to a fixed-point format, compute its hash, and post this hash to a smart contract like ModelRegistry.sol. The associated smart contract function might look like:

solidityCopy
function commitModel(bytes32 modelHash, string memory metadataURI) public {
    require(modelRegistry[modelHash] == false, "Model already committed");
    modelRegistry[modelHash] = true;
    emit ModelCommitted(modelHash, msg.sender, metadataURI);
}

This on-chain record is the anchor for all future zero-knowledge proofs about the model's behavior.

It is critical that the commitment encompasses all inputs that affect inference. This extends beyond weights to include fixed hyperparameters, preprocessing steps (like mean subtraction constants), and the exact software version of the inference library. A change in any of these components creates a functionally different model and must result in a new commitment. This rigorous approach ensures the computational integrity guarantee of ZKML: every proven inference is cryptographically bound to the exact, original model specification, providing a trustless foundation for on-chain AI.

The core of inference verification is the arithmetic circuit, a computational graph where nodes are addition and multiplication gates over a finite field. Your task is to encode the model's forward pass—every matrix multiplication, activation function, and pooling operation—into this constraint system. For a simple linear layer y = Wx + b, you would create constraints that enforce the dot product and addition. Frameworks like Circom or Halo2 provide domain-specific languages to define these constraints declaratively, which are then compiled into the Rank-1 Constraint System (R1CS) or Plonkish tables required by proof systems.

Non-linear activation functions like ReLU or Sigmoid pose a significant challenge, as they are not native arithmetic operations. You must approximate them using constraint-friendly polynomials or use lookup tables. For example, a ReLU, defined as max(0, x), can be enforced by introducing an auxiliary variable y and constraints: y * (y - x) = 0 and a bit-check to ensure y is non-negative. This increases circuit size and complexity, which directly impacts proving time and cost. Efficient handling of these functions is critical for practical performance.

The circuit must also enforce the integrity of the inputs and outputs. This is done by making the model weights (W, b) and the input (x) private or public witnesses, and the output (y) a public output. The prover generates a proof that they know private witnesses which, when processed through the circuit's constraints, yield the public output. Crucially, the fixed model architecture and weights are hardcoded into the circuit logic itself, ensuring the verifier is checking the computation against a specific, agreed-upon model.

After designing the constraints, you must run a trusted setup to generate the proving and verification keys for your specific circuit. This is a one-time ceremony per circuit. Finally, you integrate the proving system into your application. A typical flow in a Solidity verifier contract involves the off-chain prover (e.g., in Node.js) generating a proof for a given input, and the on-chain verifier checking the proof against the verification key to confirm the output is correct, without learning the private input data.

We will build a circuit that proves a model correctly computed an inference without revealing the model's private weights. For this example, our model is a single neuron with a ReLU activation: y = ReLU(w1*x1 + w2*x2 + b). The prover knows the secret weights (w1, w2, b), while the verifier only knows the public inputs (x1, x2) and the claimed output (y). The circuit's job is to constrain the computation so that only the correct weights could have produced the given output from the inputs.

First, we define the circuit logic in a Circom file (model_integrity.circom). Circom uses signals to represent public inputs, private inputs, and outputs. We declare our template and its parameters. The core of the circuit is the linear combination and the ReLU constraint, which we implement by checking that the output is non-negative and that it equals the pre-activation sum when that sum is positive.

circomCopy
pragma circom 2.0.0;
template ModelIntegrity() {
    // Public inputs (known to verifier)
    signal input x1;
    signal input x2;
    signal input y_claimed;
    
    // Private inputs (known only to prover)
    signal input w1;
    signal input w2;
    signal input bias;
    
    // Internal signal for the linear combination
    signal linear;
    
    // Constraint: linear = w1*x1 + w2*x2 + bias
    linear <== w1*x1 + w2*x2 + bias;
    
    // ReLU Constraint: y_claimed must be >= 0 and equal to linear if linear >= 0.
    // We enforce this by requiring y_claimed * (y_claimed - linear) === 0.
    // This holds true only if y_claimed == 0 or y_claimed == linear.
    // An additional constraint is needed to force y_claimed >= 0.
    signal isNonNegative;
    isNonNegative <== y_claimed * y_claimed; // Square ensures non-negativity
    y_claimed * (y_claimed - linear) === 0;
}

After compiling this circuit with circom model_integrity.circom --r1cs --wasm, we generate the R1CS (Rank-1 Constraint System) and WebAssembly files needed for proof generation. We then use a trusted setup ceremony (e.g., using the snarkjs library) to generate proving and verification keys. The prover, with knowledge of w1, w2, and bias, can now generate a zk-SNARK proof that attests to the correctness of the computation for the given public x1, x2, and y_claimed.

The final step is verification. The verifier receives only the proof and the public signals (x1, x2, y_claimed). By running the verification algorithm with the public verification key, they can be cryptographically convinced that some set of private weights exist that satisfy the model's equation, without learning anything about the weights themselves. This pattern can be scaled to larger models by composing circuits or using libraries like circomlib for more complex operations.

This basic example illustrates the core workflow: 1) Define computational constraints in Circom, 2) Compile to an arithmetic circuit, 3) Perform a trusted setup, 4) Generate a proof with private inputs, and 5) Verify with public inputs. For production use, you would need to address challenges like quantizing model parameters to finite field elements and efficiently implementing operations like fixed-point arithmetic and non-linearities within the circuit constraints.

On-chain verification is the process of submitting a zero-knowledge proof (ZKP) to a smart contract for validation. The contract contains the verification key for your specific circuit, generated during the trusted setup. When you call its verify function with a proof and public inputs, it executes the verification algorithm on-chain. A successful verification returns true, confirming the computation (e.g., a model inference) was performed correctly according to the constraints defined in your circuit, without revealing the private inputs. This creates a cryptographic guarantee of model integrity that is transparent and immutable.

To implement this, you first need to compile your circuit into a format the blockchain can understand. Using a framework like Circom with snarkjs, you generate Solidity code for the verifier contract. For example, after compiling circuit.circom and performing a trusted setup, you run snarkjs zkey export solidityverifier circuit_final.zkey verifier.sol. This creates a Verifier contract you can deploy to networks like Ethereum, Polygon, or any EVM-compatible chain. The contract's gas cost is determined by the complexity of your verification key.

Integration involves your application backend generating a proof off-chain and then submitting a transaction to the verifier contract. A typical flow in JavaScript with Ethers.js looks like this:

javascriptCopy
// 1. Generate proof off-chain (using snarkjs)
const { proof, publicSignals } = await snarkjs.groth16.fullProve(
  input, "circuit.wasm", "circuit_final.zkey"
);
// 2. Format proof for the contract
const calldata = await snarkjs.groth16.exportSolidityCallData(proof, publicSignals);
const argv = JSON.parse("[" + calldata + "]");
// 3. Send transaction
const verified = await verifierContract.verify(argv[0], argv[1]);
console.log("Verification result:", verified); // Should be true

The publicSignals typically include the model's output hash and any public parameters, which become the on-chain attestation.

Key design considerations include gas optimization and data availability. Complex proofs can be expensive to verify on Ethereum Mainnet. Solutions include using zk-rollups like zkSync or app-chains with custom gas limits, or adopting proof aggregation with systems like Plonky2 or Nova for recursive proofs. Furthermore, while the proof is stored on-chain, the actual model weights and input data remain off-chain. You must ensure this data is available (e.g., via IPFS or a decentralized storage network) and that its hash is included as a public signal, creating a verifiable link between the on-chain proof and the off-chain assets.

Real-world use cases for on-chain ML verification are emerging. In DeFi, a lending protocol can verify a credit risk model's output before approving a loan. In content authenticity, an NFT platform can verify that a generative art model produced an image without manipulation. The AI Oracle pattern allows smart contracts to trustlessly consume predictions from off-chain models. By completing this integration, you enable applications where the correctness of an AI's decision is as cryptographically certain as the transfer of a token, unlocking new paradigms for trusted automation.

You now have a foundational understanding of the ZKP workflow for ML: serializing a model (e.g., using ONNX), generating a circuit (with tools like Circom or Halo2), and producing a proof of correct inference. The critical insight is that the proof verifies the computation was performed faithfully on the committed model parameters, without revealing them. This is a powerful primitive for scenarios like proving a proprietary model's output in a trustless marketplace or an AI oracle on a blockchain.

For a robust implementation, consider these next steps. First, optimize your circuit for performance and cost. This involves minimizing the number of constraints, which directly impacts proof generation time and on-chain verification gas fees. Techniques include using lookup tables for non-linear functions and selecting efficient field representations. Second, implement a secure and efficient model commitment scheme. Merkle trees over model parameters are common, but explore verifiable delay functions (VDFs) or vector commitments for different trust assumptions.

Finally, integrate the proving system into your application architecture. For on-chain verification, you'll need a verifier smart contract. Libraries like snarkjs can generate Solidity verifiers from your Circom circuit. For off-chain verification, you can use native verifier libraries. Remember to handle key management securely—the trusted setup's toxic waste for Groth16, or the SRS for PLONK—and plan for potential circuit updates, which may require a new setup. The ZKML community resources and documentation for frameworks like Circom are essential for continued learning.