The confusion usually starts when someone tries to query historical blockchain data — say, the ETH balance of a specific address at a block from three years ago — and finds that their node can't answer it. That's not a bug. It's a deliberate design choice that reveals a fundamental distinction between two types of blockchain nodes: full nodes and archive nodes.
Understanding this distinction matters if you're running infrastructure, building on-chain tooling, or trying to make sense of why services like Infura and Alchemy expose different endpoint types at different price points.
What a Full Node Actually Stores
A full node downloads, validates, and processes the complete blockchain — every block, every transaction — but with one important caveat: it doesn't keep every historical state by default.
Here's what that means in practice. When a full node processes blocks, it validates each transaction against the current ledger state. For Ethereum, that means checking account balances, nonce values, and smart contract storage slots. After validation, the state updates. But in the default pruned configuration, the node only retains the current state and a limited window of recent blocks. Historical states get discarded once they're no longer needed to validate incoming blocks.
This is a deliberate trade-off. Full nodes can verify new blocks and prove the integrity of the current chain. What they can't do is answer questions about the past. "What was address 0x... worth at block 14,000,000?" A pruned full node has no answer — that state was discarded.
In terms of storage requirements: an Ethereum full node running Geth in default mode requires roughly 1–1.2TB as of mid-2026. On Bitcoin, a pruned full node can run with as little as 5GB, though a non-pruned node storing all historical blocks runs closer to 600GB.
What an Archive Node Adds
An archive node is a full node that keeps everything — including every historical state change since genesis.
Every time the Ethereum state changes (an account's balance updates, a contract's storage slot flips), an archive node records that change and indexes it. That means you can query it: "What was the USDC balance of contract X at block 14,850,000?" and receive a precise answer.
This is what blockchain explorers like Etherscan depend on. It's also what most DeFi protocols, tax tools, and analytics platforms need when processing historical data. Any time you see a historical balance at a specific date, a transaction trace from two years ago, or an audit of past smart contract state, an archive node is behind it.
The cost of this capability is storage. An Ethereum archive node as of mid-2026 requires roughly 16–20TB of disk space, depending on the client and configuration, and that number grows steadily as new blocks accumulate. Bitcoin's equivalent is more manageable — the full block history with all historical state runs closer to 600GB — because Bitcoin's UTXO model doesn't carry the same smart contract storage overhead.
Most developers don't run their own archive nodes. They use RPC providers — Infura, Alchemy, QuickNode, Ankr — which expose archive access via API. These services absorb the infrastructure cost and often charge more for archive-depth queries than for standard current-state calls.
Where the Constraint Actually Lives
The boundary between full and archive isn't cryptographic — it's operational. Any node could retain all historical state. The question is whether the operator chooses to and whether they have the storage to sustain it.
This creates a tiered ecosystem. At the base layer, full nodes participate in consensus, validate blocks, and propagate the chain. They're sufficient for running a validator, broadcasting transactions, or verifying that the current chain state is legitimate. Most people who "run their own node" are running a full node in this sense.
Archive nodes serve a different function. They're reading infrastructure, not consensus participants. You don't need an archive node to be a validator. You do need one — or access to one via RPC — if you're building anything that queries past chain state.
There's a third type worth placing here for completeness: light clients. These download only block headers, not full blocks, and rely on full nodes for transaction verification. Designed for mobile wallets and low-resource environments, light clients give up independent verification in exchange for minimal storage overhead. They can't audit the chain themselves, but most wallet use cases don't require it.
So the rough hierarchy is: light client → full node → archive node, with each tier adding storage requirements, query capability, and operational complexity.
What's Changing
A proposal called EIP-4444 would allow full nodes to stop storing historical block bodies and receipts beyond a certain age. The rationale: historical data doesn't need to live in every full node. It could instead be served by the Portal Network, a distributed storage layer purpose-built for this function — essentially a distributed hash table for blockchain history.
If EIP-4444 ships, the distinction between full and archive nodes sharpens further. Full nodes become even lighter, focused entirely on current-state verification. Historical data access would route through a separate infrastructure layer. As of mid-2026, EIP-4444 is actively discussed but hasn't been deployed to mainnet.
L2 networks complicate this picture in a different direction. Most L2s post compressed data to L1 and run their own sequencer infrastructure. Archive-equivalent access on L2s is generally more available because transaction volumes are lower and state is smaller — some L2s expose historical query endpoints without the 20TB overhead of mainnet.
Confirmation and Invalidation
For anyone needing to verify which type of node they're accessing: query a historical balance for a well-known address at an old block number. If the response returns a precise value, you have archive access. If it returns an error — "missing trie node," "state not available," or similar — you're hitting a pruned full node.
Invalidation of the full-vs-archive distinction would require a protocol shift that fundamentally changes how nodes store state. The most relevant candidate is stateless validation: clients verify state via cryptographic proofs (Verkle trees are the current research direction) rather than storing state themselves. If stateless Ethereum ships, the taxonomy changes substantially — but that's multi-year horizon work, not something currently deployed.
Timing Perspective
Now: The distinction is live and consequential. If you're building anything that needs historical on-chain data, you need archive access — either via a provider or by running your own node (significant infrastructure commitment, 20TB+ for Ethereum mainnet with slow initial sync).
Next: EIP-4444 worth monitoring. If implemented, it changes how historical data is distributed and accessed — full nodes get lighter, and Portal Network access becomes relevant.
Later: Stateless Ethereum (clients verify without storing full state) is active research with a long runway. It would change the full node model substantially, but isn't imminent.
What This Doesn't Cover
This is a node type explanation — what each stores and why. It doesn't address how to run a node, which client software to use (Geth, Reth, Erigon, Nethermind all have different defaults), or the economics of commercial RPC access.
Full nodes give you independent chain verification. Archive nodes add historical query capability. Both are useful; they serve different functions. The choice between running your own or using a provider depends on your use case and willingness to absorb infrastructure costs — not on any difference in trustworthiness between the node types themselves.
