At 08:12 UTC on 11 November 2020, Infura’s status page reported a problem with its Ethereum API. MetaMask, which used Infura as its default provider, ran into trouble, and Binance and Bithumb disabled ETH and ERC-20 withdrawals. Ethereum itself carried on. The fault sat in Infura’s service, and everyone looking at the chain through it lost the view.
That morning is the best short answer to the question “what is a node in blockchain”. A node is the software that checks the chain for itself. Most people holding crypto do not run one: their wallet asks somebody else’s node and believes the reply. For years that arrangement works so well that nobody notices it exists, until the day the somebody else has a bad morning.
The cause was narrow. Infura said several of its components were locked to an older version of the Geth client, which hit a consensus bug at block 11234873; Geth versions 1.9.9 and 1.9.13 were affected, 1.9.19 and later were not. The status page marks the incident resolved at 14:42 UTC, about six and a half hours after that first post. Binance, according to The Block, resumed withdrawals earlier, around 10:00 UTC.
What is a node in blockchain? Your own copy of the rulebook
The word gets stretched further than any other in crypto, so a plain definition first. A node is a computer running software that downloads a blockchain’s data, checks it against the protocol’s rules, and passes valid data on to other computers. That is all. Miners and validators are jobs added on top of that base, and a wallet app that queries a remote server is not a node at all.
The chain those nodes hold is explained in our lesson on how a blockchain works. The previous lesson of this path showed why a blockchain is so hard to rewrite: each block commits to the one before it, so changing old history means redoing the work or the stake behind everything since. That guarantee only has force if many independent machines can recompute it and reject a forgery. Those machines are the nodes.
Ask which node you use today and, for most readers, the honest reply is none. The kinds below differ in disk and bandwidth, and a plain one pays nothing, which is exactly where the sales pitches begin.
What a node does all day: validate, relay, store, serve
Validate: the node decides what counts
Bitcoin.org puts it in one line: a full node is “a program that fully validates transactions and blocks“. In practice the software takes each incoming transaction and block and asks a series of mechanical questions. Is the signature valid? Has this coin already been spent? Does the block carry the required proof of work? Is the block reward within the allowed amount? On Ethereum it also runs every transaction through the EVM and compares the resulting state with what the block claims.
A block that fails any test is thrown away, whoever produced it. This is the point most newcomers miss. A miner with an enormous share of the hash rate still cannot pay itself an extra reward, because every full node would refuse the block. The rules are enforced at the edge, by each copy of the software, with no central referee. The block format those checks read is covered in our lesson on what a block contains.
Relay and store
Once a transaction or block passes, the node tells its peers about it. Those peers run their own checks and tell theirs, so a new block crosses the network in hops. How nodes find each other and how that gossip is organised belongs to the next lesson of this path, on peer-to-peer networks.
It also keeps data: blocks, plus a working database of the current state. On Bitcoin that state is the set of unspent coins. On Ethereum it is every account balance and contract storage slot. How much history stays on disk is what separates the kinds of node described below.
Serve wallets and new nodes
Nodes answer questions. A freshly installed node downloads its history from existing ones, and bitcoin.org notes that full nodes also serve lightweight clients. On Ethereum the same job runs through a JSON-RPC interface: a wallet asks for a balance or submits a signed transaction, and the node replies. When a company runs that interface as a paid service, it is an RPC provider.
What a node does not do
- A node does not hold your coins. Coins are entries in the shared ledger, and spending them takes a private key, as our guide to private and public keys explains. Key storage is the wallet’s job (see our guide to crypto wallets).
- Mining and proposing blocks are separate jobs. On its own, the software only checks what others produce.
- Running one on Bitcoin or Ethereum earns nothing. The protocol has no reward for validating and relaying.
- Rule changes need more than one machine. An operator chooses which software to run, and that software decides what it accepts; a change spreads only if enough others adopt the same rules.
Full, pruned, archive, light: the kinds of node
The kinds differ on one axis: how much data the node keeps, and as a result how much it can check for itself.
Full node: the rules checked at home
A full node checks blocks against the protocol’s rules itself. On Bitcoin the standard configuration also keeps all of them: 780,326,253,867 bytes, about 780 GB, at block 974,241 on 2 November 2026 (Blockchair; best block time 09:52 UTC). The ledger is append-only, so that number only rises.
A pruned node shows that verifying and storing are separate things. In Bitcoin Core, the setting prune=N deletes old block files after they have been checked, keeping N MiB with a minimum of 550 MiB. Disk use drops from over 750 GB to around 7 GB, according to bitcoin.org. The node has still downloaded and checked everything once, so it enforces the same rules as an unpruned one. Bitcoincore.org puts the figure at “as little as 10GB”, “without sacrificing any security”. The trade-offs are practical. Under BIP 159 a pruned peer only guarantees the last 288 blocks, about two days, so it cannot help a newcomer download old history, and pruning does not work alongside the -txindex or -rescan options. Bitnodes’ snapshot of 2 November 2026 (09:01 UTC) shows 2,319 of its 18,526 nodes advertising limited history, the signal pruned nodes use.
Ethereum uses the words differently. Its ordinary full node is already pruned in this sense: ethereum.org says full nodes “only keep a local copy of relatively recent data (typically the most recent 128 blocks)“. So do not read “pruned” as a third kind on Ethereum. It is the normal state of a full node there. Many also start checking from a recent block they trust rather than from genesis, which is what Geth’s snap sync does.
Archive node: every past state
Ethereum.org defines archive nodes as full nodes that “verify every block from genesis and never delete any of the downloaded data“. The difference from a full node is access to every historical state, so the node can answer “what was this contract’s balance at block 12,000,000?” straight away. Few individuals need that. Block explorers, analytics firms, tax tools and researchers do.
The cost is disk. Ethereum.org’s client table, on a page last updated on 17 August 2026, lists 12 TB or more for an archive node on Geth, Nethermind or Besu, 2.5 TB or more on Erigon and 2.2 TB or more on staking means depositing a proof of stake coin with a protocol that stakes it for you and issues a transferable token (such as Lido stETH or rETH) representing the deposit plus rewards, which you can use or sell while the coins stay staked.">Reth. The spread comes from how each client stores the same data. What an archive node adds is query capacity, not a stricter check of the rules.
Light node and SPV: trust the work, check the proof
A light client keeps block headers instead of blocks. The idea is older than any wallet app: section 8 of the Bitcoin white paper, “Simplified Payment Verification”, opens with “It is possible to verify payments without running a full network node.” The client keeps the chain of headers and asks a full node for a proof that its transaction sits inside a given block. Satoshi Nakamoto estimated a header at about 80 bytes, or 4.2 MB a year. That is arithmetic from 2008, and it has held: at 974,241 blocks, 80 bytes each comes to about 78 MB. Our reading of the Bitcoin white paper puts this section in context.
The saving has a price, and the white paper states it: this method “is more vulnerable if the network is overpowered by an attacker”. A light client confirms that a transaction was included in a chain with a lot of work behind it. It does not check whether every rule was followed. And it still has to ask full nodes for its data, so it can be starved of information by the peers it reaches.
Ethereum has the same concept. Ethereum.org says light nodes “only download block headers” and that they “cannot be validators”. They verify what they receive rather than taking a server’s word for it, which already beats a plain RPC call, but they depend on full nodes existing.
The kinds side by side
| Chain and kind | What it keeps | Checks every rule itself | Disk (dated) | Typical operator |
|---|---|---|---|---|
| Bitcoin full node | Every block since 2009 | Yes | About 780 GB of chain (2 Nov 2026, Blockchair) | Hobbyists, businesses, exchanges, miners |
| Bitcoin pruned node | Recent blocks plus the coin set | Yes | Around 7 GB, after a one-time download of about 740 GB (bitcoin.org) | Home users short of disk |
| Bitcoin SPV client | Headers | No | About 78 MB (our sum, 2 Nov 2026) | Mobile wallets |
| Ethereum full node | Recent state, about 128 blocks | Yes, from the point where its sync starts | Geth or Nethermind 500 GB+, Besu 800 GB+, plus about 200 GB for the consensus client (ethereum.org, 17 Aug 2026) | Stakers, developers, businesses |
| Ethereum archive node | All historical states | Yes | 2.2 TB+ to 12 TB+ depending on client (same page) | Explorers, analytics, RPC providers |
| Ethereum light node | Headers | No | Minimal | Devices with little storage |
| Solana validator | Accounts, ledger, snapshots | Yes | Separate disks of 1 TB+, 1 TB+ and 500 GB+ (Anza docs, read 2 Nov 2026) | Data-centre operators |
Miners and validators are jobs on top of a node
Lists of node types often put miners and validators next to full nodes, which is how people end up thinking a node is a miner. They are different things. A node checks. A miner or validator also proposes blocks, and collects rewards for it. Each needs a node underneath.
Bitcoin: most nodes are not miners
A miner has to know the current tip of the chain and the valid transactions waiting, and a full node is how it finds out. On top of that it runs proof of work: hashing block candidates with specialised machines until one meets the difficulty target. The two activities are unequal in cost. A node runs on a home computer; competitive mining runs on warehouses of dedicated chips.
So the counts differ. Bitnodes listed 18,526 reachable Bitcoin nodes in its snapshot of 2 November 2026, 09:01 UTC. Each of those checks blocks, and most mine nothing. By our count of the software versions in that snapshot, 16,515 ran Bitcoin Core (about 89.1%) and 1,963 ran Bitcoin Knots (about 10.6%).
Ethereum: two clients, then a validator
Since the Merge an Ethereum node is two programs that work as a pair. The execution client (Geth, Nethermind, Besu, Erigon, Reth) holds the state and runs transactions in the EVM. The consensus client, also called the beacon node (Lighthouse, Prysm, Teku, Nimbus, Lodestar, Grandine), follows proof of stake. Neither one alone forms a working node.
A validator is a third layer: software that signs attestations and block proposals with a key backed by staked ether. Ethereum.org gives the numbers: a validator needs a minimum of 32 ETH and can hold up to 2,048 ETH. That ceiling came with EIP-7251 in the Pectra upgrade, active on mainnet on 7 May 2025 at 10:05 UTC (epoch 364032). It applies only to validators with compounding credentials, known as type 0x02. A validator on the older 0x01 credentials stays capped at an effective balance of 32 ETH, with the excess swept to its withdrawal address.
Being offline is cheap, cheating is not. Ethereum.org says a validator that misses its duties while the network is finalising normally pays small inactivity penalties, slightly less than the rewards it would have earned, and can earn them back in about the same time online. Those penalties grow when many validators are offline together.
Slashing is the harsher penalty: forced removal from the network and the loss of staked ether. Ethereum.org lists three offences, namely signing two different blocks for the same slot, attesting to two candidates for the same block, and an attestation that “surrounds” another. Its advice to home stakers is to load keys on only one machine at a time, since a backup running the same key can sign a conflicting message without anyone meaning to cheat.
Readers who want staking yield without running hardware have other routes, each with its own risks, covered in our lesson on liquid staking tokens. In the US, the IRS’s Rev. Rul. 2023-14 says “the fair market value of the validation rewards received is included in the taxpayer’s gross income” for a cash-method taxpayer, in the year the taxpayer gains dominion and control over them. Our guide to US crypto taxes covers the reporting side.
Solana: voters and RPC nodes
Solana has validators that vote and non-voting RPC nodes that answer applications. A call to Solana’s public RPC on 2 November 2026, around 09:55 UTC, returned 665 current vote accounts and 29 delinquent ones. Vote accounts are a proxy: one operator can run several, so this is not a count of independent parties. The same endpoint listed 3,900 entries in the cluster’s gossip table, 265 of them advertising an RPC port, so that figure mixes voters with non-voting machines.
Three chains, three very different hardware bills
What a node costs is a design decision of each chain. Bitcoin’s small blocks let a modest machine follow along. Ethereum sits in the middle. Solana publishes data-centre specifications and aims for throughput. The table gives the published requirements; figures from different pages and dates are labelled.
| Node | CPU | RAM | Disk | Bandwidth |
|---|---|---|---|---|
| Bitcoin Core, default (bitcoin.org, v31.0 page) | Not listed | 512 MB bare minimum | 750 GB | 250 MB a day down, 5 GB a day up |
| Bitcoin Core, pruned (same page) | Not listed | 256 MB bare minimum | 7 GB | 150 MB a day down, 10 MB a day up |
| Ethereum, minimum (ethereum.org, 17 Aug 2026) | 2+ cores | 16 GB, 32 GB advised | 2 TB NVMe | 25+ Mbit/s |
| Ethereum, recommended (same page) | 4+ fast cores | 32 GB | 4 TB NVMe | 50 Mbit/s down, 15+ up |
| Ethereum, validating (same page) | 8+ cores | 64 GB | As recommended | 25+ Mbit/s up |
| Solana validator (Anza docs, read 2 Nov 2026) | 12 cores/24 threads or more, 2.8 GHz+ | ECC suggested, board with 512 GB capacity suggested | 1 TB+ accounts, 1 TB+ ledger, 500 GB+ snapshots | Staked: 2 Gbit/s symmetric at least, 10 recommended |
| Solana RPC node (same docs) | 16 cores/32 threads or more | 256 GB or more | Larger ledger disk for longer history | Unstaked: 1 Gbit/s symmetric is enough |
Bitcoin Core: light on the machine, heavy on the first day
The official pages do not agree with each other, and neither matches the live chain. Bitcoin.org’s requirements page says 750 GB of disk and a one-time 740 GB download. Bitcoincore.org says “about 600GB of data plus a further 5-10GB per month”. Blockchair measured 780 GB on 2 November 2026. Plan from the measured number and add room for growth. The default upload of 5 GB a day, about 150 GB a month, is the line that surprises people on capped connections.
Ethereum: where the disk goes, and why client choice matters
Ethereum.org warns that its 2 TB minimum is likely to be exceeded by 2027, and it discourages DRAM-less and QLC drives. Take care with chain-size headlines. Blockchair’s API returned a size of about 1.79 TB for Ethereum on 2 November 2026, while ethereum.org lists 500 GB or more for a snap-synced Geth. The two numbers do not describe the same data, so neither tells you what to buy on its own.
Ethereum runs several independent client implementations on purpose. Ethereum.org’s client diversity page sets out the logic: a bug in a consensus client with over 33% of nodes could stop the consensus layer from finalising, and a critical bug in a client with a two-thirds majority could cause the chain to “incorrectly split and finalize”. The Infura episode was a small preview of what a client bug can do.
That page’s last dated snapshot, from October 2025 and marked as possibly outdated, had Geth at 41% and Nethermind at 38% of execution clients, with Lighthouse at 42.7% and Prysm at 30.9% of consensus clients. So one consensus client then sat above the 33% line. Do not read those shares as today’s. Consensus software is hard to identify from outside, and clientdiversity.org, read on 2 November 2026, showed Lighthouse at about 20% on one tracker and about 48% on another.
Solana: hardware for a data centre
Anza, which maintains the Agave client, asks for a CPU of 2.8 GHz or more with SHA extensions, separate NVMe disks, and at least 2 Gbit/s symmetric for a staked node. The page names no fixed RAM minimum for a validator, only a motherboard with 512 GB capacity, while it does require 256 GB or more for an RPC node. It also wants a public IPv4 address, and it advises against running behind a NAT, which is hard to meet on a home line. Compare it with a pruned Bitcoin node at 7 GB and the design choice is plain.
The growth problem: Ethereum starts to forget
Every chain grows, and a node that grows forever gets harder to run. Ethereum’s answer is history expiry, proposed in EIP-4444, still marked Draft. On 8 July 2025 the Ethereum Foundation wrote that “all Ethereum execution clients support partial history expiry in accordance with EIP-4444“. That step removes pre-Merge block data, saving about 300 to 500 GB and letting a node fit on a 2 TB disk.
The trust assumption shifts slightly. Old history only has to survive somewhere, and headers still let anyone verify it. Full rolling expiry was still in progress as of that post. The draft’s current text sets a retention window of 14,299 epochs, which by our arithmetic is about two months, and it remains a draft.
Why run one, and what it costs you
You stop taking anyone’s word for it
Ethereum.org sums up the case: a node lets you use the network “directly, trustlessly and privately“. Trustlessly means your wallet reads balances and confirmations from software you control, which has checked every rule itself. If a provider’s server is wrong, stale or lying, you are not exposed to it.
Privacy is the easier gain to overlook. Each RPC request tells the provider which addresses you care about, from which IP address. MetaMask’s privacy notice (last revised on 1 October 2026) says Infura is the default RPC provider under default settings and that it may temporarily process IP addresses where necessary. Switching to another provider moves that exposure rather than ending it. Pointing the wallet at your own node keeps those requests in your hands, and MetaMask documents how to connect one.
What you pay, and what you do not get
The bill is a disk, some bandwidth, electricity, and your attention for updates. There is no income on a plain node. Bitcoin.org describes operators as volunteers who give spare computing and bandwidth, and it says more are needed; ethereum.org says each node helps keep the network decentralised. That benefit is shared while the bill is yours, so the reason to run one is your own verification and privacy, or building on the chain, never a return.
RPC providers are a useful dependency, and still a dependency
Infura, Alchemy and similar companies run fleets of nodes and sell access through an API. Without them most wallets and applications would be far harder to build, and nothing about using them is wrong. But it puts a commercial layer between users and a network described as decentralised. The risks are concrete: a shared software fault can blind many applications at once, as it did in November 2020, and a provider sees a great deal of user activity.
Running one at home: a sidebar, not a tutorial
For most readers the sensible first node is Bitcoin Core on an existing computer with an SSD, pruned if disk is short. Bitcoin.org warns that the first sync “will take at least several days”. It suggests leaving the node on for at least 6 hours a day, continuously if you can, and turning off sleep or suspend, which can halt its traffic. Your pruned node still downloads the whole history once, so check any monthly cap before you begin.
Ethereum asks for more: two clients, a 2 TB NVMe at the very least (4 TB recommended), 16 to 32 GB of RAM, and regular updates of both programs. Sync time depends on client, configuration and hardware, and ethereum.org gives no fixed duration. Running a validator is a further commitment, with always-on uptime and 32 ETH at stake.
Four mistakes come up again and again:
- Choosing a cheap SSD. Ethereum.org discourages DRAM-less and QLC drives for a node.
- Forgetting upload. A default Bitcoin node can send about 150 GB a month, which matters on capped plans.
- Exposing the RPC port to the internet. Ethereum.org warns this “will let anyone on the internet control your node”, and Bitcoin Core’s documentation says not to enable RPC connections over the public internet. By default both stay on the local machine; leave them there.
- Backing up a validator by loading its keys on a second machine, which risks slashing.
Once the node runs, the next question is how it finds its peers and gets its data. That is the subject of the following lesson of this path, on peer-to-peer networks.
Four misunderstandings worth clearing up
“More nodes make the chain faster”
No. Each full node repeats the same work, so adding one adds a checker and no capacity. Throughput comes from the protocol’s limits on block size and timing. More nodes give more independent verification, which is a different benefit.
“18,526 means there are 18,526 Bitcoin nodes”
That figure counts reachable nodes, the ones that accept incoming connections. Bitcoin.org treats inbound connections as optional, so a machine behind a home router can run a full node without appearing in any count. The true number is unknown and higher, and the snapshot itself is noisy: the eight taken up to 09:01 UTC on 2 November 2026 ranged from 18,526 to 18,899.
The source needs a word too. Bitnodes changed hands: bitnodes.io says an independent rebuild is under way under a new operator, unaffiliated with its creator, and the snapshots now resolve to btcnodes.io. In the 09:01 UTC snapshot 7,841 entries were Tor addresses and 4,624 were I2P addresses, and an address is not a person: one operator can sit behind many of them.
“Run a node, earn crypto”
Searches such as “are crypto nodes profitable” turn up lists that mix several different products: staking, masternodes that require a locked collateral, and hardware or “node licence” schemes sold by projects. None of those is what this lesson describes. A node licence sold with a promise of yield is a financial product with a node-shaped name. Judge it by who pays the yield and from what, as you would any other investment offer.
“My wallet is a node”
Almost never. A typical browser or mobile wallet stores keys and signs transactions, then hands them to a remote RPC endpoint. Some wallets embed a light client. Fewer connect to a full node, and those only do so if you set one up. If you did not install and sync anything, you are most likely reading the chain through someone else’s window, as MetaMask users were on 11 November 2020.
