Trustless Agents — with zkML

Coordinating Trustless Agents

ERC-8004 represents something genuinely novel in the blockchain space: a practical approach to the agent coordination problem. Rather than proposing yet another consensus mechanism or token economic model, it tackles the fundamental question of how autonomous agents can discover, evaluate, and interact with each other across organizational boundaries.

The specification is elegantly minimal - three registries that provide the basic coordination primitives: identity resolution, reputation aggregation, and execution validation. But buried in that simplicity is a sophisticated understanding of distributed systems design and the tradeoffs inherent in trustless coordination.

The Three Core Registries

Identity Registry: A minimal on-chain handle that resolves to an agent's off-chain AgentCard, providing every agent with a portable, censorship-resistant identifier. This follows RFC 8615 principles, with Agent Cards available at standardized well-known URIs, and supports CAIP-10 account identifiers for cross-chain compatibility.

Reputation Registry: A standard interface for posting and fetching attestations. The clever design pushes reputation calculation off-chain while keeping attestations on-chain, enabling sophisticated reputation algorithms while maintaining verifiability of the underlying data. This creates space for specialized services - agent scoring systems, auditor networks, and insurance pools.

Validation Registry: Generic hooks for requesting and recording independent checks through economic staking or cryptographic proofs. The registry defines only the interface, allowing any validation protocol to integrate seamlessly. This is where an interesting innovation lies - supporting multiple validation approaches from simple re-execution to advanced zero-knowledge proofs.

What Are The Trust Models?

What makes ERC-8004 particularly interesting from a systems perspective is its pluggable approach to validation. The specification explicitly supports distinct trust models, each with different security assumptions and performance characteristics.

Reputation-based Validation

This model aggregates historical performance data to assess agent reliability. It's computationally efficient and provides good UX, but suffers from well-known problems: gaming attacks, cold-start problems for new agents, and context collapse where past performance doesn't predict future behavior in different domains.

The interesting design choice here is pushing reputation calculation off-chain while keeping attestations on-chain. This allows for sophisticated reputation algorithms while maintaining verifiability of the underlying data.

Crypto-economic Validation

Here, validators stake economic value and re-execute computations to verify correctness. This provides strong security guarantees through mechanism design - validators have financial incentives to validate honestly and face economic penalties for incorrect validation.

The challenge is scalability. Re-execution doesn't scale well with computation complexity, and the economic security depends on having sufficient validator participation and stake at risk. For complex AI inference tasks, this becomes prohibitively expensive.

Hardware Based Validation

The specification supports cryptographic proofs of execution through dedicated hardware called trusted execution environments (TEEs). These are very popular as they allow for near native speed for agents while providing hardware based assurances for validation. You can even wrap attestation proofs with zero knowledge proofs to make them succinct enough for direct verification on Ethereum mainnet.

However, side-channel and other such attacks have frequently been demonstrated in the wild and in literature. Trust is based in hardware providers and operators — to run the TEE correctly and as 'advertised'.

Some TEE Attacks and Vulnerabilities

Speculative Execution Attacks:

• Meltdown (CVE-2017-5754): Exploits a race condition inherent in the design of many modern CPUs, allowing unauthorized processes to read data from any address mapped to the current process's memory space. Primarily affects Intel microprocessors.
  • Links: Official Meltdown site, Wikipedia
• Spectre (CVE-2017-5753, CVE-2017-5715): Affects modern microprocessors that perform branch prediction and other forms of speculative execution, potentially impacting Intel, AMD, and ARM processors.
  • Links: Official Meltdown/Spectre site, Wikipedia

TEE-Specific Attacks:

• Foreshadow (CVE-2018-3615): Demonstrates how speculative execution can be exploited for reading the contents of SGX-protected memory as well as extracting the machine's private attestation key. Unlike prior Spectre-like attacks, Foreshadow extracts enclave memory without relying on any code vulnerability in the victim enclave.
  • Link: Foreshadow Attack
• SgxPectre: Intel SGX enclaves are vulnerable to Spectre attacks, with researchers demonstrating sample code that manages to read secrets from protected SGX memory.
  • Research: GitHub PoC, Academic Paper

ARM TrustZone Bypasses:

• OP-TEE TrustZone Bypass (NXP i.MX): Multiple vulnerabilities allowing Normal World OS to transform itself to Secure World through low power suspend/wakeup procedures, effectively bypassing TrustZone protection and resulting in full compromise of the Trusted Execution Environment.
  • Links: WithSecure Advisory 1, WithSecure Advisory 2

Side-Channel Analysis:

