Running a Node & Client Diversity

What a Node Actually Does

A node is a computer running software that downloads a blockchain, checks every block and transaction against the network's rules, and passes valid data on to other nodes. A wallet that asks someone else's server for your balance is trusting that server. ethereum.org notes that wallets typically reach out to a third-party node such as Infura or Alchemy by default, and that public nodes can see your IP address and which addresses you own. Running your own node is the 'don't trust, verify' option, and ethereum.org states that you do not need any ETH to run one.

Full, Pruned and Archive in Plain Words

A full node checks every block but does not keep everything forever. On Ethereum it keeps a local copy of relatively recent data, typically the most recent 128 blocks, and lets older data be deleted to save disk space, which is what 'pruned' means. An archive node keeps all of it, a volume ethereum.org puts in the terabytes, which suits block explorers and analytics firms rather than ordinary users. A light client sits at the other end: it downloads only block headers and asks full nodes for the rest, so it saves resources but cannot take part in consensus.

What It Takes: Bitcoin and Ethereum Side by Side

As of October 2026, ethereum.org's run-a-node page lists 4 to 8 GB of memory and a 2 TB solid-state drive as minimum hardware, and says that a node that goes offline simply catches up when it returns. By comparison, the bitcoin.org full-node page describes ordinary desktop or laptop hardware and says full nodes on fast connections commonly upload 200 gigabytes or more a month. Its advice is to leave the node running at least six hours a day, and continuously if possible, so bandwidth caps matter as much as disk space.

• Bitcoin: one program, Bitcoin Core, which validates blocks and relays them to other nodes.
• Ethereum: two programs that work as a pair, an execution client and a consensus client.
• Both: the first start downloads and verifies a large amount of history before the node is usable.
• Light client: cheaper to run, but it relies on full nodes for most of its data.

Two Clients Make One Ethereum Node

Since the Merge, an Ethereum node runs an execution client, which executes transactions in the EVM and holds the state, and a consensus client, which runs the proof-of-stake logic. As of October 2026, ethereum.org's nodes-and-clients page lists Geth, Nethermind, Besu, Erigon, ethrex and Reth as execution clients, with EthereumJS marked as still in development, and Lighthouse, Lodestar, Nimbus, Prysm, Teku and Grandine as consensus clients. All follow shared specifications. A validator is a further piece of software added to a consensus client, which is why ordinary nodes need no stake.

Syncing: Snap, Checkpoint and Where Trust Enters

Execution clients can snap sync, starting from a recent trusted checkpoint rather than from genesis, which ethereum.org calls the default on mainnet; a full sync that re-executes every block can take days to weeks. Consensus clients offer checkpoint sync, based on weak subjectivity: the node downloads a recent finalised state from a remote service and verifies from there. ethereum.org adds that the provider is trusted and should be picked carefully. Bitcoin Core's assumeUTXO feature is comparable: a UTXO snapshot is checked against a hash hard-coded in the software, while a background chainstate keeps validating the history, and a pruned node can load a snapshot.

Bitcoin Core and Solana as Contrasts

Bitcoin Core's documentation says it allows up to 200 peer connections by default, 11 of them outbound, and that turning off listening reduces traffic at the cost of serving fewer peers. Solana is, in contrast, much heavier. As of October 2026, Anza's Agave documentation sets no strict minimum stake but asks for a vote account with a rent-exempt reserve of 0.02685864 SOL, notes that voting can cost up to 1.1 SOL per day, and recommends 12 cores, 256 GB of memory and several NVMe drives for a validator. By comparison, ethereum.org lists 4 to 8 GB as the minimum for an Ethereum node, while EIP-7870, an informational proposal, recommends 32 GB of memory and a 4 TB NVMe drive for a full node (read 27 October 2026).

Client Diversity as a Security Property

Ethereum finalises when validators holding two thirds of the stake agree, so a single client's share decides how much damage one bug can do. The clientdiversity.org dashboard, read on 27 October 2026, sets the goal at under 33% and marks over 66% as danger. A bug in a client with more than one third can stop the chain finalising. A bug in a client at or above two thirds can finalise a wrong chain, and validators on it then face slashing or a slow, costly exit; ethereum.org's page, updated in February 2026, puts the maximum penalty at 32 ETH. Recovery is social: ethereum.org says full nodes can choose to follow the honest chain. The 2016 Shanghai denial-of-service attack is the positive example, because other clients kept running while Geth was fixed.

What the Share Numbers Say, and Why They Disagree

ethereum.org's chart, dated October 2025, put Geth at 41.0%, Nethermind at 38.0% and Besu at 16.0% of execution clients (supermajority.info, 26 October 2025), and Lighthouse at 42.7%, Prysm at 30.9% and Teku at 13.9% of consensus clients. For example, on 27 October 2026 the clientdiversity.org dashboard showed three consensus datasets that disagreed: Miga Labs listed Lighthouse at 49.38%, Rated.Network listed Teku at 53.86%, and Sigma Prime's Blockprint listed Teku at 99.83%. For execution clients, the same page showed on 27 October 2026 Geth and Nethermind at 43% each, based on 59.4% self-reported coverage with the rest assumed mostly Geth, marked that dataset stale as most of its data was over a year old, and said its Ethernodes feed was removed. Consensus clients are identified from traces, which ethereum.org says can confuse minority clients.

A Recorded Incident, and What Cannot Be Sourced

On the consensus-layer call of 18 May 2023, a speaker referred to a maintenance incident in which the chain stayed alive and resolved itself, and to a post-mortem that the notes attribute to 'Prism'. The notes do not describe the cause, the clients involved or any finality figures, so this page states none. A second limit applies to counting: ethereum.org warns that node crawlers can only give a limited view and may report different results, and Bitcoin Core lets an operator disable listening to cut traffic, which leaves the node connected to fewer peers while it still validates. Operators can reduce their own correlation risk with multinode validator clients, which require M of N connected clients to agree before voting.

Who Runs Nodes, and Why It Matters

ethereum.org argues that full nodes enforce the consensus rules and so cannot be tricked into accepting invalid blocks; if every node were a light node, validators could attack the network. bitcoin.org makes the same point from the other side: if too few full nodes serve lightweight clients, those clients must fall back on centralised services. Both pages treat verification by many independent parties as a safeguard, and client diversity extends that idea from the number of verifiers to the variety of software they run.