The day Ethereum "went down" — and didn't
On 11 November 2020, MetaMask wallets across the world suddenly showed blank balances. Binance paused Ethereum withdrawals. Block explorers froze. To millions of users it looked like Ethereum itself had crashed. It hadn't. A latent consensus bug — quietly fixed in Geth v1.9.17 but left un-upgraded on many machines — was triggered on mainnet, and every node still running the old software forked off onto a dead chain. One of those machines belonged to Infura, the hosted endpoint that MetaMask, Binance, and a long list of exchanges all quietly relied on. When Infura's view of the chain broke, their view of the chain broke. Meanwhile, the actual Ethereum network kept producing valid blocks every twelve-or-so seconds without missing a beat. The people who never noticed the outage were the ones running their own node.
That story is the whole reason this rung exists. A blockchain is only as trustless as the software you run to check it. The Bitcoin and Ethereum design philosophy compresses into three words — don't trust, verify — and a node is the thing that does the verifying. It is not a server you connect to; it is a program that independently re-derives the entire state of the chain from the raw blocks, applying every rule itself, trusting no one's summary. That independent verification is exactly what trustlessness means.
The full node: re-executing reality
A full node is the default, canonical participant. For every block it receives, it does not take the block producer's word for anything. It re-executes every transaction in the block through the state transition function, recomputes the resulting state root, and checks that the root it calculated matches the one written in the block header. It re-checks every signature, every nonce, every gas accounting line. If a validator tries to sneak in an invalid transaction — minting coins from nothing, spending someone else's balance — your full node simply rejects the block. No appeal, no override. This is why a 51% attacker can reorder or censor, but still cannot make your node accept an invalid state: the rules are enforced locally, on your machine.
What a full node stores is more subtle than people expect. It keeps the current world state — every account balance, contract, and storage slot, organised as a Merkle-Patricia trie — plus enough recent block history to serve peers and handle short reorgs. What it does not keep is every intermediate historical state; by default it prunes old state tries it no longer needs. As a rough figure for the mid-2020s, a snap-synced Geth full node lands around 1.2 TB and grows steadily; leaner clients like Erigon or Reth pack it smaller via a flat key-value layout. The point is that "full" means fully validating, not keeping everything forever.
# Two ways to run the same chain. Note the --syncmode and --gcmode flags. # FULL node (default): validate everything, prune old state. # ~1.2 TB on an NVMe SSD, syncs in hours via snap sync. geth --syncmode snap --datadir /data/eth # ARCHIVE node: keep EVERY historical state. Disk-hungry, slow. # 15+ TB on Geth, syncs over days/weeks (it replays from genesis). geth --syncmode full --gcmode archive --datadir /data/eth-archive
This is also where immutability stops being a slogan and becomes something you personally verified. You don't believe the chain is tamper-proof because a blog said so; your node recomputed the hash links and the state roots and confirmed it, block by block, all the way back.
The archive node: remembering every yesterday
An archive node is a full node that never prunes. It retains the complete historical state — the exact world state as it stood at block 4,000,000, at block 12,965,000, at every block ever. That lets it answer questions a normal full node cannot: "what was this account's balance 800 days ago?", or a full `debug_traceTransaction` that re-executes a years-old transaction opcode by opcode. This is the engine behind block explorers like Etherscan, on-chain analytics, tax tools, and the indexers we'll meet two guides from now — anything that needs to read deep history through the JSON-RPC interface.
The cost is brutal storage. A Geth archive node runs well past 15 TB and keeps climbing; Erigon's flat-storage design cuts the same data to roughly a few TB, which is why most archive operators choose it. The honest takeaway: almost nobody needs an archive node. If your goal is to verify your own transactions and use your wallet sovereignly, a pruned full node is enough — and far cheaper.
The light client: verify the headers, request the proofs
A light client is for the device in your pocket. Instead of downloading and re-executing every transaction, it downloads only the chain of block headers — a few hundred bytes each — and verifies the consensus that produced them. On Ethereum's proof-of-stake, it does this with the sync committee: a rotating group of 512 validators whose aggregated BLS signature attests to each header. The light client only needs to check that one aggregate signature, which is cheap enough to do on a phone. It never re-runs the EVM.
So how does a light client read a balance it never stored? It asks a full node and demands a proof. The header it already trusts contains the state root; the full node returns the balance plus the Merkle-Patricia branch connecting that balance up to the root. The light client hashes its way up the branch and checks it lands exactly on the trusted root. If the full node lies about the balance, the proof simply won't hash to the root, and the lie is rejected. This is the elegant part: a light client trusts no one for correctness — math catches any false answer.
Be honest about the trade-off, though. Proofs protect you from wrong answers, not from no answer: a light client still depends on finding some honest full node willing to serve it, so its liveness and censorship-resistance are weaker than a full node's. And it inherits the chain's honest-majority assumption for header validity — if the sync committee itself were corrupt, the headers could lie. A light client is a brilliant trust-minimised compromise, not a trust-free one.
Getting in sync: full, snap, and checkpoint
A fresh node knows only the genesis block and must somehow catch up to a chain tip millions of blocks away. How it does that — the sync mode — is one of the most practical choices you'll make, because it trades verification thoroughness against time.
- Full sync (from genesis): replay and re-execute every block from block 0 to the tip. Maximally paranoid — you verify the entire history yourself — but it can take days to weeks. Combined with archive mode, this is how an archive node is built.
- Snap sync (Geth's default): download a snapshot of the state trie at a recent block as raw account/storage ranges, then 'heal' any gaps and verify forward from there. You skip re-executing ancient history but still end up fully validating the live chain. Hours, not weeks — this is what almost everyone runs.
- Checkpoint (weak-subjectivity) sync: on the consensus side, the node starts not from genesis but from a recent finalized checkpoint — a block root you obtain from a trusted source — and syncs outward from there. This is how a consensus client comes up in minutes instead of days.
That last mode hides a real subtlety worth naming. In proof-of-stake you cannot safely bootstrap from genesis using nothing but the protocol, because of the long-range attack: an attacker holding old, since-withdrawn validator keys could forge a plausible alternate history. The defence is weak subjectivity — a new (or long-offline) node must be handed a recent trusted checkpoint to anchor on. It's a small, one-time trust input, and a fair trade for being able to sync in minutes; just get your checkpoint from a source you trust (a friend's node, several independent explorers you cross-check), not a random stranger.
# Ask YOUR OWN node whether it has finished syncing (JSON-RPC over HTTP).
curl -s -X POST http://localhost:8545 \
-H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_syncing","params":[]}'
# While syncing -> an object with progress:
# {"result":{"currentBlock":"0x10a3f0","highestBlock":"0x12c4b8", ...}}
# Fully synced and verifying at the tip -> literally the boolean false:
# {"jsonrpc":"2.0","id":1,"result":false}The plumbing: peers, gossip, and the box it runs on
No node is an island — every node is a member of a peer-to-peer network with no central server. On startup it bootstraps from a handful of well-known nodes, then runs a discovery protocol (Ethereum uses discv5, a Kademlia-style DHT over UDP) to find more, settling into a steady set of roughly 25–100 peers. There is no master list and no one to ask permission; the topology heals itself as peers come and go.
Across those connections everything spreads by gossip. When you broadcast a transaction, your node hands it to its peers, who hand it to theirs, and within seconds it has flooded the network and is sitting in everyone's mempool — this is transaction propagation, and it's the same epidemic-style flooding that carries new blocks. Crucially, your node re-validates each item before forwarding it: it won't relay an invalid transaction or an invalid block. The network's integrity is the emergent result of every node being selfishly skeptical.
And it all has to run somewhere. Mid-2020s practical specs: a 4-core CPU, 16–32 GB RAM, and — non-negotiable — a 2 TB+ NVMe SSD. The SSD matters more than anything: validating the chain hammers the state database with small random reads and writes, the exact workload a spinning hard drive is hopeless at; an HDD-backed node simply falls behind the tip forever. Plan for a stable ~25 Mbps link and a few hundred GB of traffic a month.