⚑zkML

Securing AI/ML Inference through ZK Technology

Zero Knowledge Machine Learning (zkML)

The Vanna Network incorporates zkML technology to ensure that the inferences computed by the network are honest and correct. But what exactly is zkML?

A zero-knowledge (ZK) proof is a cryptographic protocol in which one party, the prover, can prove to another party, the verifier, that a given statement is true, without revealing any additional information beyond the fact that the statement is true.

Similarly, zero-knowledge machine learning (zkML) uses zero-knowledge proofs (ZKPs) to allow a party (the prover) to demonstrate to another party (the verifier) that a certain statement is true, without revealing any additional information. In the context of machine learning, this could mean proving that a model correctly classifies a certain input or runs an inference correctly.

Vanna Labs will be using EKZL.xyz for generating and validating zkML proofs on its network. EZKL is an open-sourced library that uses the Halo2 proof system. Using EZKL, the Vanna Network can create ZK proofs that cryptographically prove statements like:

β€œI ran this publicly available neural network on some private data and it produced this output”

or

β€œI ran my private neural network on some public data and it produced this output”

These cryptographic proofs allows Vanna to guarantee the integrity of AI/ML inference computations, and prevents nodes from computing bad inferences that could pose as security risks in the blockchain network.

So… how does this magic work? We’d highly recommend looking through ezKL’s blog as well as their docs to get a stronger technical understanding of zkML, but here’s a high-level overview.

  1. Compilation: The AI model is converted into a mathematical circuit using tools like Circom. In the context of ZK proofs, tools like Circom are commonly used to describe computations as circuits in a high-level domain-specific language.

  2. Setup Phase: A trusted party generates public parameters that will be used in the proof system, e.g. using a multi-party compute (MPC) like the Perpetual Powers of Tau. The proving keys and verifying keys for the system are also generated.

  3. Witness Generation: The actual data (witness) related to the statement is mapped into the circuit.

  4. Proof Generation: Using the proving key and the mapped witness, a prover generates a succinct proof.

  5. Proof Validation: The generated proof is made available along with the statement to verifiers. The verifiers can use the public verification key to validate a proof cheaply in constant time.

An important key factor to keep in mind is that proof generation is quite computationally expensive, but proof validation is very cheap. Because of this, it makes sense for projects like Vanna to adopt an architecture where a proof is generated once, but validated numerous times by many nodes across the network.

Last updated