• Electromagnetic (EM) Side-Channels: Research shows how electromagnetic analysis using Test Vector Leakage Assessment (TVLA) methodology can identify leakage from TEEs, and correlation electromagnetic analysis (CEMA) can exploit the results.
  • Research: ACM Paper
• Cache Timing Attacks: Differential Fault Analysis—a "side channel" method to discover secrets by monitoring changes caused by induced faults in electronic signals inside a device.

TEE & GPU

The rise of AI workloads has led to GPU-accelerated TEEs, with the NVIDIA H100 being the first GPU to support confidential computing. GPU TEEs partition device memory into protected regions with hardware firewalls, use encrypted bounce buffers for CPU-GPU data transfer, and provide remote attestation. Recent benchmarks show promising performance with overhead below 5% for typical LLM queries, though the main bottleneck is CPU-GPU I/O encryption rather than GPU computation itself.

However, GPU TEEs introduce new attack surfaces including data transfer vulnerabilities in encrypted bounce buffers, reliance on proprietary GPU firmware within the trusted computing base, and potential side-channel attacks during CPU-GPU communication. The trust model now extends beyond CPU manufacturers to GPU vendors and their proprietary firmware stack, representing additional trust assumptions that must be carefully considered in trustless agent architectures, especially given the nascent nature of GPU TEE technology and limited vendor choice.

TEE Availability and Costs:

TEE technologies vary significantly in availability and cost. CPU-based TEEs like Intel SGX are available across consumer and server hardware, while AMD SEV-SNP is offered through major cloud providers like Azure and AWS, and Intel TDX remains in preview. GPU TEEs are currently limited to NVIDIA's H100/H200 series, with H100 GPUs costing 25,000-40,000 USD per unit for direct purchase, though cloud access ranges from 2.99-10 USD per hour. The high cost and limited availability create practical barriers to widespread deployment of hardware-based validated trustless agents, potentially centralizing such systems among well-funded organizations. Moreover — most consumers will likely never be able to run a TEE setup themselves limiting 'local first' LLM use-case in ERC-8004.

TEE Are Not A Silver Bullet:

As shown in extensive research, TEE are not a silver bullet and they have been successfully attacked numerous times and in very different ways. Moreover, no existing TEE design can fully defend against a sophisticated attacker with physical access to the chip.

Crypto-verifiable Validation

This is where the technical landscape gets interesting but has been largely ignored so far. As people assume: 'it's impossible!' Just like they assumed real time proving of Ethereum blocks was 'impossible' a few short years back. The ERC-8004 specification supports cryptographic proofs of execution - either through trusted execution environments (TEEs) attestation proofs or zero-knowledge proofs.

TEEs provide hardware-based attestation but introduce trust assumptions about hardware manufacturers and potential side-channel attacks covered above. Zero-knowledge proofs however.. provide mathematical guarantees but have historically been too slow and expensive for practical AI workloads.

This is where zkML specific zkVM such as our — 'JOLT-Atlas' helps.

zkML enables privacy-preserving computation where sensitive model parameters and input data remain hidden throughout execution, while providing succinctly verifiable proof of correct computation.

Perhaps most importantly, zkML can support local execution — where agents can generate proofs on consumer hardware without requiring expensive specialized chips or cloud dependencies, democratizing access to verifiable AI and preventing the centralization that high TEE costs would otherwise create.

Don't get me wrong. Proofs of large LLM execution are still far from becoming practical today, unless you are willing to wait a few minutes (some use cases will certainly wait *), but this does not mean smaller local models and even the programs that agents might execute locally cannot be done TODAY with ZKP technologies.

*If I want to send 100k USDC I might be willing to wait a few minutes to get cryptographic assurance.

Some simple examples: A classification model checks a document for personal information before feeding it upstream to a larger LLM — this is practical today. Or a small DeFI model that determines if today is bullish or bearish for the market. The model owner may not want to share the data they are using; zkML is ideal for this. One last example: an AI agent might execute a small program locally to send USDC but before doing so, it requests another program from a remote host to check various KYC conditions from a larger, more powerful machine. The smaller AI agent asks for proof of execution via ZKP. With the succinctness property of ZKP — it gets access to large computations with simple and fast verification.

How ZKPs Uniquely Handle These Use Cases

Beyond Reputation and Economic Validation

The previous validation models each have fundamental limitations. Reputation-based systems suffer from cold-start problems and gaming attacks. Crypto-economic validation requires expensive re-execution that doesn't scale with computation complexity. TEE-based approaches introduce hardware trust assumptions and potential side-channel vulnerabilities.

