Lesson 2 — Light clients — the gold-standard verification primitive

Question

A light client verifies a chain's state without running a full node — it tracks just enough consensus to check Merkle proofs against block headers. For bridges this is the gold standard: zero trust in a third-party validator set, just cryptography. What does a light client actually do, and what does it cost to run one in a smart contract?

Principle (minimum model)

A light client tracks a chain's consensus. For Ethereum: track the sync committee (every 256 epochs ≈ 27 hours); verify BLS signatures from 2/3 of the committee against block headers; trust no one beyond the chain's consensus itself.
State is verified by Merkle proof against the header. Header → state root → MPT proof → storage slot. The light client doesn't store state; it verifies proofs against the header it already trusts.
Helios is the reference Rust light client. Built by a16z / Paradigm. Tracks the Ethereum sync committee, verifies block headers, exposes a JSON-RPC. ~5 K lines of Rust.
On-chain light clients are expensive. BLS signature verification = ~140 K gas on Ethereum. Tracking the sync committee = a state-root update every ~27 hours. Worth it for high-value bridges; overkill for low-value transfers.
IBC light clients are the production gold standard. Cosmos chains run each other's light clients on-chain → trust-minimised cross-chain messaging at the consensus layer. Tendermint's instant finality makes this cheap.
Ethereum's post-Pectra light-client improvements. Smaller sync committees / cheaper BLS verification / single-slot finality → on-chain light clients become viable for more chains.
Counter-example: optimistic light clients. Assume the light client is correct, allow challenges for N days. Cheaper but introduces a slow withdrawal window (same shape as OP rollups).

Worked example + steps

Light clients — the gold standard verification primitive

A full Ethereum node stores ~1TB and runs ~200GB of RAM. A light client does the same job — verifying that the chain is what it claims to be — using a few megabytes and a phone-grade CPU. It downloads block headers, follows the same consensus rules a full node does, and trusts only what the protocol itself guarantees. Nothing else.

That's why every serious cross-chain bridge eventually asks: can we put a light client of the source chain inside the destination chain and verify cross-chain messages cryptographically? When the answer is yes, you've reached the trust-minimization gold standard. And the production light clients that get there are written in Rust.

1. What a light client is — and isn't

A light client can:

Verify block headers chain back to genesis
Verify a state inclusion proof (Merkle proof against state root)
Verify a transaction was included (Merkle proof against tx root)
Follow consensus (track current finalized state)

A light client cannot:

Look up arbitrary state without a proof (no full state)
Execute arbitrary transactions (no full state to execute against)
Generate state proofs (only verify them)

So a light client is a verifier of claims about chain state, not a producer. Bridges use light clients to verify claims that "transaction X happened on chain Y" — the relayer produces the claim + proof, the light client verifies.

2. The Ethereum light client protocol

Light clients on PoW Ethereum were a research toy — verifying chains-of-work cheaply enough to run in a browser didn't really work. PoS changed the economics: a fixed validator set with BLS-aggregated signatures (one short signature per block, regardless of how many validators signed) makes light-client verification cheap. The protocol lives in ethereum/consensus-specs:

Every sync committee period (~27 hours), 512 validators are randomly selected as the sync committee — a rotating subset whose only job is to sign block headers for that period
The sync committee signs every block header
Light client downloads just the sync committee membership + their signatures
Light client verifies signatures against the committee's BLS aggregated public key (BLS = a signature scheme where N signatures combine into one)

So to follow Ethereum, a light client needs:

Initial trusted checkpoint (must be obtained out-of-band, e.g., from a trusted source)
Sync committee updates every period (verifies committee rotation)
Header updates during a period (verified by current committee signatures)

That's it. ~MB per period, vs TB for full state. Verification cost is 512 BLS signature aggregation + check, ~ms.

3. Reading Helios — Rust Ethereum light client

a16z/helios is a16z's production-grade Rust light client for Ethereum. Used by wallets, indexers, bridges. ~10k lines of Rust.

The architecture:

