Join our community of builders on Discord!

AIVM Execution Layer (AI EL) Architecture

1. Overview

This diagram focuses on the AI Worker's internal execution flow within the Trusted Execution Environment (TEE), highlighting the privacy-preserving inference and attestation generation.
LCAI AIVM Data Flow
LCAI AIVM Data Flow

2. AIVM EL Definition

The AIVM Execution Layer is the compute layer that performs privacy-preserving AI inference inside trusted hardware. It is responsible for deterministic execution, objective commitment creation, and generation of TEE attestations that can be verified by validators. AIVM EL responsibilities
  • Decrypt user prompts inside TEE enclaves
  • Execute model inference
  • Produce objective commitments and TEE attestations
  • Encrypt responses for users and, when needed, committee verifiers
  • Emit inference commitments for batching and settlement

3. Core Components

3.1 AI Worker Nodes (AIVM EL)

AI worker nodes execute inference inside TEEs and generate verifiable proofs.
  • Minimum stake: 100,000 LCAI
  • Hardware: NVIDIA H100 GPU with Confidential Computing enabled
  • TEE: NVIDIA CC + Intel TDX for CPU-level attestation
  • Responsibilities: query execution, attestation generation, ZK proof generation (when selected)
  • Rewards: 60% of inference fees (see 60/20/20 distribution) (Suject to community Governance)

3.2 Registries and Attestation Audit

  • NodeRegistry: registers workers with secp256k1 key and TEE remote attestation quote
  • ModelRegistry: maps model IDs to valid MR_ENCLAVE hashes and model commitments
  • Attestation audit: on-chain verifier validates the hardware signature and confirms the node runs a certified, untampered execution environment

4. AIVM Execution Flow (High Level)

4.1 Task Initiation and Worker Selection

  • User submits prompt via Web UI
  • Gateway verifies session and credits
  • Orchestrator selects a worker from NodeRegistry using stake-weighted sampling and availability scoring
  • Client retrieves worker TEE public key from on-chain registry
  • Client encrypts prompt end-to-end with HPKE and sends to worker

4.2 TEE Execution and Objective Commitment

Within the TEE enclave, the worker performs:
  1. Decrypt the query packet
  2. Load model weights from secure memory
  3. Execute inference: r = F_theta(q)
  4. Capture execution trace for potential verification
  5. Encrypt response for the user
  6. Generate TEE attestation quote
Objective Commitment O = H(model_commitment || detConfigHash || H(q) || H(r) || metadata) The TEE attestation binds
CodeHTML
to
CodeHTML
to prove correct code and model execution.

4.3 Provisional Acceptance Interface

  • AI worker sends encrypted response + attestation to the gateway
  • Committee (N=6, K=4) verifies attestation and signs ReceiptRoot for provisional acceptance
  • User receives response in ~500ms; this is not payment-final

5. TEE Attestation Structure

The attestation quote includes:
  • MR_ENCLAVE: hash of enclave binary
  • H(q): SHA-256 hash of input query
  • H(r): SHA-256 hash of output response
  • nonce: replay protection
  • timestamp: inference execution time
  • sigma_TEE: ECDSA signature from TEE hardware key
The quote binds the objective commitment and proves the enclave identity.

6. Response Encryption and Payload Construction

The AIVM EL uses hybrid encryption to ensure confidentiality, integrity, and context binding. Cryptographic primitives
  • DHKEM (X25519) for key encapsulation
  • HKDF-SHA256 for key derivation
  • AES-GCM-256 for authenticated encryption
  • SHA-256 for commitments
Encryption flow
  1. Generate per-inference symmetric key K_r and nonce
  2. Construct AAD binding: chain_id || task_id || worker_id || lease_id || session_id || model_id || detConfigHash || lease_expiry
  3. Encrypt response: C_response = AES-GCM-256(K_r, nonce, r, aad)
  4. Generate one ephemeral key pair (eph_sk, eph_pk)
  5. Wrap K_r for user using X25519 + HKDF + AES-GCM
  6. Wrap K_r for committee validators (N=6) using same eph_sk
  7. Compute H_q = SHA-256(q), H_r = SHA-256(r)
  8. Generate TEE attestation over objective commitment
  9. Assemble payload: nonce, C_response, eph_pk, wrapped keys, attestation, H_q, H_r, task_id, worker_id, timestamp, AAD context
Decryption
  • User derives shared secret from eph_pk, unwraps K_r, decrypts response, verifies H_r
  • Committee members can decrypt only for disputes/spot-checks

7. Model Weights Binding

Model weights are verified and bound to attestations as follows:
  1. Weights stored on IPFS and pinned via Filecoin
  2. IPFS CID registered in ModelRegistry
  3. Worker loads weights into TEE secure memory
  4. TEE computes model_commitment = H(model_weights)
  5. Worker registers {MR_ENCLAVE, model_commitment} on-chain during onboarding
  6. Any inference attestation is verified against registry entries

8. Data Availability Interface (AI EL to CL)

Inference commitments are batched and published via native blobs. From the AI EL perspective:
  • Per-inference payload includes task_id, worker_id, timestamp, H(q), H(r), sigma_TEE, encrypted response, and wrapped keys
  • Batcher aggregates commitments every 12 seconds or 100 inferences
  • Blob transactions carry encrypted batches; blobs are not stored in EVM state

9. Hardware Requirements (AI Worker)

  • GPU: NVIDIA H100 80GB HBM3 (Confidential Computing enabled)
  • CPU: AMD EPYC or Intel Xeon with TDX support
  • RAM: 512GB ECC DDR5
  • Storage: 2TB NVMe SSD (model weights + execution traces)
  • Network: 10 Gbps dedicated connection

10. Security Properties (AIVM EL)

  • Privacy: prompt decrypted only inside TEE
  • Verifiability: objective commitment and TEE attestation prove correct execution
  • Integrity: AES-GCM tags and context binding
  • Replay prevention: nonce and timestamp
  • Model integrity: MR_ENCLAVE + model_commitment binding
--- End of Document ---