Skip to content
Financial Context Wiki

Light Clients

A fork-aware guide to consensus light-client bootstrap, sync committees, weak-subjectivity checkpoints, optimistic and finalized headers, execution state proofs, RPC providers, data availability and privacy.

Updated

For educational purposes only; not security or transaction advice. A light client verifies only the objects covered by its configured protocol and proofs; confirm the exact chain, fork, checkpoint, header status, provider and unverified data surfaces.

Direct answer

A light client is verification software that follows a blockchain with less local execution, state and history than a full node. A light node is a device or process running that software. On proof-of-stake Ethereum, a consensus light client bootstraps from a trusted recent finalized checkpoint and verifies fork-aware sync-committee updates to maintain optimistic and finalized headers. It does not replay every EVM transaction.

That verified consensus view is only the first trust anchor. To verify an account or contract storage value, the client must link the authenticated beacon header to the execution payload header, select its stateRoot, and verify an account or storage proof against that root. An ordinary RPC response without the required proof remains a provider assertion. Consensus signatures do not automatically prove transaction history, receipts, traces, data availability, application behavior or long-term retrieval.

How it works

  1. Pin network and trust roots: chain identity, genesis validators root and time, fork schedule and presets, current clock, client version and a recent trusted finalized weak-subjectivity checkpoint. Cross-check the checkpoint through independent authenticated sources; peer agreement cannot repair a malicious starting root.
  2. Obtain a LightClientBootstrap for the trusted block root. Verify the bootstrap header, the current sync committee and its Merkle branch, then initialize the LightClientStore. Reject a chain, fork digest, generalized index or serialization schema that does not match the configured fork.
  3. Process LightClientUpdate objects by sync-committee period. Verify slots, participation bits, BLS aggregate signature and domain, current and next committee branches, finality branch and monotonicity before rotating committees. Fork upgrades can change object fields and generalized indices, so Altair constants are not permanent universal values.
  4. Maintain separate optimistic_header and finalized_header policies. An optimistic update can provide fresher information with greater reorganization or withholding exposure; a finalized update has a stronger consensus status but can lag. Applications must select the appropriate header explicitly rather than relabeling the newest response as final.
  5. Anchor execution data. Verify the execution payload header and branch carried by the authenticated light-client header, then bind each account or storage query to that execution stateRoot, block hash and finality status. For Ethereum, eth_getProof can return an account proof and requested storage proofs; verify nodes, paths, values and nonexistence locally.
  6. Inventory every unverified surface. A balance proof does not authenticate a transaction receipt, log query, trace, call simulation, mempool, token label, oracle, blob, historical range or provider’s claim that no result was omitted. Define a proof, independent reconstruction, full-node fallback or explicit trust assumption for each required object.
  7. Operate fail-closed. Record checkpoint, fork, optimistic and finalized roots, execution block and state root, proof nodes, provider and timestamps. Enforce maximum staleness, diversify providers and network paths, protect query privacy, test eclipse and outage recovery, and use a full node or another verification system when the light-client proof surface is insufficient.

Worked examples

  • Sync-committee integer boundary. For a 512-member committee, the specification’s supermajority test is participants * 3 >= 512 * 2. With 341 participants, 341 / 512 = 66.6015625% and 1,023 < 1,024, so the test fails. With 342, 342 / 512 = 66.796875% and 1,026 >= 1,024, so it passes. This verifies the configured update rule; it is not proof that every committee member or implementation is honest.
  • Header clocks. A teaching checkpoint is at slot 10,000, an attested header is at 10,064, and its finalized header is at 10,032. At 12 seconds/slot, the attested header is 64 * 12 = 768 seconds = 12 minutes 48 seconds after the checkpoint, while finality lags the attested header by 32 * 12 = 384 seconds = 6 minutes 24 seconds. Slot timing does not guarantee network delivery or finality at a fixed wall-clock SLA.
  • Compact branch, narrow claim. In an ideal balanced tree with 2^20 leaves, a single-leaf branch has 20 sibling hashes. At 32 bytes/hash, that is 640 bytes; compared with an 8 MiB = 8,388,608 bytes object, the branch is 0.00762939453125% of the size, a reduction of 99.99237060546875%. The branch proves only its leaf-to-root relation, not availability of the other bytes.
  • Proof versus bare RPC. At a finalized execution stateRoot, a verified account proof yields 3.25 ETH, while an unproved RPC response says 3.30 ETH. The discrepancy is 0.05 ETH, and the bare response is 0.05 / 3.30 = 1.5151515152% higher. Accept the value proven under the selected root, but do not infer a later balance, receipt, historical result or token identity from that proof.

Risks

  • Configuring the wrong chain, genesis validators root, genesis time or preset.
  • Bootstrapping from a malicious, stale or nonfinal checkpoint.
  • Using one unauthenticated checkpoint source or accepting a long-range fork.
  • Local-clock drift causing wrong slots, periods, domains or staleness decisions.
  • Running an obsolete fork schedule, object schema or generalized index.
  • Failing to validate sync-committee participation, BLS signatures or domains.
  • Missing committee rotation or accepting an invalid current or next committee.
  • Treating the optimistic header as the finalized header.
  • Linking the wrong beacon header, execution payload or execution block hash.
  • Verifying an account or storage proof against the wrong stateRoot.
  • Accepting malformed trie nodes, paths, encodings or nonexistence proofs.
  • Treating an unsupported or proofless RPC method as verified.
  • Receiving stale, censored, incomplete or fabricated provider responses.
  • Eclipse, Sybil or common-control failure across apparently different providers.
  • Losing liveness when proof-serving full nodes prune or stop serving data.
  • Confusing consensus validity with execution replay or application correctness.
  • Confusing a valid proof with data availability or permanent retrievability.
  • Lacking receipts, logs, traces, bodies or history needed by the application.
  • Client implementation, dependency, binary or fork-upgrade failure.
  • Query, IP, account and transaction privacy leakage to providers or peers.

Common misconceptions

  • A light client is merely a smaller full node or a renamed remote RPC endpoint.
  • A verified sync-committee header makes every RPC response trustworthy.
  • The freshest optimistic header is equivalent to a finalized header.
  • A Merkle proof or consensus signature proves data availability and complete history.
  • Light-client use automatically provides full-node privacy, liveness and censorship resistance.

Sources

Navigation

Search the wiki...