Light Client

Origin: composes, a decades-old blockchain design pattern, tracing back to Bitcoin's original whitepaper. Solidus status: not-built, nothing exists yet; every current query trusts a full node directly.

A light client is software that can check facts about a blockchain, "did this transaction happen," "is this account balance real," "is this credential still valid", without downloading and re-executing the entire chain's history the way a full node does. The tradeoff it makes is trust-minimization versus resource cost: a full node verifies everything itself and trusts nothing but the protocol's rules, at the cost of storing and processing the whole chain; a light client instead verifies a small amount of cryptographic evidence, a chain of block headers, plus a Merkle proof tying a specific fact to a specific header's state root (see that entry), and gets most of the same trust guarantee for a fraction of the resources. This is what makes it possible to check blockchain facts from a phone, a browser extension, or an embedded device, without either running a full node or blindly trusting whatever server you happen to ask.

Where it comes from

The earliest version of this idea, Simplified Payment Verification, or SPV, appears in Satoshi Nakamoto's original 2008 Bitcoin whitepaper: a client that keeps only block headers, verified by their proof-of-work, and checks individual transactions against those headers via Merkle proofs rather than replaying the entire ledger. Proof-of-stake and BFT chains have since built their own equivalents that verify against validator signatures or quorum certificates instead of proof-of-work: Ethereum's post-Merge "sync committee" light-client protocol is one well-known example. None of this is a Solidus contribution; it's decades of prior blockchain engineering.

The honest state of it

Solidus has not built any of this. Every way to check something about Solidus's chain today (an account balance, a DID resolution, a credential's status, a block header) is a direct JSON-RPC call to a full node, either rpc.solidus.network or devnet-v2.solidus.network. Solidus's SDKs make that call and return the answer; they do not independently verify a header chain, check a Merkle proof against a locally-tracked state root, or do anything else that would let an application trust the answer rather than the endpoint. Querying Solidus today means trusting whichever RPC node you asked, in exactly the way a light client is designed to avoid.

This matters for anyone building on Solidus today: a wallet, a verifier integration, or an app checking credential status is currently trusting Solidus's own infrastructure to tell the truth, not cryptographically checking it. That's a real limitation, not a minor one, and it's worth stating outright rather than letting the existence of a state root and quorum certificates elsewhere in this Lexicon imply a light client has been built on top of them. It hasn't.

Check it yourself

There's nothing to check, no light-client code, library, or protocol exists to inspect. If and when one is built, this entry should be the first thing updated.

Related terms: State Root · JSON-RPC · Finality · Merkle Tree · Quorum Certificate