Helios Ethereum Light Client Architecture (L1 & L2)

A maximally concise, information-dense reference for reimplementation in Zig.

Helios is a trust-minimized, stateless Ethereum light client. It verifies consensus-layer (CL) headers and execution-layer (EL) state using cryptographic proofs without storing the chain. The design consists of two tightly integrated subsystems:

• Consensus Layer: Verifies canonical chain head via sync-committee signatures (L1) or sequencer signatures (L2).
• Execution Layer: Verifies state (accounts, storage, receipts, logs) using Merkle-Patricia proofs tied to the trusted header’s state root.

The result is a local JSON-RPC server that returns only verifiably correct blockchain data.

---

1. Architecture Overview

Consensus Layer (CL)

Purpose: Trust-minimized header verification without block execution.

• Implements the beacon-chain Light Client protocol (post-Merge).
• Uses sync committees (512 rotating validators) to verify header signatures.
• Tracks chain head using aggregate BLS signatures over beacon headers.
• Stores minimal data: current/next sync committee + latest finalized checkpoint.

Execution Layer (EL)

Purpose: State verification without storing full state.

• Takes trusted execution payload header (from CL).

• Uses the header’s state root to verify:

  • account state
  • code hash
  • storage slots
  • transaction inclusion
  • receipt inclusion

• Verification via Merkle-Patricia trie proofs obtained through eth_getProof.

Outcome: All local RPC responses are verified against canonical Ethereum state.

---

2. Bootstrapping & Syncing

Weak Subjectivity Checkpoint (WSC)

Helios starts from a trusted beacon block hash (recent finalized block). Used to prevent long-range attacks inherent to PoS.

• Default checkpoint is embedded; user may override.
• Helios stores the newest finalized block on disk and promotes it to the next WSC.

Checkpoint Validation

1. Fetch beacon block by hash from consensus RPC.
2. Hash it locally; ensure it matches the WSC.
3. Extract current + next sync committees.

Fast-Forward Sync (27-hour leaps)

Sync committees rotate every 256 epochs (~27 hours).

Helios leaps through history:

1. Use next committee to verify a header in the following period.
2. Extract new current/next committee.
3. Repeat until within the current sync period.
4. Switch to real-time mode: verify every incoming header via committee signatures.

Result: Multi-week catch-up in seconds with only a few aggregate signature checks.

Finality Handling

• Consensus layer also reports finalized headers.
• Helios anchors finality by storing finalized blocks → reorg resistance.
• Never follows forks that predate the latest stored finalized checkpoint.

---

3. Execution Layer State Verification

Given a trusted header with a state root:

Account & Storage Proofs

• Query EL RPC using eth_getProof.

• RPC returns:

  • account fields
  • storage slot values
  • Merkle-Patricia proof nodes

• Helios independently rehashes the trie path → must match the known state root.

Contract Code

• Verify code hash in account proof.
• Optionally retrieve bytecode and hash it.

Receipts & Transaction Inclusion

• Header contains transactionsRoot and receiptsRoot.

• Helios can verify:

  • Transactions list matches header root.
  • Receipt included via proof (if RPC supports).

eth_call & Gas Simulation

• Helios loads required state via proofs.
• Runs local EVM (revm in Rust; Zig impl should embed minimal EVM).
• Compares output with RPC or just returns its own simulation.
• RPC cannot lie about call results because Helios re-executes them.

RPC Provider Redefined

Helios converts an untrusted RPC into a verifiable data source:

• RPC can withhold, but cannot forge data.
• Only DoS or censorship is possible.

---

4. L2 (Optimism/Base) Support

Ethereum L2s lack sync committees. Helios replaces CL logic with sequencer signature verification.

OP Stack Consensus Model

• Each L2 block is signed by the sequencer ("pre-confirmation").
• Helios verifies ECDSA signature → authenticity of header.
• Trust assumption: sequencer honest (L2 protocol provides fraud proofs on L1, not Helios).

L2 Execution Verification

Identical to L1:

