Running a full node means storing and verifying every transaction a network has ever processed. Light clients avoid that cost by verifying headers and asking for proofs about the specific data they need.
A header summarizes a block
Each block header contains a reference to the previous block, a timestamp, consensus data and a cryptographic commitment to the transactions the block contains.
The commitment is a root value computed from all the transactions, so any change to any transaction changes the root and invalidates the header.
Headers are small, typically a few hundred bytes, while the blocks they describe can be several orders of magnitude larger.
The chain of headers carries the work
Downloading only headers still lets a client verify the consensus rules that link blocks together, because those rules operate on header contents.
On proof-of-work networks the client can confirm that each header meets the difficulty target and that the chain accumulates work, identifying the heaviest chain without seeing a single transaction.
On proof-of-stake networks the equivalent check involves validator signatures, requiring the client to track the validator set as it changes across epochs.
Inclusion proofs answer specific questions
To confirm a particular transaction is in a block, the client requests a proof: the small set of intermediate hashes needed to recompute the root from that transaction.
If the recomputed root matches the header the client already trusts, the transaction must have been in the block. A false proof cannot produce a matching root.
The proof grows only logarithmically with block size, so verification stays cheap even as blocks become large.
What light clients cannot check
A header proves what was included, not whether the included data was valid. A block containing an invalid state transition still has a well-formed header.
Full nodes catch that by re-executing every transaction. Light clients do not execute anything and therefore rely on full nodes rejecting invalid blocks.
They also cannot detect omission. A server can truthfully answer every question asked while declining to mention transactions the client did not know to ask about.
Why the tradeoff is usually accepted
Light client design assumes at least one honest, well-connected peer will supply correct headers, an assumption that holds while the network has many independent full nodes.
This is why full node participation matters even to users who never run one, since the light client security model depends on those nodes existing.
Newer approaches narrow the gap using succinct proofs of validity, allowing a client to verify that state transitions were correct without executing them.