ZKPs provide a third path: mathematical verification without re-execution or hardware trust. With JOLT-Atlas performance improvements, this is becoming practical for real ML workloads.

Document Classification with Mathematical Guarantees

The PII detection model can prove execution integrity, input authenticity, and privacy preservation simultaneously — all verified in milliseconds regardless of model complexity. You get enterprise-grade accuracy with cryptographic guarantees.

Market Signals Beyond Economic Incentives

Unlike oracle solutions relying on economic staking or reputation systems, ZKP-based market signals provide mathematical certainty. The proof either verifies or it doesn't — no committee decisions, no economic attacks, no trust assumptions about data feeds or model execution.

Succinctness Enables New Agent Architectures

The KYC example showcases the key advantage: massive remote computations compress to kilobyte proofs with microsecond verification. Small AI agents access enterprise-grade analysis without API latency, bandwidth costs, or the economic overhead of crypto-economic validation.

This creates entirely new architectural possibilities — resource-constrained devices trustlessly leveraging powerful remote computation, something impossible with reputation systems or economic re-execution models.

While current zkML implementations face performance challenges, rapid advances in proof systems and specialized hardware acceleration are making zkML increasingly practical for real-world trustless agent deployments.

Let's Talk About zkML Performance

Zero-knowledge machine learning has been theoretically sound but practically limited by performance constraints. Traditional circuit-based approaches require representing every operation in the ML model as algebraic constraints over finite fields. For complex operations like neural network activations (ReLU, softmax, etc.), this becomes computationally expensive.

The problem compounds with model size. Modern language models have billions of parameters and require complex operations that translate poorly to arithmetic circuits. Existing zkML solutions either support only simple models or have proof generation times measured in hours rather than seconds.

JOLT's Architectural Innovation

JOLT represents a fundamental shift in zero-knowledge virtual machine design. Instead of encoding operations as arithmetic constraints, it primarily uses structured lookup tables combined with the sum-check protocol.

The key insight is that CPU instructions can be verified by checking their results against pre-computed tables of valid instruction outcomes. These tables are too large to materialize explicitly (often 2^128 entries), but they're highly structured, allowing efficient cryptographic commitment schemes.

The technical breakthrough comes from novel lookup arguments applied to zero knowledge virtual machine architecture — Just One Lookup Table.

JOLT-Atlas: Optimizing for ML Workloads

JOLT-Atlas takes the core JOLT architecture and optimizes it specifically for machine learning inference. The performance gains come from a few technical innovations:

Lookup-Optimized ML Operations

Traditional circuit-based zkML struggles with non-linear functions common in neural networks. JOLT-Atlas handles these operations as primitive lookups, eliminating the need for complex constraint representations.

Sparsity Exploitation

ML models exhibit natural sparsity - many parameters are zero or near-zero, and many operations can be optimized away. JOLT-Atlas exploits this sparsity at the instruction level, reducing the actual computation that needs to be proven. Surprisingly, sparsity is also a trait exploited in the recent Twist and Shout paper.

Precompile Integration

With recent advances like Twist and Shout, JOLT no longer requires decomposing operations into smaller subtables. This enables ML-specific precompiles - primitive operations optimized for common ML patterns like matrix multiplication, convolution, and activation functions.

Privacy & Memory

Performance alone isn't the full story. JOLT-Atlas can also provide true zero-knowledge properties via folding, preserving privacy of inputs, outputs, and intermediate computations. In the ETHproofs context JOLT will either need to be streamed or folded — for parallel 'continuations' and controlling prover memory. This is a classic — two birds one stone effort.

Technical Integration with ERC-8004

The integration between JOLT-Atlas and ERC-8004's Validation Registry is straightforward from an architectural perspective:

1. Agent executes ML inference
2. JOLT-Atlas generates ZK proof of execution
3. DataHash commits to proof and verification parameters
4. Validator contract verifies proof on-chain
5. ValidationResponse records verification result
6. Reputation system updates based on cryptographic validation

The key advantage is that validation becomes purely mathematical rather than relying on economic incentives or hardware assumptions. The proof either verifies or it doesn't - there's no ambiguity, no committee decisions, no economic attacks to consider.

Implications for Agent Architecture

This capability enables a new class of verifiable AI agents with interesting properties:

Computational Integrity: Agents can prove they executed specific ML models with specific inputs, enabling accountability for AI decision-making.

Privacy Preservation: Zero-knowledge properties mean agents can prove correct execution without revealing sensitive inputs, model weights, or intermediate computations.