flowchart LR
    Trusted["Trusted checkpoint<br/>(slot, blockRoot)"] --> Sync["Sync to head"]
    Sync --> Update["Sync committee<br/>updates every period"]
    Update --> Header["Header updates<br/>via current committee"]
    Header --> Verify["Verify claims<br/>(execution payloads,<br/>state proofs)"]
    RPC["RPC server"] --> Verify
    Apps["Bridge / Indexer"] --> RPC

Key files to read:

consensus/src/consensus.rs — the consensus client (verifies sync committee + headers)
execution/src/state.rs — verifies state inclusion proofs from execution layer
rpc/src/lib.rs — RPC server (so apps can query verified state)

The whole thing runs in a browser via wasm. That's the point — a wallet can verify Ethereum without trusting Infura.

🔍 Find in repo. Open Helios's consensus/src/consensus.rs. Find where the sync committee signature is verified. What BLS aggregation is happening? Trace the verification flow.

4. Light clients on Reth-based chains

For your custom L1 (Tempo, Hyperliquid, etc.) to be a bridge destination, someone needs to write a light client of your chain on the target chain.

Two approaches:

4.1 Naive light client (BFT chain)

Your L1 uses BFT consensus (e.g., HotStuff). A light client of your chain needs to:

Track validator set (and rotation events)
Verify 2f+1 signed block headers
Verify state inclusion proofs against state root

In a Solidity contract on Ethereum: ~5000 gas per header verification with BLS aggregate signature. ~$0.50 per header at 50 gwei.

This works! But you need a Solidity contract that knows your BFT rules.

4.2 ZK light client

Same flow, but the BFT verification happens inside a zkVM proof off-chain. The contract on Ethereum just verifies a ZK proof (constant cost, ~100k gas).

Production examples (in 2026):

Succinct's SP1 for Ethereum light client — proves sync committee verification
Espresso — ZK light client for shared sequencer
Polyhedra — ZK light client for various chains

ZK light clients are the endgame for bridges. Trust = math.

When throughput is high. Naive: O(N) cost where N = headers. ZK: O(1) on-chain + O(N) off-chain. ZK wins when you're verifying many headers and on-chain gas is the binding constraint.

5. The light client integration with Reth

Two roles a Reth-based chain plays in light client integration:

5.1 Reth as the source chain

Your Reth-based L1 produces blocks. To be light-client-friendly:

Your header format must include enough info to verify (state root, validator set commitment, BLS aggregate signature)
Your block production must commit to validator set changes in the header
Your state tree must be Merkle-Patricia (so you can produce state inclusion proofs)

Reth gives you all of this by default. You just need to ensure your consensus impl writes the right fields to headers.

5.2 Reth as the destination chain

Your Reth-based L1 receives messages from another chain. A bridge contract on your chain needs to verify the source chain's headers + proofs. This is where light client contracts live.

For Ethereum→Tempo: a Solidity contract on Tempo that runs Ethereum's sync committee verification. ~5000 gas per header.

Reth's EVM runs the same as mainnet, so any Solidity light client (Helios's contract, custom ones) works.

6. Practice

Browse a16z/helios — clone if you have time
Identify the file containing BLS signature verification logic
Estimate: if your L1 has 30 validators (vs Ethereum's 512), how much cheaper is light client verification?
Sketch: what header fields does your custom L1's block need to expose for light clients?

7. Reading list

Helios source — production Rust light client
Ethereum light client spec — the formal protocol
SP1 light client — ZK light client implementation

Final check: in one sentence, why is a light client of your L1 the most trust-minimized way for other chains to verify your state? If your answer doesn't reference "trust only the source chain's consensus," re-read §1.

Summary (3 lines)

A light client tracks consensus (sync committee + BLS verification) and verifies Merkle proofs against block headers. No third-party trust — cryptographic only.
Helios = reference Rust light client (~5 K lines). On-chain light clients are expensive (~140 K gas / BLS verification + sync-committee updates every 27 h) but gold-standard for high-value bridges.
IBC is the production reference (Cosmos chains run each other's light clients on-chain). Ethereum's post-Pectra path makes more on-chain light clients viable. Next lesson reads OP's standard bridge — the canonical L2 deposit/withdrawal pattern.