Light Client

Overview

A light client maintains enough authenticated information to verify particular aspects of blockchain state without operating a full node. Depending on the protocol, it may follow proof-of-work headers, verify validator signatures, check finalized checkpoints, or validate Merkle proofs.

Security assumptions vary. Some clients verify consensus transitions directly, while simplified wallets ask servers for transaction data and gain privacy or trust dependencies. Long-range attacks, weak subjectivity, eclipse attacks, and stale checkpoints require protocol-specific defenses. Applications should identify exactly what the client verifies, where data comes from, and how forks or validator changes are handled. A valid inclusion proof is meaningful only against a trusted canonical header. High-value payment services should use independent peers, fresh checkpoints, and fallback full-node verification where practical.

Implementations of Light Client should fix hash functions or algebraic parameters, encodings, ordering rules, domain separation, proof format, and verifier configuration. Reviewed libraries and published test vectors are essential because malformed inputs, non-canonical values, or version mismatch can invalidate the result. Failed verification, stale roots, verifier updates, and unsupported versions need explicit handling rather than automatic acceptance or parameter substitution. Operational use of Light Client should record the proof or format version, statement identifier, public inputs, trusted root or verifier, result, and relevant block or application context. Light Client should be evaluated by identifying the exact statement being proved, the trusted commitment or root, the prover or proof source, the verifier, public inputs, witness data when applicable, and the security parameters. The proof label alone does not establish soundness, privacy, or suitability for a particular application.