After studying this material, you should be able to:

1. Explain why verifying AI model identity is a problem worth solving
2. Define zkSNARKs and their core properties
3. Describe how provable inference works at a system level
4. Identify real-world applications where provable inference matters
5. Evaluate the current state, limitations, and progress of the field

---

Step-by-Step Teaching

Step 1: The Core Problem — Why Can't We Trust AI Responses?

The Analogy

When you talk to a friend in person, you verify their identity through multiple senses: sight, sound, touch. When you interact with an AI model, you have almost none of these verification mechanisms.

The Specific Trust Problem

User sends prompt
        ↓
[Something processes it]  ← What is this exactly?
        ↓
User receives response

The user cannot verify whether the response came from:

• ✅ The actual claimed model (e.g., Claude 3.7)
• ❌ A cheaper substitute model (cost-cutting by a routing service)
• ❌ A tampered model (modified by an attacker)
• ❌ A more powerful unauthorized model pretending to be weaker

Why Judging Output Alone Fails

Even if the response seems high quality, that tells you nothing definitive. A cheaper model might produce similar-looking output. A tampered model might behave normally 99% of the time and maliciously 1% of the time.

Why Checking Yourself Is Impractical

You might think: "Just run the model yourself and compare." Two problems:

1. Weights are private — you don't have access to them
2. Compute is expensive — running a 400B parameter model requires massive hardware most users don't have

Key Insight: We need a way to verify model identity that is cheap for the verifier, doesn't require knowing the weights, and cannot be faked.

---

Step 2: The Solution Concept — Cryptographic Proofs

What Is a Proof in This Context?

Think of it like a certificate of authenticity, similar to how HTTPS certificates verify websites. The model provider sends, alongside each response, a short mathematical proof file that says:

"I promise that the model I committed to earlier produced exactly this output for this input."

The Four Properties That Make This Work

This is the heart of the concept. A useful proof system needs all four of these:

Why All Four Are Necessary

• Without completeness: honest providers get penalized unfairly
• Without soundness: the whole system is useless — anyone can fake it
• Without zero-knowledge: providers would never adopt this (weights are worth billions)
• Without succinctness: verification requires as much compute as running the model — no improvement

Analogy: Think of a university diploma. It proves you graduated (completeness + soundness), doesn't reveal your GPA or personal records (zero-knowledge), and can be quickly checked by an employer without re-running your entire education (succinctness).

---

Step 3: The Technical Tool — What Is a zkSNARK?

Breaking Down the Name

zkSNARK = Zero-Knowledge Succinct Non-interactive Argument of Knowledge

How It Works Conceptually (Simplified)

PROVER (has weights)                    VERIFIER (no weights)
        |                                       |
        | 1. Commits to weights                 |
        |-----> [commitment = short fingerprint]|
        |                                       |
        | 2. Runs model on prompt               |
        |                                       |
        | 3. Generates proof file               |
        |-----> [~19 MB proof] ---------------→ |
        |                                       |
        |                    4. Checks proof    |
        |                    (seconds, CPU only)|
        |                    PASS or FAIL       |

The Mathematical Foundation (Conceptual)

The zkSNARK in FlashProve is built in layers:

Hash Functions (security foundation)
        ↓
Interactive Oracle Proof (IOP) — information-theoretic layer
        ↓
Code Proximity Tests + Lookup Arguments (efficiency tools)
        ↓
zkSNARK (final cryptographic proof)

You don't need to understand each layer deeply right now. The key point is: the security rests on well-studied mathematical hardness assumptions, not on trusting the prover.

Important: This approach even offers post-quantum security — it remains secure even against future quantum computers, because it relies on hash functions rather than number-theoretic problems.

---

Step 4: The System — How FlashProve Works

Two Phases

Phase 1: Offline (One-Time Setup)

Provider runs once per model:
- Takes ~39 minutes on one H100 GPU
- Produces a "commitment" to the weights (~6.5 MB)
- This commitment is like a tamper-evident seal on the weights
- Valid for ~16 million requests
- Published publicly

Phase 2: Online (Per Request)

For each batch of 24 requests:
- Provider runs model normally (inference)
- Provider generates proof file (~18.78 MB per request)
- User downloads commitment (once) + proof (per request)
- User verifies proof in ~17 seconds on a CPU

What the Proof Actually Claims

The proof asserts this specific statement:

"The model whose weights match the published commitment, when given this exact prompt, produces exactly these output tokens."

If even one token is wrong, or the weights are different, the proof fails.

Performance Numbers in Context

Is 70–95× overhead acceptable?

That depends on the use case. For security-critical applications (regulatory compliance, tamper detection), yes. For casual chat, probably not yet. The field is improving rapidly.

---

Step 5: Real-World Applications

Application 1: Regulatory Compliance (Pacing AI Development)

