ZK Proofs Beyond Rollups: Verifiable AI Inference on Ethereum
Engineering Team
What ZK Proofs Enable Beyond Scaling
Zero-knowledge proofs have been synonymous with blockchain scaling since 2021. zkSync, StarkNet, Scroll, and Polygon zkEVM use them to compress thousands of transactions into a single proof verified on Ethereum L1. But scaling is just the first application. The real power of ZK proofs is verifiable computation — the ability to prove that an arbitrary program executed correctly without re-running it.
This answer-first framing matters: ZK is not a scaling technology that happens to have other uses. ZK is a general-purpose verifiable computation technology that happened to find its first large-scale market in blockchain scaling.
In 2026, the most exciting ZK applications are not rollups. They are:
- zkML — proving that a machine learning model produced a specific output without revealing the model weights
- ZK coprocessors — running heavy computation off-chain and posting a succinct proof on-chain
- Verifiable credentials — proving identity attributes (age, citizenship, credit score) without revealing the underlying data
- MEV protection — encrypting transaction intent and proving validity without revealing details to block builders
zkML: Verifiable AI Inference
The collision of artificial intelligence and blockchain has been mostly hype until now. But zkML — applying zero-knowledge proofs to machine learning inference — solves a real problem: how do you trust that an AI model produced a specific output?
The Trust Problem
Consider a DeFi lending protocol that uses an AI model for credit scoring. The model takes a borrower’s on-chain history and returns a credit score that determines their collateral ratio. Three trust issues arise:
- Model integrity — How does the borrower know the protocol used the claimed model and not a different one that discriminates against them?
- Input integrity — How does the protocol prove it used the correct on-chain data as input, not fabricated data?
- Execution integrity — How does anyone verify the computation was done correctly?
Without ZK proofs, the answer is “trust the protocol operator.” With zkML, the answer becomes: “verify the proof.”
How zkML Works
zkML systems convert neural network inference into an arithmetic circuit, then generate a ZK proof of correct execution:
1. Model quantization: Convert floating-point weights to fixed-point
(e.g., float32 → int8 or int16)
2. Circuit compilation: Translate each neural network layer into
arithmetic constraints:
- Linear layers → matrix multiplication circuits
- ReLU activations → comparison circuits
- Softmax → lookup table circuits
3. Witness generation: Execute the model with the actual input,
recording all intermediate values
4. Proof generation: Use a proving system (Halo2, Plonky3, SP1)
to generate a succinct proof that the circuit executed correctly
5. Verification: A smart contract on Ethereum verifies the proof
in O(1) time, regardless of model size
Current Limitations and Practical Boundaries
zkML in 2026 is real but constrained:
| Model Size | Proving Time | Proof Size | Verification Gas | Practical? |
|---|---|---|---|---|
| Tiny (100K params) | 5-30 seconds | 256 bytes | ~300K gas | Yes |
| Small (1M params) | 1-5 minutes | 256 bytes | ~300K gas | Yes, for async tasks |
| Medium (10M params) | 15-60 minutes | 256 bytes | ~300K gas | Feasible with GPU provers |
| Large (100M+ params) | Hours to days | 256 bytes | ~300K gas | Research only |
| LLM-scale (1B+ params) | Impractical | — | — | Not yet |
The key insight: proof size and verification cost are constant regardless of model size. Only proving time scales with computation complexity. This means the bottleneck is the prover, not the verifier — and prover hardware (GPUs, FPGAs, ASICs) is improving rapidly.
zkML Use Cases in Production
1. On-chain credit scoring
A DeFi protocol runs a credit scoring model on a borrower’s on-chain transaction history. The zkML proof guarantees:
- The correct model was used (model hash matches the committed hash)
- The correct input data was used (Merkle proof against the state root)
- The computation was correct (ZK proof of inference)
The borrower gets a better rate without revealing their full history to the protocol operator. The protocol gets verifiable risk assessment without trusting an off-chain oracle.
2. Verifiable content moderation
A decentralized social media platform uses an AI classifier to detect harmful content. zkML proves the classifier was applied consistently to all posts — no selective censorship, no hidden bias. The proof attests: “this content was classified as harmful by model XYZ with confidence 0.95.”
3. Private machine learning
A healthcare protocol proves that a diagnostic model produced a specific result for a patient’s data — without revealing either the patient data or the model weights. Both parties’ privacy is preserved while the computation result is publicly verifiable.
ZK Coprocessors: Off-Chain Compute, On-Chain Verification
Smart contracts on Ethereum are intentionally limited in computation. Gas costs make complex logic prohibitively expensive. ZK coprocessors solve this by moving computation off-chain while keeping verification on-chain.
Architecture
+------------------+ +-------------------+ +------------------+
| Smart Contract |---->| ZK Coprocessor |---->| Proof Verifier |
| (Request) | | (Off-chain) | | (On-chain) |
+------------------+ +-------------------+ +------------------+
| 1. Emit event | | 2. Read state | | 4. Verify proof |
| with query | | 3. Execute program| | 5. Store result |
| | | Generate proof | | |
+------------------+ +-------------------+ +------------------+
The flow:
- A smart contract emits an event requesting a computation (e.g., “compute the 30-day TWAP of ETH/USDC”)
- The ZK coprocessor reads historical blockchain state and executes the computation off-chain
- The coprocessor generates a ZK proof that the computation was correct
- The proof is submitted to a verifier contract on-chain
- The result is stored on-chain and available to any smart contract
Why Not Just Use an Oracle?
Oracles (Chainlink, API3) provide off-chain data to smart contracts, but they require trusting the oracle operator. ZK coprocessors provide trustless computation:
| Property | Oracle | ZK Coprocessor |
|---|---|---|
| Trust model | Trust the operator | Trust math (verify proof) |
| Data source | External APIs | Blockchain state (verifiable) |
| Computation | Simple aggregation | Arbitrary programs |
| Cost | Per-request fee | Proof verification gas |
| Latency | Seconds | Minutes (proving time) |
| Auditability | Operator reputation | Cryptographic proof |
Leading ZK Coprocessor Projects
Axiom — the first ZK coprocessor for Ethereum, focused on historical state queries. Axiom allows smart contracts to trustlessly access any historical block header, account state, or storage slot from Ethereum’s history.
Brevis — a general-purpose ZK coprocessor that supports custom computation over blockchain data. Brevis uses a modular architecture with separate proving circuits for data access, computation, and aggregation.
Lagrange — specializes in cross-chain state proofs. Lagrange’s ZK coprocessor can prove state from multiple chains (Ethereum, Arbitrum, Base) and make it available on any target chain.
Proving System Comparison: SP1 vs RISC Zero vs Jolt
The choice of proving system determines the developer experience, performance, and security of a ZK application. Three systems have emerged as the leading general-purpose zkVMs in 2026:
SP1 (Succinct)
SP1 is a zkVM that proves the execution of arbitrary RISC-V programs. Developers write standard Rust code, compile it to RISC-V, and SP1 generates a ZK proof of correct execution.
// SP1 guest program — standard Rust code
#![no_main]
sp1_zkvm::entrypoint!(main);
pub fn main() {
// Read input from the host
let input: Vec<u8> = sp1_zkvm::io::read();
// Perform computation (e.g., credit score calculation)
let score = compute_credit_score(&input);
// Commit output (becomes part of the public proof)
sp1_zkvm::io::commit(&score);
}
fn compute_credit_score(data: &[u8]) -> u32 {
// Your business logic here — standard Rust
// No cryptographic knowledge required
42
}
RISC Zero
RISC Zero is the pioneer of the RISC-V zkVM approach. It uses a STARK-based proving system and offers the most mature tooling ecosystem.
// RISC Zero guest program
#![no_main]
risc0_zkvm::guest::entry!(main);
fn main() {
let input: MyInput = risc0_zkvm::guest::env::read();
let result = process(input);
risc0_zkvm::guest::env::commit(&result);
}
Jolt (a]16z)
Jolt uses a novel lookup-based proving approach (Lasso + Surge) that avoids the complex arithmetic circuits used by SNARKs and STARKs. This results in simpler prover implementation and competitive performance.
Comparison Table
| Feature | SP1 | RISC Zero | Jolt |
|---|---|---|---|
| ISA | RISC-V | RISC-V | RISC-V |
| Proof system | Plonky3 (STARK) | STARK + Groth16 wrapper | Lasso/Surge (sumcheck) |
| Language | Rust | Rust | Rust |
| On-chain verifier | Solidity (Groth16) | Solidity (Groth16) | Solidity (sumcheck) |
| Verification gas | ~270K | ~250K | ~300K |
| Proving speed (relative) | Fast (1x) | Medium (1.5x slower) | Fast (0.9x) |
| Recursion | Native | Native | In development |
| GPU acceleration | Yes (CUDA) | Yes (CUDA, Metal) | Yes (CUDA) |
| Precompiles | SHA256, Keccak, secp256k1 | SHA256, RSA, ed25519 | Limited |
| Maturity | Production (2025+) | Production (2024+) | Beta (2025+) |
| Notable users | Axiom, Succinct bridges | Bonsai network, zkVM apps | a16z portfolio |
Which to Choose?
- SP1 for fastest time-to-market and best developer experience. Succinct’s team iterates rapidly and the documentation is excellent.
- RISC Zero for the most battle-tested system with the widest precompile support. Best for cryptographic applications that need RSA or ed25519 verification.
- Jolt for cutting-edge performance in compute-heavy applications. The Lasso lookup approach excels at memory-intensive programs.
Practical Use Cases in 2026
Identity Verification Without Data Exposure
A ZK identity system proves “this user is over 18 and a resident of the EU” without revealing their name, birthdate, or address. The proof is generated from a government-issued digital credential (eIDAS 2.0 wallet) and verified on-chain:
Input (private): Digital identity credential
Program: Extract birthdate → compute age → check ≥ 18
Extract country → check ∈ EU member states
Output (public): Boolean (true/false)
Proof: ZK proof that the program executed correctly on the credential
This enables compliant DeFi (KYC without data collection), age-gated content access, and cross-border identity verification.
MEV Protection via Encrypted Mempools
Frontrunning and sandwich attacks extract billions from DeFi users annually. ZK proofs enable encrypted mempools where transactions are encrypted but provably valid:
- User encrypts their transaction and generates a ZK proof that: the transaction is valid (correct nonce, sufficient balance), the transaction pays sufficient gas, and the transaction does not violate protocol rules
- Block builders include the encrypted transaction based on the proof (they know it is valid but cannot read the details)
- After block commitment, the transaction is decrypted and executed
- MEV extractors cannot frontrun because they cannot see transaction details before commitment
Projects like Shutter Network and Penumbra are implementing variants of this approach.
Verifiable Random Functions for Gaming
On-chain games need provably fair randomness. A ZK-based VRF (Verifiable Random Function) generates random numbers with a proof of correctness:
- The random seed is derived from future block data (unpredictable)
- The VRF computation is proven in ZK (correct execution)
- The proof is verified on-chain (anyone can audit fairness)
This eliminates the need to trust a randomness oracle or committee.
The Road Ahead: 2026-2027
The ZK ecosystem is evolving rapidly. Key developments to watch:
- Hardware acceleration — Dedicated ZK proving ASICs from Cysic, Ingonyama, and Accseal will reduce proving costs by 100-1000x, making real-time zkML feasible for medium-sized models.
- Proof aggregation — Systems like Nebra and Aligned Layer aggregate multiple proofs into one, amortizing verification costs across hundreds of applications.
- Formal verification — Tools for formally verifying ZK circuits are maturing, critical for high-value applications like bridges and financial protocols.
- Client-side proving — Mobile devices are becoming capable of generating simple ZK proofs in-browser, enabling private credential verification without a server.
Frequently Asked Questions
What is the difference between ZK proofs and ZK rollups?
ZK rollups are one application of ZK proofs — they use ZK proofs to verify batched transaction execution for blockchain scaling. ZK proofs themselves are a general cryptographic tool for verifiable computation. This article focuses on non-rollup applications: zkML, ZK coprocessors, identity, and MEV protection.
Do I need to understand cryptography to build with ZK?
With modern zkVMs (SP1, RISC Zero, Jolt), no. You write standard Rust code, and the zkVM handles the cryptographic proof generation. Understanding ZK fundamentals helps for optimization, but it is not required for basic applications.
How much does ZK proof verification cost on Ethereum?
A Groth16 proof verification costs approximately 250-300K gas (~$0.50-1.50 at typical gas prices). STARK verification costs more (~500K-1M gas) but can be reduced via proof composition (wrapping a STARK in a Groth16). On L2s (Arbitrum, Base), verification costs are 10-100x lower.
Can ZK proofs guarantee AI safety?
No. ZK proofs guarantee computational integrity — that a program ran correctly. They do not guarantee that the program (or model) itself is safe, unbiased, or aligned with human values. zkML proves “model X produced output Y for input Z.” It does not prove “model X is fair” or “model X is safe.”
When will ZK proofs work for large language models?
Not in 2026. Current zkVMs can handle models up to ~10M parameters in reasonable time. LLMs have billions of parameters. Proving a single GPT-4 inference would take weeks with current technology. Hardware acceleration (ASICs) and algorithmic improvements may make medium-sized LLM proving feasible by 2028-2029.