AI Inference Architecture

Overview

LightChain AI is a decentralized EVM blockchain with Proof of Intelligence (PoI) that enables users to submit AI inference jobs executed by a network of independent, economically incentivized workers. The platform orchestrates job submission, worker assignment, inference execution, result delivery, verification, and payments, all with privacy by default.
The system is built on Prysm (Consensus Layer) and Geth (Execution Layer), with AI inference orchestration handled through smart contracts and off-chain services.

Core Components

Blockchain Layer

• Consensus Layer (Prysm): Provides consensus and EIP-4844 blob storage for encrypted prompts and responses
• Execution Layer (Geth): Hosts smart contracts that enforce eligibility, manage payments, and handle dispute resolution

Smart Contracts

Off-Chain Services

How It Works

1. Session Creation

A user requests a session for a specific AI model. The dispatcher selects an eligible worker based on stake, capacity, and health, then signs the recommendation. The user's frontend generates a random AES-256 session key, encrypts it for the assigned worker (and for the disputer as escrow), and creates the session on-chain in a single transaction.

2. Job Submission

The user encrypts their prompt with the session key and submits it as an EIP-4844 blob transaction, then calls submitJob() with the inference fee. The contract escrows the fee and auto-assigns the job to the session's pinned worker — no per-job dispatcher involvement is needed.

3. Inference Execution

The worker retrieves the encrypted prompt blob from the chain, decrypts it with the session key, and runs inference via Ollama. The response is encrypted and delivered to the user in real-time via WebSocket, while the on-chain completion (response blob + completeJob) happens asynchronously.

Privacy

All prompts and responses are encrypted before touching the chain. Encryption operates at the session level — a single symmetric key covers all messages within a session.

• User prompts are encrypted client-side before submission as blobs
• Worker responses are encrypted with the same session key
• On-chain observers only see ciphertext in blobs
• The relay never sees plaintext — it only forwards encrypted data

A key escrow mechanism allows the protocol's disputer to decrypt session data when needed for dispute resolution. While the disputer currently has access to session keys for verification purposes, the production system will eliminate this trust assumption by running the disputer inside a Trusted Execution Environment (TEE), ensuring that decrypted data is never exposed outside the secure enclave. The relay can observe traffic metadata (who is communicating, timing, and message sizes), though it cannot read the content. In the production system, this metadata leakage will be addressed by replacing the relay with a P2P messaging layer (libp2p) that removes centralized visibility into traffic patterns.

Verification

The platform uses a layered approach to ensure workers are running the correct models and delivering quality results:

• Canary Jobs: The protocol periodically submits test jobs with known reference answers. These are indistinguishable from real jobs and use a high similarity threshold to detect model substitution.
• User-Initiated Disputes: Users who notice low-quality responses can file a dispute by posting a bond. The disputer re-executes the inference and compares results using semantic similarity. All dispute evidence is stored on-chain for public verifiability.
• Staking & Slashing: Workers must stake LCAI to participate. Timeouts, failed disputes, and repeated offenses result in progressive slashing and eventual jailing.

Currently, there is no cryptographic proof of which model a worker is running — the canary jobs and dispute system provide economic deterrence against cheating. The production system will solve this definitively through TEE-based hardware attestation, which provides cryptographic proof of model identity and execution integrity. Additionally, ZK proofs will be used for selective cryptographic verification of high-value jobs.

Data Storage (EIP-4844 Blobs)

Encrypted prompts and responses are stored as EIP-4844 blobs, providing cost-effective on-chain data availability with a separate fee market. Since LightChain is its own L1, blob demand will initially be low, keeping storage costs minimal.

Worker Requirements

Workers must:

• Stake LCAI tokens (amount varies per model)
• Run the Worker Sidecar software alongside Ollama with whitelisted models
• Register an encryption public key on-chain
• Maintain uptime and responsiveness to avoid slashing

Job Dispatch

The job dispatcher is currently a centralized service that selects which worker serves a session. While centralized, its power is constrained by on-chain guardrails — the smart contracts enforce worker eligibility, so the dispatcher cannot assign jobs to ineligible workers. All assignment decisions are auditable via on-chain records. In the production system, the centralized dispatcher will be replaced by P2P worker discovery combined with on-chain VRF (Verifiable Random Function) selection, making worker assignment fully decentralized and tamper-proof.

Roadmap: Production Evolution

The current architecture is designed as a foundation with a clean migration path to a production system featuring protocol-level Proof of Inference: Smart contract interfaces (IWorkerRegistry, IJobRegistry) are designed to remain stable through this migration, ensuring existing integrations and tooling continue to work seamlessly.