A blockchain node is a computer that runs a blockchain network’s client software and participates in storing, verifying and relaying data according to the protocol rules. Among blockchain fundamentals, nodes are the physical basis of a distributed ledger: the blockchain exists only as the set of copies that nodes keep and agree on.
Nodes differ in how much data they keep and which tasks they perform. A full node independently checks every block and transaction, a light node relies on others for most data, an archive node keeps every historical state, and some nodes also produce blocks as miners or validators. Together, the number and independence of nodes determine how decentralized and censorship-resistant a network really is.
What a blockchain node does
A blockchain node performs four core tasks: it connects to peers, validates incoming data, stores the chain and serves information to wallets and applications. These tasks run continuously, so a node stays synchronized with the latest block height.
When a transaction arrives, the node checks its signature, format, balance or nonce, and fees against the protocol rules. Valid transactions enter the node’s mempool and are forwarded to peers; invalid ones are dropped. When a new block arrives, the node verifies its header, its consensus proof, each transaction and the resulting state before accepting it.
The table below summarizes the core node functions and the risk each one protects against.
| Function | What the node does | Protects against |
|---|---|---|
| Peer-to-peer networking | Discovers peers, gossips transactions and blocks | Single points of failure |
| Validation | Checks every transaction and block against the rules | Invalid spending and rule changes |
| Storage | Keeps the chain and current state | Loss of history |
| Serving data | Answers queries over RPC interfaces | Dependence on third-party providers |
| Block production | Mines or proposes blocks, if configured | Concentrated control of ordering |
Types of blockchain nodes
Node types are distinguished by how much of the chain they store and how much they verify themselves. The terms differ slightly between networks, but the categories below are used across most public blockchains.
| Node type | Data kept | Verification | Typical user |
|---|---|---|---|
| Full node | All blocks, current state | Verifies everything independently | Exchanges, developers, privacy-minded users |
| Pruned node | Recent blocks and current state | Verifies everything, discards old blocks | Users with limited disk space |
| Archive node | All blocks and every historical state | Full, plus historical queries | Block explorers, analytics firms |
| Light node | Block headers only | Relies on full nodes and proofs | Mobile and browser wallets |
| Validator or mining node | Full data plus signing keys or hardware | Full, plus block production | Stakers, miners, staking services |
A light node uses compact cryptographic proofs, typically Merkle proofs, to confirm that a transaction is included in a block without downloading the whole block. This makes it efficient, but it trusts that the headers it follows represent the valid chain.
Hardware and network requirements
Resource needs depend on the network, the node type and the client software. Requirements also grow over time as the chain grows, so operators plan for headroom rather than the current minimum.
| Node type | Storage | Memory and processor | Bandwidth |
|---|---|---|---|
| Light node | Megabytes | Phone or browser class | Low |
| Pruned node | Tens of gigabytes | Modest desktop | Moderate |
| Full node | Hundreds of gigabytes to a few terabytes | Desktop or small server | Steady, often hundreds of gigabytes monthly |
| Archive node | Several terabytes or more | Server class, fast SSD | High |
| High-throughput chain validator | Terabytes, very fast disks | Many cores, large memory | Very high |
Fast solid-state storage is the most common bottleneck, because state access during validation is random and frequent. The initial synchronization from the genesis block can take from hours to several days, which is why many clients offer snapshot or checkpoint sync.
Why running a node matters
Running a full node gives a user independent verification: the node rejects invalid blocks even if miners or validators produce them. This is how protocol rules are enforced in practice, because a rule change that nodes do not accept creates a split, as seen in hard forks and soft forks.
A node also improves privacy and reliability. A wallet connected to its own node does not reveal its addresses to a third-party service, and an application that queries its own node is not affected when a public RPC provider throttles or fails. The trade-off is operational effort: updates, monitoring, storage growth and security hardening.
From the network’s perspective, many independent nodes spread across operators, countries and hosting providers increase decentralization. Concentration of nodes in a few cloud data centers is a recognized weakness, because one provider’s outage or policy change could affect a large share of the network.
Client diversity is a related concern. When most nodes run the same client software, a single bug can make a large part of the network accept an invalid block or stop following the chain. Networks such as Ethereum deliberately maintain several independent client implementations, and operators are encouraged to choose a minority client so that no single codebase controls the outcome of consensus.
Common misconceptions about nodes
The most frequent misunderstanding is that every node mines or earns rewards. On most networks, ordinary full nodes are unpaid and exist to verify; rewards go to the nodes that produce blocks, and on proof-of-stake networks only to those with staked collateral.
- A node is not a wallet: wallets manage keys, while nodes verify and relay data, although software may combine both.
- More nodes do not raise throughput: each node repeats the same work, so capacity does not scale with node count.
- Light nodes are not full verifiers: they depend on honest full nodes for much of their security.
- Cloud nodes still need trust: a node run by a hosting provider gives the provider access to its data and keys.
The short version
A blockchain node is like one of many identical copies of a public record book, each kept by a different person who checks every new page before adding it. If someone tries to add a fake page, the other copies refuse it.
Some nodes keep the whole book, some keep only the latest chapters, and some only keep the table of contents. The key takeaway is that nodes are what make a blockchain trustworthy without a central owner.
Where it makes a difference
A cryptocurrency payment company initially relies on a public RPC provider to check incoming customer deposits. During a busy period, the provider rate-limits requests, and deposit confirmations are delayed for hours.
The company sets up two full nodes in different data centers and an archive node for historical reporting, and it points its systems at its own infrastructure with the public provider only as a backup. Deposits are now confirmed directly against blocks the company has verified itself, delays disappear, and the company no longer shares its customers’ address activity with an outside service.