Light Client Protocol

Light clients download and validate only block headers—approximately 80 bytes per block—rather than full blocks containing all transactions. This reduces storage requirements from hundreds of gigabytes to mere megabytes. The client verifies the proof-of-work or proof-of-stake consensus on each header, establishing a trusted chain of block identifiers without processing any transaction data. For Ethereum's beacon chain, this means syncing roughly 10 KB per day versus 100+ GB for a full archival node.

In proof-of-stake networks like Ethereum, light clients leverage a rotating sync committee—a fixed-size group of 512 validators randomly selected every 256 epochs (~27 hours). The light client downloads the current sync committee's aggregated BLS signature and verifies it against the known validator set. This enables the client to authenticate block headers without verifying the full validator set's signatures individually. The security assumption is that at least 2/3 of the sync committee remains honest during its tenure.

To verify specific state or transaction inclusion, light clients request Merkle proofs from full nodes. A Merkle proof is a logarithmic-sized path of sibling hashes from a leaf node to the Merkle root stored in the block header. The light client recomputes the root hash locally and compares it against the trusted header. This allows verification of account balances, contract storage, or transaction receipts with O(log n) data complexity rather than O(n). A proof for a single account in a tree of millions requires only ~15-20 hashes.

Light clients can be secured by two proof paradigms: fraud proofs (optimistic) and validity proofs (ZK-based). With fraud proofs, light clients accept blocks as valid unless a challenge period elapses during which full nodes can submit proof of invalidity. With validity proofs, every state transition is accompanied by a zero-knowledge proof that the light client verifies in constant time. ZK-rollups like StarkNet and zkSync use validity proofs, enabling light clients to achieve full security with minimal computation.

A critical component of modern light client design is data availability sampling (DAS). Rather than downloading an entire block to verify all data was published, the light client randomly samples small chunks of the block data using erasure coding. If enough samples are successfully retrieved, the client gains high probabilistic confidence that the full block data is available for full nodes to reconstruct. This technique underpins Ethereum's danksharding roadmap and Celestia's modular blockchain architecture.

The canonical light client protocol introduced in the Altair hard fork (October 2021). Relies on a sync committee of 512 validators that rotates every 27 hours. Light clients download only beacon block headers and verify sync committee signatures to confirm finality.

• Verification: BLS signature aggregation from 2/3 of sync committee
• Data requirement: ~100 KB per epoch vs. multi-gigabyte full chain
• Trust model: Follows the majority of validators, inheriting full PoS security
• Implementation: Lodestar, Nimbus, and Helios clients support this protocol

The light client protocol native to the Cosmos SDK ecosystem, defined in the Interchain Standards (ICS-002). Uses a sequential header verification model where each block header contains a commit from 2/3+ of the validator set.

• Fork detection: Compares headers from multiple peers to detect equivocation
• Trusting period: A security parameter defining how long a validator set can be trusted without re-verification
• Bisection algorithm: Efficiently finds the minimal set of headers needed to verify a distant block
• IBC integration: Powers cross-chain light client verification in the Inter-Blockchain Communication protocol

A radically different approach where the entire blockchain state is compressed into a constant-size (~22 KB) zk-SNARK proof. Every Mina node operates as a light client by default, verifying a single recursive proof rather than any chain history.

• Recursive composition: Each block proof attests to the validity of all previous blocks
• Verification cost: O(1) time regardless of chain length
• Trust model: Relies on the underlying Kimchi proof system with no trusted setup ceremony
• Implication: Enables full-node security on smartphones and browsers without any chain sync

A data availability-focused light client that verifies that block data has been published without downloading it. Uses Kate-Zaverucha-Goldberg (KZG) polynomial commitments and data availability sampling to probabilistically confirm data availability.

• Sampling: Requests random chunks of the block and verifies them against the KZG commitment
• Security: High probability of detecting missing data with minimal sampling
• Erasure coding: Data is 2D Reed-Solomon encoded so any 50% of chunks can reconstruct the full block
• Role: Critical infrastructure for sovereign rollups and validiums requiring off-chain data availability