Join our community of builders on Discord!

Proof of Intelligence (PoI) Consensus Layer Architecture

1. Proof of Intelligence (PoI) Consensus Layer Architecture

This diagram visualizes the flow of consensus, from validator duties and block production to the specific mechanisms of committee verification and data availability.
LCAI CL-EL Data Flow
LCAI CL-EL Data Flow

2. Proof of Intelligence (PoI) Definition

Proof of Intelligence is defined as: PoI = Objective commitment + TEE attestation proof The objective commitment binds an inference to deterministic settings and to the prompt/response hashes: O = H(model_commitment || detConfigHash || H(q) || H(r) || metadata) Where
CodeHTML
is a separate commitment to model weights, distinct from
CodeHTML
which measures the enclave binary code. The TEE attestation quote signs over
CodeHTML
and
CodeHTML
to prove the correct enclave and model executed the task.

3. Consensus Layer Roles and Components

3.1 Validator Nodes

Validators participate in PoI consensus (PoS-secured) and are responsible for block production, committee verification, protocol spot-checks, and L1 chain finality.
  • Minimum stake: 200,000 LCAI
  • Responsibilities: block proposal, attestations, state verification, protocol spot-checks, dispute evidence submission
  • Rewards: 50% of transaction/gas fees; 20% of inference fees (committee verification + spot-check work)
  • Penalties: missed spot-check duty (1% slash), downtime >24h (3% slash), double-signing (100% slash)
Validators run a PoI consensus client (CL) plus a standard geth execution layer (EL). PoI extensions live in the CL and protocol services, including TEE attestation verification and K-of-N committee signatures (K=4 of N=6 recommended). The architecture requires Engine API V3 for CL-EL integration to support blob transactions and attestation data flow.

3.2 PoI Consensus Responsibilities

The consensus layer provides:
  • L1 block production and finality (PoS consensus)
  • Verification of committee signatures for provisional inference acceptance
  • Verification routing and assignment for protocol spot-checks
  • Data availability for inference batches via native blobs
  • Enforcement of slashing for consensus and verification failures

4. L1 Finality and Fork Choice

Lightchain AI uses standard PoS finality with LMD-GHOST fork choice and a Casper-FFG style finality gadget.
  • Block time: 12 seconds
  • Slots per epoch: 32
  • Finality latency: 1-3 epochs (configurable)
Finalized L1 blocks do not revert except in catastrophic scenarios requiring social consensus. L1 chain finality is independent of inference disputes.

5. Dual Finality Model (CL Perspective)

The CL enforces L1 finality and provides data availability for inference verification. Inference correctness finality is handled by application-layer contracts, but is anchored to consensus data and timing.
  • Provisional acceptance: ~500ms committee verification (K=4 of N=6) of the TEE attestation and ReceiptRoot signature
  • Hard inference finality: after the dispute window (default 24h) with no successful spot-check failures
Key principle: Invalid inferences affect settlement state and worker economics, not L1 chain finality. Blocks remain finalized regardless of inference correctness.

6. Committee Verification (Provisional Acceptance)

For each inference batch:
  • Committee assignment uses VRF-based selection of N=6 validators
  • K=4 signatures are required to provide provisional acceptance
  • Committee verifies TEE attestation (hardware root of trust), checks
    CodeHTML
    against ModelRegistry, and validates objective commitment
    CodeHTML
This provides fast UX feedback but is not payment finality.

6. Protocol Spot-Checks

Validators perform stochastic ZK spot-checks as part of protocol security. There are no external challengers in v1.
  • One task is randomly selected per batch
  • Exactly one validator is assigned via VRF: SelectCommittee(validators, batch_id, slot, seed, 1)
  • Compute budget cap: max 3 spot-checks per validator per epoch
  • Assigned validator has a window to submit verification results
Outcomes:
  • Spot-check detects fault: worker slashed, batch marked INVALID, no chain reorg
  • Spot-check passes: batch continues toward settlement
  • Validator fails duty: 1% validator slash, no chain reorg

7. Data Availability and Blobs (Consensus Layer)

Inference commitments are batched and published via native blob transactions in the CL (inspired by EIP-4844). This eliminates external DA dependencies and enables efficient verification. Blob Architecture
  • InferenceBlobTx carries 128 KB blobs (4096 field elements x 32 bytes)
  • Max 6 blobs per block (target 3)
  • Each blob contains erasure-coded encrypted batch, KZG commitment, proof, versioned_hash (0x01 || SHA256(kzg_commitment)[1:])
  • Blobs propagate via consensus gossip, sharded across 64 subnets
Erasure Coding and DAS
  • 2D Reed-Solomon over BLS12-381 scalar field
  • Default matrix: 64x64 original expanded to 128x128 (4x redundancy)
  • Reconstruction possible from any 50% of chunks
  • Light clients perform random sampling with KZG proofs
KZG Commitments
  • Uses Ethereum KZG Ceremony parameters
  • Commitment: 48 bytes, proof: 48 bytes, verification: 2 pairings (~1.5 ms)
Retention
  • Mandatory retention: dispute window + safety margin (default 32 hours)
  • Optional warm storage: 32-90 days
  • Cold storage: 90+ days
Validators may prune blobs after the mandatory retention period but must retain on-chain versioned_hashes.

8. CL-EL Boundary

The consensus client integrates with the execution layer using Engine API V3 to support:
  • Native blob transaction propagation
  • Inclusion and verification of inference batch commitments
  • Consensus gossip for blob sidecars
Validator APIs used for blob access:
  • /eth/v1/beacon/blob_sidecars/{block_id}
  • /lightchain/v1/blob/{versioned_hash}
Assigned validators retrieve blobs, verify KZG commitments, and request key disclosure for spot-checks.

9. Staking and Slashing (Consensus-Critical)

Staking Requirements
RoleMin Stake
Validator200,000 LCAI
AI Worker100,000 LCAI
Slashing Conditions
OffenseSlash %Who
Failed ZK spot-check (fraud)Governance parameterAI Worker
Missed spot-check duty1%Validator
Validator double-signing100%Validator
Validator downtime (>24h)3%Validator
AI worker downtime (>1h)2%AI Worker

10. Consensus Parameters (CL Relevant)

ParameterValue
Block time12 seconds
Slots per epoch32
L1 finality latency1-3 epochs
Batch interval12 seconds or 100 infs
Spot-check selection1 task per batch
Validator spot-check assignmentVRF-based
Max spot-checks per validator/epoch3
Inference dispute window (T_chal)24 hours (default)
DA layerNative blobs
Max blobs per block6 (target 3)

11. Security Assumptions (CL View)

  • Rational adversary model: attackers only act if expected profit exceeds expected slashing loss
  • MR_ENCLAVE binding via PoI prevents model downgrade attacks
  • Spot-checks deter lazy execution and enforce objective commitments
  • Nonce and timestamp in attestation prevent replay
Key safety rule: Consensus safety and L1 finality are independent of inference correctness. Invalid inferences trigger economic penalties and settlement changes, not block reorgs. --- End of Document ---