A blockchain node is a computer running the network's client software. It connects to other nodes, receives transactions and blocks, checks them against the protocol's rules, and passes valid data on. A full node checks everything itself and does not trust anyone else's copy of the chain. A light node checks only part of the data and relies on full nodes for the rest. Which one you run decides how much you verify yourself and how much disk, memory and bandwidth you need.
Figures below were checked against official project documentation on 25 October 2026.
Where the word comes from
In networking, a node is any connection point that can create, receive or forward data, such as a router, a server or a laptop. Blockchains use the word in the same way, with one addition: a blockchain node also enforces the network's consensus rules. Ethereum's developer documentation defines a node as "any instance of Ethereum client software that is connected to other computers", and a client as "an implementation of Ethereum that verifies data against the protocol rules".
What a full node does
Bitcoin's documentation defines a full node as "a program that fully validates transactions and blocks". Almost all full nodes also accept transactions and blocks from other nodes, check them, and relay them onward.
This is what makes a blockchain trustless in practice. If many independently run nodes reject an invalid block, no single miner or validator can push it through. A wallet connected to your own full node checks balances and payments against your own copy of the chain, not against what a third-party server reports.
The cost is resources. That cost is the main reason most users rely on someone else's node.
Node types
Full node
Downloads and validates every block. On Ethereum, full nodes do "a block-by-block validation of the blockchain", keep recent state, and can regenerate older state when needed.
Pruned node
A full node that validates everything and then deletes old block data to save disk space. In Bitcoin Core you turn this on with prune=N, where N is the number of MiB to keep. The minimum is 550, and 0 turns pruning off. bitcoin.org says pruning cuts storage "from over 750GB to around 7GB". It also says a wallet is "as secure with high values as it is with low ones". Pruning does not work with -txindex or -rescan, and it disables the importwallet RPC.
Archive node
On Ethereum, archive nodes are full nodes that "verify every block from genesis and never delete any of the downloaded data". They answer historical queries and need terabytes of storage.
Light node
Downloads block headers instead of full blocks, checks data against those headers, and asks full nodes for anything else. Light nodes cannot take part in Ethereum consensus. The idea goes back to Section 8 of the Bitcoin white paper, "Simplified Payment Verification". There a user keeps only the block headers of the longest proof-of-work chain. The paper warns that this method can be fooled for as long as an attacker can overpower the network.
Which kind of node fits what you need?
Answer up to four questions to see which node type the article's decision list points to and what it costs in storage.
Do you want staking rewards on Ethereum?
- Yes → Full node plus a validator
- No → next question
Do you need historical chain data for analytics or indexing?
Do you want to verify your own payments yourself, without trusting someone else's copy of the chain?
- Yes → next question
- No, I only check balances on a phone or small device → Light client
Is disk space tight on the machine you will use?
- Yes → Pruned full node
- No → Full node
Running a node by itself earns nothing. Solo staking on Ethereum means a full node (execution and consensus clients) plus validator software and a deposit of 32 ETH. ethereum.org recommends 8+ CPU cores and 64 GB of RAM if you are validating.
Historical queries need a full node that keeps all its data. On Ethereum that may mean an archive node, which verifies every block from genesis, never deletes downloaded data and needs terabytes of storage.
A light client downloads block headers, checks data against them and asks full nodes for the rest. It needs little hardware, but you trust the full nodes it connects to, and it cannot take part in Ethereum consensus.
A pruned node still validates everything, then deletes old block data. In Bitcoin Core set prune=N with N of at least 550 MiB; bitcoin.org says pruning cuts storage to around 7GB. A pruned Monero node is about 105 GiB today. Pruning does not work with -txindex or -rescan.
A full node checks every block and transaction itself. For Bitcoin, plan for the larger official figure: over 750 GB of storage, growing by 5 to 10 GB a month. Ethereum's minimum is a 2 TB NVMe SSD and 16 GB of RAM; a full Monero node is about 265 GiB today.
This follows the article's four-case list only: it does not check your own hardware or cover other chains, and storage figures are the projects' 25 October 2026 numbers, which grow every month.
Bitcoin nodes
- Software: Bitcoin Core. The download page lists version 31.1.
- Disk: bitcoincore.org says a full node needs a one-time download of about 600 GB, plus 5 to 10 GB per month. With pruning you can store as little as 10 GB in total. bitcoin.org gives a higher first-sync figure: about 740 GB extra download on first start, and over 750 GB of storage. The two official pages don't agree, so plan for the larger figure.
- Minimums (bitcoin.org, pruned setup): 7 GB of free disk space with at least 100 MB/s read/write speed, 2 GB of RAM, and at least 400 kilobits (50 kilobytes) per second of upload.
- Bandwidth: about 20 GB of download a month. Full nodes on fast connections commonly upload 200 GB or more a month.
Ethereum nodes
Since the switch to proof of stake, every Ethereum node runs two pieces of software:
- an execution client, which listens for transactions, executes them in the EVM and holds the current state
- a consensus client, which runs the proof-of-stake consensus algorithm. Optional validator software can be added to it.
Hardware figures from ethereum.org's "Run a node" guide:
| Minimum | Recommended | |
|---|---|---|
| CPU | 2+ cores | 4+ cores (8+ if validating) |
| RAM | 16 GB (32 GB recommended for stability) | 32 GB (64 GB if validating) |
| Storage | 2 TB NVMe SSD | 4 TB NVMe SSD (DRAM-less and QLC drives discouraged) |
| Bandwidth | 25+ Mbit/s | 50 Mbit/s down / 15+ Mbit/s up (25+ up if validating) |
Running a node does not by itself earn rewards. Solo staking means running a validator, and ethereum.org says "this requires a deposit of 32 ETH".
Monero nodes
- Software:
monerod, the Monero daemon. It manages the blockchain, while a separate wallet program manages the account. - Storage (Monero Docs): approximate current sizes are 265 GiB for a full node and 105 GiB for a pruned node. The docs advise planning for 662.5 GiB or more (full) and 262.5 GiB or more (pruned). Pruning is optional and off by default. The docs say it "saves 2/3 of disk space w/o degrading functionality but contributes less to the network".
- Ports: 18080 for peer-to-peer connections with other nodes, and 18089 for wallet RPC in the documented setup.
- Running a node and mining are separate activities: the node handles the blockchain and does not produce blocks by itself.
Choosing what to run
- You want to verify your own payments: run a full node, pruned if disk space is tight. Pruning keeps full validation.
- You need historical data for analytics or indexing: you need an unpruned full node. On Ethereum that may mean an archive node.
- You only need to check balances on a phone or a small device: a light client is enough, but you trust the full nodes it connects to.
- You want staking rewards on Ethereum: you need a full node plus a validator and the 32 ETH deposit.
Before setting up, check the current requirements on each project's own documentation. Storage needs grow every month.
Limitations: hardware and storage figures come from each project's own documentation as of 25 October 2026. They change as the chains grow, and the two official Bitcoin pages give different first-sync figures.