Problem: A regulator wants to ensure a provider is using compute for inference, not secretly training a more powerful model.

Solution with zkSNARKs:

Regulator: "Show me proof you served these inference requests"
Provider: Submits proof files covering the period
Regulator: Verifies proofs cheaply, without needing provider's hardware
Result: Cannot fake inference without actually doing it

Application 2: Tamper Detection (Security)

Problem: An attacker compromises an inference server and substitutes a malicious model.

Solution with zkSNARKs:

Every response must come with a valid proof
Proof is bound to the committed weights
Attacker's model ≠ committed model
→ Attacker cannot produce valid proofs
→ Tampering is detected

Application 3: Text Provenance

Problem: A company claims their code was audited by a frontier AI security model. How do you verify this?

Solution with zkSNARKs:

Company provides: [audit report] + [zkSNARK proof]
Proof says: "Model X analyzed this code and produced this report"
Anyone can verify the proof cheaply
→ Cannot fake having used a frontier model

Novel example from the article: A "Proof-of-Failure" — proving that a model spent at least 1 million tokens trying to find bugs in code and found none. This is a verifiable negative result.

Application 4: Model Approval Enforcement

Problem: Regulations require only approved models to be served. Providers might cheat with cheaper/riskier unapproved models.

Solution with zkSNARKs:

Approved models have registered commitments
Every response must include proof tied to an approved commitment
Unapproved model → proof fails → violation detected

---

Step 6: Trustworthiness — Formal Verification with Lean

The Problem with Cryptographic Code

Cryptographic code is notoriously difficult to get right. A single subtle bug can break all security guarantees. How do you trust the code?

The Solution: Lean Proof Assistant

Lean is a formal verification language. It allows you to write mathematical proofs that a computer can check mechanically.

FlashProve proves three top-level properties in Lean:

Completeness theorem ← machine-checked proof
Soundness theorem    ← machine-checked proof  
Zero-knowledge theorem ← machine-checked proof

The Trust Architecture

Lean theorems (machine-verified)
        ↓
Lean verifier (slow but provably correct)
        ↓ tested against ↓
C++ verifier (fast, used in practice)

Key insight: For soundness, you only need to trust the verifier (not the prover). The Lean verifier is provably correct. The C++ verifier agrees with it on all tests. So you can trust the system without trusting the prover at all.

Remaining Trust Gaps (Honest Limitations)

The article is transparent about what formal verification does NOT cover:

1. The formal statements must be manually audited to ensure they match their intent (an interactive visualizer is provided to help)
2. The fast C++ code has no formal guarantee — it's tested but not proven
3. The prover (zero-knowledge property) cannot practically be run in Lean — requires human/agentic security audits

---

Step 7: Limitations and Current Boundaries

Understanding limitations is as important as understanding capabilities.

---

Step 8: The Bigger Picture — Progress in the Field

Historical Progress (zkML Timeline)

2017: SafetyNets — tiny CNN, proof of concept
2021: zkCNN — VGG-16 (15M params), 88 seconds/proof
2022: Kang et al. — MobileNet v2
2023: ZKML — GPT-2 (117M params), ~0.006 tokens/second
2024: zkLLM — LLaMA-2-13B, ~2.5 tokens/second
2025: FlashProve — Llama 4 Maverick (400B params), ~110 tokens/second

What This Progress Tells Us

The field has gone from tiny toy models to frontier-scale models in under a decade. The overhead has dropped from impractical to roughly 2 orders of magnitude above native inference.

Key Takeaway: The question is no longer "Is provable inference possible?" but "How fast can we make it?"

---

Summary: The Complete Mental Model

PROBLEM: Cannot verify which AI model produced a response

SOLUTION: zkSNARKs — cryptographic proof files with 4 properties:
  ├── Completeness (honest proofs pass)
  ├── Soundness (fake proofs fail)  
  ├── Zero-Knowledge (weights stay private)
  └── Succinctness (cheap to verify)

SYSTEM: FlashProve
  ├── Offline phase: commit to weights once
  └── Online phase: prove each response batch

APPLICATIONS:
  ├── Regulatory compliance / pacing
  ├── Tamper detection / security
  ├── Text provenance
  └── Model approval enforcement

TRUST: Lean formal verification of core security properties

CURRENT STATE: Research prototype
  ├── Works on 400B model at 110 tokens/second
  ├── ~70-95× overhead vs. native inference
  └── Several limitations remain (context length, floating-point, etc.)

---

Self-Check Questions

1. Why is it insufficient to judge model identity from output quality alone?
2. What would happen if a proof system had soundness but not zero-knowledge?
3. Why does the offline phase only need to run once per model?
4. In what scenario would 95× overhead be acceptable? When would it not be?
5. What is the difference between the Lean verifier and the C++ verifier, and why do both exist?
6. Why does proving soundness only require trusting the verifier, not the prover?