What a node does, and why running one matters
A full node checks every rule itself; light clients, archive nodes and hosted endpoints each trade part of that checking for convenience.
A node is a program that holds a copy of the rules and applies them to everything it is told. That is the entire definition, and it is the reason a network of strangers can operate without an authority: a node that checks for itself cannot be lied to about the ledger, only ignored. The different node types on offer trade away portions of that checking in exchange for lower cost, and knowing which portion is being traded is the practical skill.
What verification means in practice
When a node receives a block, it re-executes the work rather than accepting a summary. It confirms that the block references the previous one correctly, that every included transaction carries a valid digital signature, that no coin is spent twice against its own copy of the state, that resource limits are respected, and that the block satisfies the consensus rule — sufficient work, or attestations from the right validators. Only then does it extend its chain and relay the block onward.
The commitments that make this efficient come from a Merkle tree, which compresses a set of transactions into a single root fingerprint such that any individual member can be proven present with a short path rather than the whole set. This is what allows a lightweight client to verify membership without holding everything, and it is the structure underneath most proofs exchanged between chains and layers.
The practical value of doing this personally is narrower and more concrete than the slogans suggest. A full node cannot be told that units exist which the rules never created, cannot be shown a payment that was not actually included, and does not have to ask anyone whether a transaction confirmed. It also improves privacy, because a node that holds the whole chain never has to reveal which addresses it cares about. What it does not do is protect against losing a key, against a badly written contract, or against a counterparty failing, which are different categories of risk handled elsewhere.
The node menu
| Type | What it stores | What it verifies | What it trusts |
|---|---|---|---|
| Full node, pruned | Current state and recent blocks | Every rule, for every block it processes | Nothing beyond its own software |
| Archive node | Every historical state, at every height | Every rule, and can reconstruct any past balance | Nothing beyond its own software |
| Light client | Block headers and requested proofs | Membership and header validity | That honest peers exist to supply data |
| Wallet on a hosted endpoint | Keys only | Nothing about the chain | The provider's answers entirely |
A pruned full node is the standard configuration and is far less demanding than most people assume, because keeping every historical state is what makes archive nodes large. Archive nodes exist mainly for analytics, block explorers and indexers, which need to answer questions about the past rather than about now. A light client downloads headers and asks peers for proofs of the specific facts it needs, which is a genuine security model rather than a trust-me arrangement, though a weaker one than full validation.
The layer where trust quietly returns
Most wallets and most applications do not run any of this. They send queries to a remote endpoint operated by a service company, which runs the node on their behalf. The convenience is real and so is the re-imported trust: such a provider can report a balance that does not exist, omit transactions, go offline at the worst moment, decline to relay a particular transaction, and record which addresses are queried together from which network address, which is a meaningful privacy leak even for a chain whose data is public.
None of this lets a provider spend anyone's coins, because spending needs the private key and self-custody means holding it. The exposure is to being misinformed and to being excluded, not to theft. It is also a concentration story: a handful of endpoint providers serve a large share of application traffic on major networks, which is a form of centralization risk that does not appear in any consensus-layer statistic.
Client diversity, which is a different problem
Independent teams write independent implementations of the same protocol. That redundancy is protective — a bug in one implementation is usually caught by the others rejecting its blocks — but only when no single implementation dominates. If a supermajority of the network runs one client and that client accepts an invalid block, the invalid chain can gain a majority and the minority correct nodes are the ones that appear to be forked off. Under proof of stake there is a sharper version: a client bug causing mass equivocation can lead to correlated slashing across every validator running it.
This is why node client diversity is tracked separately from node count, and why client concentration appears in serious risk assessments. A network with many nodes all running the same code has one point of failure wearing a large number of hats.
What it costs and why the number matters
Chain size is the headline cost and it grows monotonically with usage; bandwidth for relaying blocks and transactions is the recurring one; initial sync time is the friction that discourages people most. These costs are also a design constraint with a political edge: raising throughput generally raises the resources required to validate, which reduces the population able to run a node independently, which shifts the network toward the hosted-endpoint model described above. That trade-off sits underneath most long-running debates about block size and throughput on any chain.
Node count is the corresponding measurement, and it should be read as an estimate. Reachable nodes can be counted by crawling; nodes behind firewalls cannot, so published figures are lower bounds with methodology attached. A rising count indicates broader independent verification, not necessarily broader use.
The next lesson covers who decides what those nodes are running. Compare node counts and chain sizes across networks on the comparison tool, and read data sources for how these counts are collected.