"How Do You Prove That an AI Computed Correctly?" — An Introduction to Neural Networks over Finite Fields

A Lab Coffee Break Guide to ZKML, FHE, and On-Chain AI

One Friday afternoon, three students dropped by the lab of Professor Lilu, a researcher working on neural networks over finite fields.

Yuki (high school junior; loves coding; math up to modular arithmetic)
Kaito (college sophomore; has taken linear algebra and intro to groups/rings/fields)
Rin (first-year master's student; studying algebraic geometry and computational complexity)

On the table: coffee and cheesecake. Professor Lilu picks up a whiteboard marker.

Episode 1 — "Did That AI Actually Compute Things Correctly?"

Prof. Lilu: First question — have you all used ChatGPT?

Yuki: Of course! I use it every day.

Prof. Lilu: Okay, so when ChatGPT gives you an answer, how do you verify it was actually computed by GPT-4?

Yuki: Um… you just have to trust OpenAI, right?

Prof. Lilu: Exactly. The entire AI world right now runs on "just trust us." But that breaks down in three situations.

First. Say a bank's AI rejects your loan application. They tell you "the AI decided." But did that AI actually run properly? Did someone swap out the result halfway through? From the outside, you can't tell. Regulations like the EU AI Act are starting to demand that this be verifiable.

Second. A company wants to prove "our AI has $99$% accuracy" — but the model weights are trade secrets they can't reveal. Meanwhile, users want to submit medical data to an AI but don't want it leaked. You need to prove correctness while keeping secrets. That's a contradiction — or is it?

Third. Deepfakes. Imagine if cameras could issue a "digital birth certificate" the moment a photo is taken, mathematically guaranteeing it came from a specific device at a specific time and was never tampered with. That would be the ultimate weapon against AI-generated fakes.

Kaito: All three of those boil down to "proving that a computation was done correctly."

Prof. Lilu: Exactly. And there's a technology that does this mathematically. It's called ZKML and FHE, and at the core of both is the same math: running neural networks over finite fields.

Yuki: Finite fields?

Prof. Lilu: Let's take it step by step. Starting with neural networks.

Episode 2 — Neural Networks Are Just Addition and Multiplication

Prof. Lilu: Yuki, do you know what a neural network actually does?

Yuki: Something about neurons connected like a brain that learns…?

Prof. Lilu: The name suggests that, but the reality is simpler. One neuron does this:

output = w × x + b

Multiply input $x$ by weight $w$, add bias $b$. That's a linear equation. A neural network is just thousands of these stacked in layers.

Yuki: Wait, that's it?

Prof. Lilu: That's it. A neural network is a massive pile of additions and multiplications. But there's one troublemaker: the ReLU activation function.

Kaito: $max(0, x)$, right? Zero if negative, pass-through if positive.

Prof. Lilu: Right. It involves a comparison — "is $x$ positive or negative?" Addition and multiplication are fine, but this comparison becomes a bomb later.

Rin: Because finite fields have no ordering.

Prof. Lilu: Exactly. Let's talk about finite fields.

Episode 3 — Finite Fields: The Surprisingly Powerful "World of Remainders"

Prof. Lilu: Yuki, can you compute "remainder when divided by 7"?

Yuki: Sure. $10 ÷ 7$ has remainder $3$.

Prof. Lilu: Now let's build a world where "remainder mod $7$" is all that exists. The numbers are just $0, 1, 2, 3, 4, 5, 6$.

3 + 5 = 8 → 8 mod 7 = 1
3 × 4 = 12 → 12 mod 7 = 5

Yuki: Okay, addition and multiplication work normally.

Prof. Lilu: Here's the amazing part — division works too. Want to divide by $5$ ? Find its inverse. $5 × 3 = 15$ → $15$ $mod$ $7 = 1$. So the inverse of $5$ is $3$.

Yuki: Whoa, you can divide in a world of integers!

Prof. Lilu: When you take remainders mod a prime p, you get addition, subtraction, multiplication, and division — all of them. This is called a finite field $F_p$.

Kaito: $Z/pZ$. By Fermat's little theorem, every nonzero element has a multiplicative inverse.

Prof. Lilu: And in cryptography, $p$ is enormous. For the BN254 elliptic curve, $p$ is roughly $2^{254}$ — a $77$-digit prime number.

Rin: And we run the entire neural network over this massive finite field.

Prof. Lilu: Right. And here's where the problem hits.

Yuki: The ReLU thing?

Prof. Lilu: Bingo. In a finite field, asking "is $5$ positive or negative?" is meaningless. Because mod $7, 5$ is the same as $-2$. The distinction between positive and negative simply doesn't exist.

Kaito: So ReLU's "zero out negatives" can't be written directly. Bit decomposition to extract the sign bit requires $O(log$ $p)$ constraints — about $254$ constraints per ReLU with BN254…

Prof. Lilu: That's the ReLU problem. Three solutions exist. First, replace ReLU with a polynomial like $x^2$ — works with just multiplications. Second, bit decomposition — heavy but reliable. Third, lookup tables — precompute "if input is this, ReLU output is that." The 2024 zkLLM paper's tlookup is an advanced version of this, handling LLM Softmax and more with no asymptotic overhead.

Episode 4 — Quantization: Bringing Decimals into Finite Fields

Yuki: But wait. Normal neural networks compute with decimals, right? Finite fields only have integers. How does that work?

Prof. Lilu: Great question. The answer is quantization.

Say a weight is $0.75$. Multiply by 1000 and you get $750$ — an integer. Scale everything by the same factor, and the whole network runs on integer arithmetic.

Yuki: Oh, that's the same thing smartphones do for fast AI!

Prof. Lilu: Exactly! Converting $32$-bit floats to $8$-bit integers. The finite field version just targets a $254$-bit field element instead.

Kaito: Multiplications double the scale each time, so you need requantization — multiplying by $(2^s)^{-1}$ $mod$ $p$…

Prof. Lilu: Right, and managing rounding errors is nontrivial. EZKL automates this range analysis. Also, in 2024 it was proven that even under fixed-point arithmetic, ReLU, Sigmoid, and GELU maintain universal approximation — so quantization doesn't fundamentally break the network's expressive power.

Episode 5 — What Is a Zero-Knowledge Proof? Magic That Proves Correctness Without Showing Anything

Yuki: Okay, I understand that neural networks can run over finite fields. But how does that connect to "proof"?

Prof. Lilu: Let's get to the heart of it. Zero-knowledge proofs.

Yuki, imagine this. You want to prove to a teacher that you know the answer to a test — but without showing your answer sheet. Normally, impossible, right?

Yuki: If I say the answer, I've shown it…

Prof. Lilu: But in the math world, this is possible. Here's how it works.

The teacher gives you a random challenge — a question that only someone who knows the answer could solve. You solve it. Once might be luck. But 100 times in a row?

Yuki: At that point you'd have to conclude "this person really knows the answer."

Prof. Lilu: And the teacher never once heard the actual answer. That's a zero-knowledge proof — proving correctness without revealing content.

In ZKML it works like this:

AI company (prover): "I fed input x into model $M$ and got output $y$."
User (verifier): "Prove it."
AI company: Hands over a mathematical proof $π$ — without revealing model or data
User: Verifies $π$ in milliseconds → OK!

Yuki: What does $π$ actually look like? A file? Numbers?

Prof. Lilu: Great question. For a SNARK, the proof $π$ is 2-3 points on an elliptic curve — about $192$ bytes total. It fits in a single tweet.

Yuki: Only $192$ bytes?! The neural network computation has millions of multiplications!

Prof. Lilu: That's the SNARK magic. Millions of constraints get compressed into just a few elliptic curve points. The verifier does a few pairing operations on those points and it's done — verification in milliseconds.

For STARKs, the proof is larger — tens to hundreds of kilobytes. It's mostly hash values and Merkle tree paths. No elliptic curves, so it's quantum-resistant, but the proof is bigger.

Kaito: So the proof contains either elliptic curve points or hash sequences — neither of which includes the original data or model.

Prof. Lilu: Exactly. You can't reconstruct the input data or model weights from $π$. That's what "zero-knowledge" means.

Episode 6 — Where Do the Random Values Come In?

Yuki: You mentioned "random challenges" earlier. Is the proof full of random numbers?

Prof. Lilu: Good catch. Random values play two roles.

First, when creating the proof. The prover mixes in random values called blinding factors. Without these, it wouldn't be zero-knowledge. By adding meaningless random terms to the polynomial, you prevent anyone from guessing the original data from the polynomial's shape.

Second, when verifying the proof. The verifier (or a hash function via the Fiat-Shamir transform) generates a random challenge r. The prover evaluates the polynomial at r and sends back the result.

Yuki: But why does it have to be random?

Prof. Lilu: This is the key insight. Here's the mechanism in a nutshell.

The entire neural network computation gets converted into one giant polynomial equation: "If the computation was done correctly, polynomial $H(x)$ should be zero at every point."

The verifier picks a random point r and asks: "Is $H(r)$ zero?"

If the prover cheated, $H(x)$ isn't really zero everywhere. The probability that a nonzero polynomial happens to be zero at a randomly chosen point is at most $d/p$ (where $d$ is the degree and $p$ is the field size), by the Schwartz-Zippel lemma.

Yuki: Oh! That's why it HAS to be random! If the prover knew $r$ in advance, they could craft a fake polynomial that's zero only at that point.

Prof. Lilu: Perfect. Randomness is what makes cheating impossible.

One more important thing: the proof π handed to the verifier does NOT contain the random values themselves. It contains only the "responses" — polynomial evaluations and elliptic curve points. You can't reverse-engineer the challenge r from the responses, and you certainly can't recover the original data or model.

Kaito: In the non-interactive case, the Fiat-Shamir transform derives the challenge from a hash function. Since the prover can't predict the hash output, you get security equivalent to a random oracle.

Prof. Lilu: Exactly. To summarize:

The prover mixes in "random blinders" → guarantees zero-knowledge
The verifier issues "random challenges" → guarantees cheating is caught
Only "responses" (elliptic curve points or hash sequences) are handed over → data and model stay secret

Episode 7 — "Why 99.999…% and Not 100%?"

Yuki: Something's been bugging me. Is a zero-knowledge proof not "100% correct"?

Prof. Lilu: Great question. This is where a lot of people get confused.

The math world has two kinds of "proof."

The first is mathematical theorem proving (formal proof).

Yuki: What's theorem proving?

Prof. Lilu: You know those "prove that…" problems in math class? Like "prove the angles of a triangle sum to $180°$." You use nothing but logical rules, step by step, to reach a conclusion that's absolutely certain. No "probably" or "approximately." $100$%.

Computers can do this too, using tools called theorem provers — Coq, ACL2, Lean, and others. They can mathematically guarantee, with $100$% certainty, that a program works according to its specification. Zero probability of error.

Yuki: Huh, you can prove a program is correct with math!

Prof. Lilu: Right. And formal proofs are used to verify "does this ZK circuit have bugs?" In fact, a 2024 study found that about 96% of circuit-level bugs in SNARK systems were "missing constraints" — exactly the kind of thing formal proofs can catch beforehand.

The second is zero-knowledge proofs (cryptographic proofs). These prove "a specific computation was executed correctly" but with an astronomically tiny — but nonzero — probability that a fake proof could slip through. This is called the soundness error.

Yuki: Why can't it be 100%?

Prof. Lilu: It connects to what we just discussed. Whether a fake proof passes comes down to "does a polynomial happen to be zero at a randomly chosen point?" By the Schwartz-Zippel lemma, for a degree-d polynomial over a field of size p, that probability is at most $d/p$.

With BN254, $p ≈ 2^{254}$, and d is at most a few million depending on network size. So the probability of a fake passing is:

10^6 / 10^77 ≈ 10^{-71}

Kaito: Ten to the minus 71… The number of atoms in the observable universe is around $10^{80}$, so this is incomprehensibly smaller.

Prof. Lilu: Right. Practically the same as $100$%, but theoretically not exactly zero — hence "$99.999$…%."

Yuki: So the two types of proof have different roles.

Prof. Lilu: Exactly. Formal proofs guarantee the circuit design has no bugs — $100$%. Zero-knowledge proofs guarantee the circuit was actually executed correctly — $99.999$…%. Two layers of security.

Yuki: Can formal proofs be done on encrypted data?

Prof. Lilu: Formal proofs target program code — the circuit definition — not data. The circuit blueprint is usually public, so encryption isn't needed. One proof covers the design forever. Meanwhile, zero-knowledge proofs are generated per inference — the prover computes on plaintext locally, and only the proof π reaches the verifier.

Rin: So formal proofs are "one-time offline design verification," and zero-knowledge proofs are "per-execution online proof generation."

Prof. Lilu: Couldn't have said it better.

Episode 8 — Why Does Running on a Finite Field Prove "No Tampering With the Specified Model"?

Yuki: This is the part I understand least. Why does running a neural network over a finite field prove that "this specific model computed correctly from start to finish with no tampering"?

Prof. Lilu: Alright, this is the main event. Let me walk through it.

The neural network computation is additions and multiplications. Written over F_p, these become a huge set of polynomial equations.

For example, "$z = x × y$" becomes the constraint "$z - x·y = 0$." The whole network produces hundreds of thousands to millions of constraints.

Yuki: Okay…

Prof. Lilu: And what the zero-knowledge proof does is prove:

"I know a set of values (called a witness) that simultaneously satisfies ALL of these constraints"

— without revealing the witness.

The witness includes the model weights, input data, all intermediate values, and the output. If all constraints are satisfied, it means the correct model processed the correct data through the correct computation.

Kaito: If even one constraint fails, the proof can't be constructed.

Prof. Lilu: Right. Tamper with a single value anywhere, and the constraint at that point breaks, and the entire proof falls apart.

Yuki: What about someone swapping in a different model?

Prof. Lilu: You publish a hash (commitment) of the model weights in advance. The proof includes a constraint saying "the weights I used match this commitment." Swap the model, and the commitment won't match — proof fails.

Rin: That's the binding property of polynomial commitments like KZG.

Prof. Lilu: Exactly. Putting it all together:

Convert the network computation into polynomial constraints over a finite field
A correct computation's witness satisfies all constraints
A tampered computation violates constraints → proof can't be created
The verifier checks via random challenges that the polynomial is indeed zero
Probability of a fake passing: $d/p ≈ 10^{-71}$
Model swapping is prevented by commitments

That's why finite-field neural network computation can mathematically guarantee that a specified model computed correctly without tampering.

Episode 9 — What Is Fully Homomorphic Encryption? Computing on Encrypted Data

Yuki: I think I'm getting ZKML now. But what's this "FHE" that keeps coming up?

Prof. Lilu: FHE stands for Fully Homomorphic Encryption. It's a different technology from ZKML, but shares the same mathematical foundation.

Yuki, imagine this. You have medical test results. You want an AI to diagnose them, but you don't want anyone else to see the data.

Yuki: If I upload to the cloud, the AI company can see everything, right?

Prof. Lilu: Normally, yes. But with FHE:

You encrypt your data and send it to the AI company
The AI company runs the neural network on the encrypted data
An encrypted result comes back to you
You decrypt the result with your secret key

The AI company never saw your data. Not once.

Yuki: Wait, you can compute on encrypted data?!

Prof. Lilu: You can. That's what makes FHE special.

Yuki: But how do you add or multiply encrypted numbers?

Prof. Lilu: Great question. With normal encryption, adding two ciphertexts gives you garbage. But FHE is a specially designed encryption scheme where addition and multiplication of ciphertexts correspond to addition and multiplication of the underlying plaintexts.

Think of it as computing inside a locked box. You can't open the box, but specific operations from the outside cause the numbers inside to get added or multiplied. Only the key holder can open the box and see the result.

Kaito: Mathematically, CKKS operates over a cyclotomic polynomial ring. "Encrypted addition" is ciphertext addition, "encrypted multiplication" is ciphertext multiplication.

Prof. Lilu: Right. And FHE can handle the linear parts of neural networks — matrix multiplications, bias additions — on encrypted data. The challenge is nonlinear functions like ReLU. CKKS approximates them with polynomials (Chebyshev, etc.), while TFHE/CGGI uses programmable bootstrapping for arbitrary lookup-style evaluation.

Yuki: What's the difference between FHE and ZKML?

Prof. Lilu: Great question. They protect different things.

FHE: Protects data privacy. The computing party can't see the data.
ZKML: Proves computation correctness. A third party can verify the computation was done right.

Ideally you want both — private data AND verified computation. That's why FHE + ZKP hybrids are being researched: compute on encrypted data with FHE, prove correctness with ZKP.

Rin: Like Chimera's CGGI/CKKS/BFV scheme switching.

Prof. Lilu: Exactly. Still at the research stage, but very promising.

Yuki: Does FHE also run neural networks on something like finite fields?

Prof. Lilu: Sharp question. CKKS operates on a "quotient of a polynomial ring," but applying the Chinese Remainder Theorem (CRT) maps each slot to an element of F_p. So fundamentally, it's parallel computation over finite fields. "Neural networks over finite fields" is the shared mathematical foundation of both ZKML and FHE.

Episode 10 — How Long Does This Actually Take?

Yuki: So in practice, how long does all this take? Can it work in real time?

Prof. Lilu: Honestly, it's still heavy. But improving fast. Here are concrete numbers.

ZKML (ZK proofs of AI inference):

Task	Proof generation	Verification
Small model (image classification)	~2.5 seconds	Sub-millisecond
Medium (recommender systems)	Minutes to tens of minutes	A few seconds
GPT-2 (distilled)	~1 hour	A few seconds
LLaMA-2-13B	~13 min/prompt	Under 0.006 sec

Yuki: Verification is insanely fast!

Prof. Lilu: That's the fundamental asymmetry of ZKP. "Proof generation is heavy, but verification is instant." AWS spends an hour generating the proof on GPUs, and your phone verifies it in 50 milliseconds. That model works.

FHE (encrypted inference):

Task	Inference time
MNIST (small NN, GPU-accelerated)	0.04 sec/image
CIFAR-10 classification	~47-2000 sec/image
ResNet-110	~3.6 hours/image
BERT-base (Transformer)	~18 min/inference

Kaito: FHE gets brutal with deep networks because bootstrapping dominates — 75-84% of total time.

Prof. Lilu: Right. But GPU acceleration is pushing MNIST down to 0.04 seconds. Bottom line: real-time chat AI isn't feasible yet, but loan approvals, medical diagnostics, and audits — batch processing scenarios — are very much practical. Expect 5-10x speedups from GPU optimization by 2026, with distributed proving on top of that.

Episode 11 — Who's Actually Using This? Products and Services

Yuki: Are there real services using this technology?

Prof. Lilu: Several.

Worldcoin (now World). The eyeball-scanning orb. They run a biometric identity system called "World ID" combining iris scanning with ZK proofs. The process of generating an iris code is protected by ZK proofs — proving "this person is a unique human" while preserving privacy. Around 33 million World App users, of which about 15 million are Orb-verified (as of September 2025). One of the largest real-world ZKML deployments.

EZKL (Zkonduit). An open-source library that converts PyTorch models (via ONNX) into Halo2-based ZK-SNARKs automatically. Security-audited by Trail of Bits. Used across DeFi credit scoring to game AI. Being adopted for BitTensor's consensus mechanism.

Modulus Labs. On-chain AI verification infrastructure. Demonstrated on-chain verification for 18-million-parameter models. Built "RockyBot," an AI trading bot where strategies are ZK-proven. Partnerships with Ion Protocol and Lyra Finance.

Giza. Verifiable ML model execution on StarkNet. Built Yearn Finance v3's risk assessment engine with ZKML.

Zama. Provides "Concrete ML," an FHE library for developer-friendly encrypted inference.

Yuki: Worldcoin is that eye-scanning thing! I didn't know it was ZKML.

Prof. Lilu: Spectral uses EZKL for Web3 credit scoring, AI Arena uses zkML in its game economy. VCs like a16z and Polychain are making major investments in Modulus Labs, Worldcoin, and Ingonyama (ZKP hardware accelerators). One estimate projects 90 billion ZK proofs needed for Web3 alone by 2030 — a $10 billion market.

Episode 12 — A Brief History: From "Impossible" to "Practical" in 8 Years

Kaito: When did this field start?

Prof. Lilu: Surprisingly recently.

2017. SecureML (Mohassel & Zhang) pointed the way to "cryptographic ML privacy." MPC-based, not ZKP.

2020. Zhang et al. formally defined "proving NN inference with ZKPs." vCNN published.

2021. zkCNN, ZEN, and Mystique arrived in rapid succession. zkCNN specialized the GKR protocol for convolutions — a landmark paper.

2022. Worldcoin organized the ZKML community. EZKL established the practical workflow: "PyTorch → ONNX → ZK proof."

2024. Kang et al. at EuroSys demonstrated ZK-SNARKs for Twitter(X)'s recommendation model and distilled GPT-2. zkLLM (CCS 2024) proposed specialized protocols for LLM attention mechanisms.

2025. DeepProve-1 generated the first ZK proof of a full GPT-2 inference. Called "the Hello World of verifiable generative AI."

Rin: DeepProve's GKR approach is 50-150x faster than EZKL. TeleSparse (PETS 2025) introduces ZK-friendly model design via neural teleportation. zkPyTorch is targeting LLaMA-3 compatibility.

Prof. Lilu: Eight years from theory to practice. And still accelerating.

Episode 13 — What's Next

Prof. Lilu: To close, here's where things are headed.

For Yuki: Blockchain-verified AI inference is almost here. Encrypted medical diagnosis. Cameras issuing ZK certificates against deepfakes.

For Kaito: ZK-friendly model design (polynomial activations, neural teleportation). Recursive proofs (IVC, Nova folding) for layer-by-layer proving. Maturing FHE compilers (Concrete, HEaaN, SEAL).

For Rin: LLM-scale ZKP needs streaming proofs (2026) and distributed proving. Verifiable training remains wide open — SGD randomness is the fundamental barrier. AG codes for STARK efficiency. Lattice-based SNARKs and hash-based STARKs for post-quantum security. Automated formal-verification-to-ZKP pipelines.

Closing

Prof. Lilu: Tie it all together and here's what you get.

"Running neural networks over finite fields" — this seemingly bizarre problem turns out to be the solution to the most pressing challenges in AI: trustworthiness, privacy, and verifiability.

When a bank's AI makes a loan decision, its correctness can be cryptographically proven. Companies can prove model performance while keeping weights secret. Cameras can issue digital birth certificates at the moment of capture to fight deepfakes.

The math behind it — finite fields, polynomial theory, elliptic curves, algebraic geometry, computational complexity — is beautiful, and astonishingly practical.

Yuki: "World of remainders" didn't click at first, but now I see how powerful it is.

Kaito: Algebra, cryptography, and AI all connected — this is incredible.

Rin: I might write my thesis on AG code applications to STARKs.

Prof. Lilu: Go for it. This field has beautiful math and real-world impact. It'll be one of the most important topics at the intersection of AI and cryptography for the next decade.

Now — anyone want another slice of cheesecake?

References

Mohassel, P. & Zhang, Y. (2017). "SecureML." IEEE S&P.
Liu, T., Xie, X. & Zhang, Y. (2021). "zkCNN." CCS.
Feng, B. et al. (2021). "ZEN." Cryptology ePrint.
Coglio, A. et al. (2023). "Formal Verification of Zero-Knowledge Circuits."
Kang, D. et al. (2024). "ZKML." EuroSys.
Sun, H., Li, J. & Zhang, H. (2024). "zkLLM." CCS.
South, T. et al. (2024). "Verifiable evaluations of ML models using zkSNARKs." arXiv.
Lagrange Labs. (2025). "DeepProve-1."
Maheri, M. et al. (2025). "TeleSparse." PETS.
Peng, Z. et al. (2025). "Survey of ZKP Based Verifiable ML." arXiv.
Hong, C. (2025). "FHE-based privacy-preserving ML." Security and Safety.
Ebel, A. et al. (2025). "Orion: FHE for Deep Learning." arXiv.