~/notes / node operation
Light Clients and Why They Matter More Than They Sound
Verifying a chain without downloading it. The difference between checking and asking is the difference between a wallet you trust and one you verify.
Most wallets do not verify anything. They query a server, receive an answer, and display it. If the server lies, the wallet displays the lie.
A light client is the middle option: it verifies cryptographically without storing the whole chain.
The three models
Full node. Downloads and validates everything. Complete verification, substantial storage and bandwidth.
Light client. Downloads block headers only, which are tiny. Verifies inclusion of specific transactions using Merkle proofs supplied by full nodes. It does not need to trust the node supplying the proof, because the proof is checkable against a header it holds.
Trusting client. Queries an API and believes the response. This is what almost every mobile wallet and browser extension does.
What a light client can verify
That a transaction was included in a block, that a block header is part of a valid chain, and on chains with state proofs, that an account balance was a specific value at a specific block.
That covers most of what a wallet needs.
What it cannot verify
Whether the chain it is following is the one the majority of the network is following. A light client trusts the headers it is given, and an isolated client fed a fabricated chain would accept it.
Defences exist: connecting to multiple independent sources, and on proof-of-stake chains, sync committees that let a light client check a small set of signatures rather than the whole validator set.
It also cannot see the mempool. Pending transactions require asking a node, and that answer is trusted.
Why this matters practically
When a wallet says you hold a certain balance, there are two possible bases for that claim.
Either it verified the claim cryptographically, or a server said so.
In normal conditions the difference is invisible. It matters when the server is wrong, compromised, censoring, or logging your addresses for correlation.
The privacy consequence is the one people notice least. A wallet querying a provider’s API reveals every address it holds, to that provider, continuously.
The state of it
Light client implementations for major chains exist and have improved substantially, with sync committee designs making them practical on proof-of-stake networks in particular.
Adoption in consumer wallets remains limited, because the trusting model is easier to build and users cannot tell the difference.
What to do about it
For substantial holdings, running your own node and pointing your wallet at it is the complete answer. That is the only configuration where nothing is being trusted.
For everything else, the practical middle ground is to use wallets that support connecting to a custom node, and to understand that the default configuration is a trust relationship rather than a verification one.
And for the working balance held at a venue, none of this applies: an exchange balance is a claim against a company by definition, which is a different and more honest kind of trust. Platforms that let you take custody immediately at least make the transition from one model to the other a single operation rather than a project.
# Corrections and technical nitpicks are welcome. Send them over. They get published with the fix.