Crypto
4 min read

Full Node

A computer running blockchain software that downloads and independently verifies every block and transaction. Full nodes enforce consensus rules and form the backbone of a decentralized network.

What a full node does

A full node:

  1. Downloads the entire blockchain from peers.
  2. Validates every transaction and every block independently.
  3. Maintains the current state — every account balance, every contract state.
  4. Forwards valid transactions and blocks to other peers.
  5. Rejects anything that violates protocol rules.

The cost: significant disk space, bandwidth, and CPU. A Bitcoin full node requires ~600 GB and growing; an Ethereum full node (without archive history) requires ~1 TB.

Why full nodes matter

Full nodes are the backbone of a blockchain's decentralization:

  • Independent verification. Each full node enforces the rules without trusting anyone else. The collective set of full nodes is what defines what the chain "is."
  • Censorship resistance. A network with thousands of independent full nodes is hard for any party to censor or capture.
  • Don't trust, verify. The crypto-native principle is that you don't trust an intermediary's claim about the chain — you can verify yourself by running a node.

Without full nodes, the blockchain would just be a small set of operators producing blocks that other parties trust without verification.

Full node vs. validator

Two related but different roles:

  • Full node — verifies the chain. Doesn't necessarily produce blocks or earn rewards.
  • Validator (or miner) — actively produces or attests to blocks. Earns rewards but has more obligations and resource requirements.

Every validator runs a full node, but most full nodes aren't validators. Many users run full nodes purely for verification — running their own wallet against their own node, rather than trusting a third-party RPC service.

The node operator landscape

Bitcoin currently has ~15,000-20,000 reachable full nodes; Ethereum has ~5,000-10,000. The ranges depend on counting methodology and aren't always consistent across sources.

The numbers have implications:

  • Healthy for the chain's decentralization despite the visible concentration of mining/validation in fewer hands. Block production and verification are different functions.
  • Concentrated infrastructure layer. Most full nodes run on Hetzner, AWS, or other cloud providers. Geographic and provider diversity is real but limited.

Light nodes and SPV

Not every participant runs a full node. Alternatives:

  • Light node (SPV in Bitcoin) — downloads only block headers and verifies a subset of data. Trusts full nodes for most validation.
  • Mobile/browser wallets — typically don't run any node; query a remote RPC service like Alchemy or Infura for chain data.
  • Custodial wallets — the operator runs nodes; users trust the operator entirely.

The trade-off: lower-resource clients give up the "verify yourself" property in exchange for accessibility. For most users, this trade-off is acceptable; the network's overall security comes from the collective set of full-node operators, even if individual users don't run their own.

Hardware requirements

For Bitcoin:

  • ~600 GB SSD recommended (full chain).
  • 4+ GB RAM.
  • A reliable internet connection.
  • Initial sync takes a few days; ongoing operation is light.

For Ethereum:

  • 1+ TB SSD (NVMe strongly recommended for performance).
  • 8-16 GB RAM.
  • Reliable internet.
  • Initial sync can take days even with fast hardware.

For other chains, requirements vary — Solana full nodes have notoriously high requirements (multi-TB SSD, many cores, fast network) reflecting Solana's high throughput. Lower-throughput chains have correspondingly modest requirements.

Why hardware costs matter

Full-node hardware requirements affect decentralization:

  • Bitcoin's modest requirements allow even hobbyists to run nodes. The chain is decentralized partly because the bar is low.
  • Ethereum's growing storage needs have raised concerns about long-term node-running accessibility. The "stateless client" research aims to address this.
  • Solana's high requirements make running a node practical mainly for professional operators. Critics call this less decentralized than alternatives.

Different chains make different trade-offs between throughput and node-running accessibility. The choices have real consequences for who can participate as a full node.

Archive nodes vs. full nodes

A subtype:

  • Full node — current state plus enough history to verify recent activity. Older state is pruned.
  • Archive node — every historical state, going back to genesis. Useful for indexers, analytics, and historical queries. Far more expensive.

Most full nodes are pruning nodes, dropping older state to save disk space. Archive nodes are typically run by infrastructure providers, exchanges, and analytics firms.

Why running a full node is sometimes worthwhile

For most users, the answer is "you don't need to run a full node." But for some specific cases, it adds real value:

  • High-value holders — a full node lets you verify your own transactions and balances independently of any third party.
  • Privacy-conscious users — querying remote RPC services leaks information about your queries (and indirectly your wallet) to those services. A self-hosted node avoids this.
  • Developers — running a node locally for testing and development has practical benefits.
  • Decentralization advocates — running a node directly supports the network's decentralization, even if it's not strictly "necessary" for your own use.

In broader infrastructure

Full nodes are one layer in a deeper infrastructure stack:

  • Mining/validation hardware at the bottom for produced chains.
  • Full nodes for verification.
  • Indexers and analytics consuming chain data.
  • APIs and RPC services abstracting node operation.
  • Wallets and dApps consuming abstracted services.

Each layer can be more or less centralized; full-node decentralization is a key but not sole determinant of overall chain decentralization.

How to actually run one

The standard path for a Bitcoin or Ethereum full node:

  1. Get appropriate hardware (sufficient SSD, RAM, network).
  2. Download the standard client (Bitcoin Core for BTC; Geth, Nethermind, Reth, Erigon for ETH).
  3. Configure with reasonable defaults.
  4. Wait days for initial sync.
  5. Operate as a long-running background service.

Specialized tools (Umbrel, MyNode, Start9) make running a Bitcoin or Ethereum node accessible without deep technical expertise. They package the software, provide a UI, and handle most of the operational complexity.