• Each L2 block has a state root.
• Helios verifies account/storage via Merkle proofs from L2 RPC.

Modularity

Consensus backends are pluggable:

• Ethereum L1 → BLS sync committees
• Optimism/Base → sequencer signatures
• Future: multi-sequencer committees, BFT gadgets, zk-verified headers

Helios’s architecture abstracts header verification, so adding Linea, Arbitrum, or any EVM rollup is straightforward.

---

5. Local JSON-RPC Server

Helios exposes a fully compatible Ethereum JSON-RPC interface:

Verified:

• eth_getBalance
• eth_getTransactionCount
• eth_getCode
• eth_getStorageAt
• eth_call / eth_estimateGas (via local EVM)
• eth_getBlockByNumber/Hash (header verified)
• eth_getTransactionByHash (root check)
• eth_getTransactionReceipt (root check)

Forwarded (trust not required):

• eth_sendRawTransaction (RPC broadcasts)

Trusted Only for Availability:

• RPC must support eth_getProof.
• Consensus provider must serve correct light client updates.

Helios = local node behavior with verification guarantees.

---

6. Reorgs, Finality & Safety

L1 Reorgs

• Sync-committee majority determines canonical head.

• On reorg:

  • new majority-signed header replaces last.
  • old head discarded.

• Finality anchors prevent deep reorgs.

L2 Reorgs

• Sequencer may reorg pre-L1-publish blocks.
• Helios follows whatever the valid sequencer signs.
• Strong guarantees only after L1 inclusion (optional to check).

Weak Subjectivity Risks

• Checkpoint too old → possible long-range attack.
• Helios mitigates by auto-updating to each finalized checkpoint.

---

7. Stateless Model: Trade-offs

Pros

• Near-zero disk (only small checkpoint file)
• Near-instant sync
• Suitable for mobile, browser, embedded
• Tiny attack surface
• Fully verifiable state access

Cons / Requirements

• RPC must support proofs
• No historical state unless RPC provides it
• RPC withholding = request failure
• Cannot validate state transitions (no full block execution)
• Trusts Ethereum validator majority or L2 sequencer honesty

---

8. Lessons for Zig Reimplementation

Core Architectural Principles

• Dual modules: CL verification + EL verification.
• Stateless: No DB; verify all data on demand.
• Modular consensus backends: BLS, ECDSA, future zk proofs.
• Proof-centric execution: Always verify via Merkle proofs.
• Minimal TCB: Keep code small, deterministic, auditable.

Zig Implementation Guidance

Consensus Layer

• Implement SSZ parsing & BLS12-381 aggregate signature verification.

• Implement sync committee rotation logic.

• Structure consensus backend as interface:

  • verify_header(header, proof)
  • next_committee(header_state)
  • per-chain genesis/checkpoint parameters

Execution Layer

• Implement Merkle-Patricia trie node parsing + Keccak hashing.
• Implement minimal EVM for eth_call simulation.
• Integrate proof fetching via eth_getProof.

RPC & Networking

• Build a lightweight JSON-RPC HTTP server (Zig stdlib).

• Implement provider abstraction:

  • HttpProvider
  • future: PortalProvider

State & Finality

• Store latest finalized header hash on disk.
• Use small in-memory caches (recent header, committee, proofs).
• Implement fork-choice: always follow highest-weight verified header.

Performance & Portability

• Optimize hashing & BLS operations (SIMD, unrolled loops).
• Compile for WASM/mobile; keep binary minimal.
• Use Zig error handling for explicit verification failures.

---

Conclusion

Helios demonstrates the ideal light client architecture: stateless, cryptographically verified, modular, fast, and small.

A Zig reimplementation should mimic its structure:

• Verify consensus → verify state → expose RPC.
• Store almost nothing.
• Trust nothing that can be verified.
• Generalize header verification to any EVM chain.

This architecture yields a trust-minimized, embeddable Ethereum RPC suitable for browsers, mobile apps, rollup nodes, and cross-chain protocols.