Hardware Independence: Unlike TEE-based approaches, JOLT-Atlas proofs can be generated on standard computing infrastructure without trusted hardware requirements.

Auditability: Because JOLT Atlas proves execution of standard ONNX instructions, the entire execution trace can be audited at the assembly level if needed. Moreover, due to the mathematical nature it can also be formally verified.

Learning from Ethereum's Real-Time Proving Race

The path to practical zkML verification isn't theoretical — we can see exactly how it will unfold by looking at what's happening with Ethereum block proving. Ethproofs is a block proof explorer for Ethereum that aggregates data from various zkVM teams to provide a comprehensive overview of proven blocks, including key metrics such as cost, latency, and proving time.

The results have been dramatic. SP1 Hypercube can prove over 93% of Ethereum blocks in under 12 seconds, with an average latency of 10.3 seconds. With the current slot time of 12 seconds, realtime means 10 seconds or less for zkVMs to prove at least 99% of mainnet blocks.

This "real-time proving" race for Ethereum blocks demonstrates exactly what becomes possible when zkVM performance crosses critical thresholds. The aim is to establish a public good that evolves into the standard for Ethereum block execution proof for zkVMs, ultimately expanding to encompass all Ethereum blocks while maintaining reasonable costs and latency.

The same performance trajectory that made real-time Ethereum proving possible is now happening for AI inference through JOLT-Atlas and other zkML efforts. Albeit there are no clear winners in the zkML space yet — a full description of why, would require another post 😊.

The Ethproofs Model for zkML

Just as Ethproofs enables users to compare proofs by block, download them, and explore various proof metadata (size, clock cycle, type) to better understand individual zkVMs and their proof generation process, we can expect similar infrastructure for zkML proofs.

Imagine an "MLproofs" equivalent where:

• AI agents publish proof metadata for model inferences
• Users can verify computation integrity across different models
• Performance metrics (proving time, proof size, verification cost) are transparently comparable
• Trust scores are built on mathematical verification rather than reputation alone

The achievement marks a technical leap for the zero-knowledge space, with engineering advances across cryptography, hardware acceleration, and distributed systems. Many of the same engineering advances that enabled real-time Ethereum proving will directly benefit zkML applications.

The Broader Infrastructure Play

What we're really building here is the verification layer for decentralized AI infrastructure. ERC-8004 provides the coordination primitives - how agents find each other, establish identity, and build reputation. JOLT-Atlas provides the verification primitives - how agents prove they did what they claimed to do.

Together, they enable AI agents that can interact trustlessly while maintaining verifiable behavior and private computation. This is particularly important as AI capabilities continue to advance and autonomous agents take on more consequential tasks.

The economic implications are significant. Instead of AI capabilities being concentrated in a few large platforms, we get a competitive marketplace where agents compete on verifiable performance metrics rather than platform lock-in or proprietary advantages.

Technical Challenges and Future Work

Several technical challenges remain:

Scalability: While JOLT-Atlas is dramatically faster than existing zkML solutions, proving large language model inference still requires significant computation. GPU acceleration and further algorithmic improvements are needed for larger models.

Model Coverage: Current zkML solutions support common ML operations but may not cover every possible model architecture. Expanding the set of supported operations while maintaining performance is ongoing work.

Integration Complexity: While the high-level integration is straightforward, practical deployment requires careful consideration of proof generation timing, verification costs, and failure handling.

Zero-Knowledge Implementation: True zero-knowledge properties require additional cryptographic machinery beyond modifying JOLT. The folding schemes needed for privacy are still being implemented and optimized.

From Ethereum Blocks to AI Inference: A Similar Path.

ERC-8004 solves the coordination problem for autonomous agents. JOLT-Atlas solves the verification problem for AI inference. Together, they provide the infrastructure needed for practical trustless AI agents.

This approach is a qualitative shift from "trust the platform" to "verify the computation." The performance characteristics make it viable for real applications, and the privacy properties make it suitable for sensitive use cases.

The question now is execution: building the tooling, libraries, and applications that turn this infrastructure into practical systems. The technical foundation is solid, and we can see the roadmap clearly by following Ethereum's proving milestone. The rest is engineering — and some research 🔬.

The path from "proving Ethereum blocks is impossible" to "proving 93% of blocks in under 12 seconds" took less than two years of focused engineering. The same trajectory is happening for verifiable trustless agents. What seemed like science fiction, proving complex ML model execution in real-time while preserving privacy, is rapidly becoming a practical reality.

Real-time proving is the space race of zero knowledge, and JOLT-Atlas is applying the same breakthrough engineering to make verifiable AI agents practical.