Blockchain Node Types: Full Nodes, Light Nodes & Archive Nodes Explained 2026
2026 complete guide to blockchain node types: Full Node vs Light Node (SPV) vs Archive Node — how they work, verify transactions, and why node diversity is the foundation of decentralization. Covers Bitcoin and Ethereum node requirements, hardware specs, running your own node, and network distribution statistics.
TL;DR
- Full nodes store the complete ledger and independently verify every transaction — they are the bedrock of blockchain decentralization, with roughly 12,000-18,000 reachable full nodes on the Bitcoin network
- Light nodes (SPV) store only ~60MB of block header data and can run on a smartphone, verifying transactions through Merkle proofs — efficient but reliant on full nodes for data
- Archive nodes retain all historical state data, exceeding 12TB, used primarily by blockchain explorers, DApp developers, and researchers — overkill for most users
Introduction
"Don't Trust, Verify" — it's the core tenet of the crypto world. But can you really verify every transaction? The answer depends on what type of node you run.
Blockchain nodes are the "base stations" of cryptocurrency networks — without nodes, there is no blockchain. As of July 2026, the Bitcoin network processes roughly 400,000-500,000 on-chain transactions daily1, Ethereum handles about 1,000,000-1,200,0002 — all independently verified by tens of thousands of nodes distributed across the globe. Every time you check a transaction on a block explorer, you're relying on someone else's node data — but is it a node you trust, or your own?
For most users, the concept of blockchain nodes feels familiar yet distant. You hear about "decentralization," "P2P networks," and "nodes" constantly, but few people have ever run their own node, let alone understand the fundamental differences between full nodes, light nodes, and archive nodes.
This article systematically breaks down all three node types — full, light (SPV), and archive nodes — covering how they work, their verification mechanisms, hardware requirements, and role in the network, helping you make the right choice for your needs. To first understand how the blockchain itself works, read our core blockchain principles: hashing and chain structure.
What Is a Blockchain Node?
The simplest definition: a blockchain node is a computer (or device) connected to a blockchain network, running client software that stores, verifies, and relays transaction and block data.
Nodes are the fundamental communication units of a blockchain network. When you initiate a withdrawal from an exchange, send a transfer from your wallet, or execute a smart contract on a DApp, the request is first packaged into a transaction, broadcast to network nodes for validation, relayed to other nodes upon confirmation of validity, and eventually included in a block by a miner (or validator).
A node's core responsibilities include:
- Transaction validation: verifying signatures, sufficient balance, and absence of double-spending
- Block validation: checking new blocks against consensus rules (difficulty target, transaction validity, etc.)
- Data storage: preserving the blockchain's historical data
- Transaction relay: broadcasting validated transactions to peer nodes
- Network maintenance: sustaining the P2P connection topology
However, not all nodes perform every task. Based on workload and data storage, nodes fall into three main categories — full nodes, light nodes, and archive nodes — along with some special variants.
Full Nodes: The Supreme Court of the Blockchain
What Is a Full Node
A full node is the "Supreme Court" of a blockchain network — it doesn't rely on any external source; it verifies everything independently. A full node downloads, stores, and validates the complete blockchain data (or at least the pruned but fully verified data). Every full node independently enforces consensus rules and accepts no one else's "guarantees."
The core function is straightforward: verify every new block and every transaction against the network's consensus rules. If a miner attempts to violate the rules (for example, creating a Bitcoin block over 4MB or including an invalid Coinbase transaction), the full node immediately rejects it — refusing to sync or relay it to other peers.
How Full Nodes Work
The startup process for a Bitcoin full node typically involves:
Initial Block Download (IBD)
A newly started full node fetches the complete blockchain data from peer nodes, from the genesis block to the latest block. During IBD, the node validates each block and every transaction within it — checking block header hashes against the difficulty target, verifying each Coinbase transaction's compliance, and confirming transaction signatures, sufficient balance, and absence of double-spending.
As of July 2026, Bitcoin full node IBD requires downloading approximately 600GB of data. On a 100Mbps connection, initial sync takes roughly 2-5 days (depending on CPU and storage performance). Ethereum full node initial sync exceeds 1TB, taking 3-7 days3.
Transaction Verification
Once synchronized, a full node continuously: validates all transactions in newly received blocks; verifies that the block header's Merkle root matches its transaction list; confirms the block's timestamp, difficulty, and Nonce comply with rules; and validates that the block size is within limits. Upon passing verification, the block is appended to the local chain.
Pruned Nodes
A pruned full node is a variant of the regular full node. It downloads and validates the complete blockchain data (identical IBD process), but after verification, it deletes old block transaction data, keeping only the UTXO set (Bitcoin) or the current world state (Ethereum). Bitcoin pruned full nodes can reduce storage requirements to approximately 10-20GB while still performing the same validation work.
A pruned node is NOT the same as a light node. A pruned node fully validated all historical data before pruning; a light node never downloaded the full data in the first place.
Why Full Nodes Matter
Full nodes are the guarantee of blockchain decentralization. If miners produce blocks, full nodes keep miners honest. In a network without full nodes, miners could easily alter rules, censor transactions, or forge history.
Every full node is effectively a "voter" on consensus rules — when a full node rejects a non-compliant block, it silently upholds network rule consistency. If enough nodes reject a new protocol version (refusing to adopt new rules), a soft fork may form; if new and old nodes reach an irreconcilable disagreement on what constitutes a valid block, a hard fork occurs.
The number of Bitcoin full nodes is a core metric for measuring blockchain decentralization.
Light Nodes (SPV Nodes): Mobile Validators
Why Light Nodes Exist
Mobile devices cannot store 600GB of blockchain data, yet many users still want to verify transactions on their own devices. Satoshi Nakamoto provided a solution in the original 2008 Bitcoin whitepaper — Simplified Payment Verification (SPV)4, the technical foundation of light nodes.
Light nodes don't store the complete blockchain; they only save the block header of each block, forming a chain of headers. Each Bitcoin block header is exactly 80 bytes — less than 2MB per year, totaling approximately 60MB for all Bitcoin history. Ethereum block headers are slightly larger (~500 bytes per block), totaling approximately 2-3GB for all history.
How SPV Verification Works
Light nodes verify whether a transaction has been confirmed by the network in a clever way:
The light node maintains the full chain of block headers. When it needs to verify a transaction, it requests the transaction details and its Merkle path proof from one (or more) full nodes — containing all sibling hashes from the transaction up to the block's Merkle root. The light node computes the Merkle root from these hashes and compares it against the Merkle root stored in the corresponding block header. If they match, the transaction is confirmed to exist in that block.
The critical limitation of SPV is: light nodes verify that a transaction is included in a block, but do not independently check the transaction's validity (such as sufficient balance or double-spending). They rely on full nodes for these "validity" judgments.
A light node knows "this transaction exists in block #X," but does not check "whether this block followed all the rules." It delegates that question entirely to full nodes.
Light Node Use Cases
The most common light node applications are mobile wallets and browser extension wallets. When you open a Bitcoin wallet on your phone, it's very likely an SPV light node:
- First launch: downloads all block headers (~60MB)
- Every ~10 minutes: syncs the latest block header
- When receiving a transaction: requests a Merkle proof from a full node
- Verifies using the Merkle proof + locally stored block header
- No need to download full transaction data
Modern light nodes typically connect to multiple full nodes to guard against deception — if one full node provides a fraudulent Merkle proof, the light node can cross-reference with another.
Light Node Limitations
The biggest limitation of light nodes is privacy: when a light node requests a transaction's Merkle proof from a full node, the full node can learn which transaction is being queried, potentially linking it to the light node's IP address and identity. BIP-37 (Bloom Filtering) and later BIP-157/158 (Compact Block Filters) have partially improved privacy protection in this area5.
Archive Nodes: The History Museum of the Blockchain
What Makes Archive Nodes Unique
Archive nodes are the most specialized node type — they require the most data, the highest hardware costs, yet perform no more "validation work" than full nodes. Archive nodes retain everything a full node stores, plus every historical state snapshot from genesis to the present.
The key data storage differences:
Bitcoin Archive vs Full Node
Bitcoin uses the UTXO model, where each block records the "creation" and "destruction" of UTXOs. A Bitcoin full node can reconstruct any past world state by replaying all historical transactions. Therefore, the data difference between Bitcoin archive and full nodes is minimal — both at approximately 600GB, differing only in whether old block files have been deleted.
Ethereum Archive vs Full Node
The gap between Ethereum archive and full nodes is enormous. Ethereum full nodes store complete transaction history but not the full world state snapshot after every block — they keep only the current state plus approximately the last 128 blocks for rollback. Archive nodes preserve the complete state snapshot after every single block.
Ethereum archive node data has exceeded 12TB as of July 2026, growing at approximately 2-3TB per year. This data volume makes running an Ethereum archive node prohibitively expensive for individual users.
Who Needs an Archive Node
Archive node users primarily include:
- Blockchain explorers (Etherscan, Blockchair, etc.): need to query any address's balance at any point in time
- DApp developers: need to examine historical contract states during development
- Data analytics and research firms: perform historical on-chain data trend analysis
- Audit firms: may need to trace historical state for smart contract security audits
- Exchanges and custodians: require full historical data for compliance and audit requirements
For average users, investors, and even most developers, a pruned full node or regular full node is more than sufficient.
Comprehensive Node Type Comparison
| Dimension | Full Node | Light Node (SPV) | Archive Node |
|---|---|---|---|
| Storage | ~600GB (BTC) / ~1TB+ (ETH) | ~60MB (BTC headers) / ~2-3GB (ETH) | ~600GB (BTC) / 12TB+ (ETH) |
| Transaction Verification | Full independent | Merkle proof only | Full + all historical snapshots |
| Initial Sync | 2-7 days | 5-30 minutes | 7-30 days |
| Hardware Requirements | Medium (8GB+ RAM, 1TB+ SSD) | Low (phone-capable) | Extreme (32GB+ RAM, 4TB+ NVMe) |
| Privacy | High (no external queries) | Medium (queries full nodes) | High (self-sufficient + historical queries) |
| Network Contribution | High (relay, serve light nodes) | Low (only connects) | High (serve full nodes + archival queries) |
| Operating Cost | Low-Medium (electricity + bandwidth) | Negligible | High (hardware + storage management) |
| Typical Users | Network participants, mining pools, exchanges | Wallet users | Data providers, research institutions |
| Regular Maintenance | Required (sync, upgrade client) | Minimal | Required (extensive storage management) |
Node Count and Decentralization
Actual Node Distribution
Every full node is a "pillar" of the decentralized network. As of July 2026, Bitcoin has approximately 12,000-18,000 reachable full nodes6, while Ethereum has roughly 5,000-7,0007. Accounting for Tor/i2p hidden nodes and firewalled unreachable nodes, the actual total node count is estimated at 50,000-100,000 for Bitcoin.
Geographic distribution shows notable concentration:
- United States: ~25-30% of Bitcoin nodes, ~30-35% of Ethereum nodes
- Germany: ~15-20% of Bitcoin nodes, ~15-20% of Ethereum nodes
- France: ~5-8% of Bitcoin nodes
- Netherlands, Canada, United Kingdom: ~3-5% each
- Asia overall: less than 15% of Bitcoin nodes, ~10-15% of Ethereum nodes
This geographic concentration presents a latent decentralization risk — if a country implements large-scale node blocking, the network could be significantly impacted. Bitcoin Core's FIBRE network and Tor support, introduced in 2019, have partially mitigated this issue.
How Many Nodes Are "Enough" for Decentralization
There is no single answer. From a security perspective, the core metric isn't total node count but node operator diversity. Two thousand nodes run by the same company are less censorship-resistant than 500 independent nodes distributed across different countries, ISPs, and legal jurisdictions.
An ideal node network should exhibit:
- Geographic diversity: nodes distributed across as many countries and regions as possible
- Operator diversity: nodes running on different ISPs, cloud providers, and hardware
- Software diversity: different client implementations (e.g., Bitcoin Core, bcoin, libbitcoin)
- Autonomy: each node operated by an independent individual or organization, not a single entity
How to Run Your Own Node
Bitcoin Full Node
Running a Bitcoin full node is the easiest entry point, with mature tools and community support:
- Hardware: a computer with 8GB+ RAM and 1TB+ SSD running Linux/Windows/Mac (a Raspberry Pi 4 with external SSD works too)
- Download Bitcoin Core: get the latest version from bitcoincore.org (current version v28.x)
- Initial sync: start the client, wait for IBD to complete (2-5 days depending on hardware and network)
- Configure optional features: enable Tor proxy for privacy, enable pruning mode to save space, open RPC interface for external programs
For beginners, tools like Umbrel or MyNode offer one-click node management on a Raspberry Pi or Intel NUC with a web-based interface.
Ethereum Full Node
Ethereum full nodes require more powerful hardware:
- Hardware: 16GB+ RAM, 2TB+ NVMe SSD (3-4TB recommended for future growth)
- Client selection: execution layer client (Geth, Nethermind, Besu) + consensus layer client (Lighthouse, Prysm, Teku)
- Fast sync: use "Snap Sync" to reduce IBD from days to hours
- Initial sync: approximately 3-7 days (snap sync mode can reduce to 12-24 hours)
Light Node
For most users, running a light node is the simplest way to participate:
- Bitcoin light node: enable "SPV mode" in mobile or desktop wallets (e.g., Electrum, BlueWallet)
- Ethereum light node: MetaMask and Rainbow default to light node mode
- Standalone light node: configure with
bitcoind -prune=0 -blocksonly=0for a Bitcoin Core light node
Future Trends in Node Technology
Blockchain node technology is evolving rapidly in several directions:
Light client standardization: Ethereum's Portal Network aims to further distribute light node header data, making light nodes completely independent of centralized full nodes. This would significantly improve light node security and privacy.
State expiry: Ethereum's "State Expiry" proposals attempt to solve archive node data explosion. The core idea is to move long-unaccessed state data to a "cold" state, reducing active node storage pressure.
Tiny node hardware: Miniscript and Taproot enable Bitcoin validation on microcontrollers. IoT device nodes may become a new node paradigm in the future.
Full nodes as a public service: More community members and organizations offer public full node services (Blockstream Green, Infura, Alchemy), but these centralized services exist in tension with blockchain's decentralization philosophy.
Summary
| Node Type | One-Line Summary |
|---|---|
| Full Node | Blockchain's self-defense force — trusts nothing, independently verifies every transaction and block |
| Light Node | Efficient user — trades some security and privacy for extremely low resource consumption |
| Archive Node | Data archaeologist — preserves every historical snapshot from genesis, serving analytics and queries |
For most crypto users, understanding node types matters because: you don't have to run a full node yourself, but you should know why full nodes are important. If you want to contribute to network security and privacy, running a pruned full node (10-20GB storage) or using a light node wallet (a few MB) already makes a difference.
Ultimately, a blockchain network's security and decentralization depend on the diversity of its node operators — every independently run full node strengthens the network's censorship resistance. This is not just putting "Don't Trust, Verify" into practice, but actively maintaining the value of the crypto world.
FAQ
Are blockchain nodes and miners the same thing?
No. Miners/Validators produce new blocks; nodes verify and maintain blockchain data. A node can also function as a miner (pool nodes commonly dual-function), but the vast majority of nodes only validate, not mine. Among Bitcoin's 12,000-18,000 reachable nodes, only a tiny fraction participate in mining.
Can I use cryptocurrency without running a node?
Absolutely. Most users access cryptocurrency through exchanges, custodial wallets, or block explorers, which run full nodes in the background. The benefit is zero technical barriers; the trade-off is trusting a third party's data — at odds with the "Don't Trust, Verify" ethos of crypto. If you want to hold assets yourself without relying on third parties, our Bitcoin 2026 complete guide: from mining to Layer 2 lays out the full self-custody picture.
Do nodes earn income?
Bitcoin and Ethereum full nodes (non-mining) do not earn direct income. Running a node is a voluntary contribution to network security and decentralization. Some projects (Stacks' STX delegation, Layer 2 sequencer nodes) do offer token rewards to node operators, but most operators run nodes out of principle.
Can a smartphone run a full node?
Not currently. Bitcoin full nodes require approximately 600GB of storage and stable uptime; Ethereum full nodes need 1TB+. However, smartphones can easily run light nodes (SPV). Bitcoin Core is developing mobile full node applications, but storage and performance constraints make mainstream adoption unlikely in the near term.
Can nodes be attacked?
Yes. Publicly accessible full nodes face some network attack risks: DDoS attacks can disconnect nodes; ISPs can block P2P ports (Bitcoin default 8333, Ethereum default 30303); advanced attackers can launch Eclipse attacks (surrounding a node with attacker-controlled peers). Bitcoin Core improvements (Tor support, anchor peer introduction) and various network-level precautions have significantly improved node resilience.
References
Footnotes
-
Blockchain.com Stats — Bitcoin on-chain transaction statistics https://www.blockchain.com/explorer/charts ↩
-
Etherscan.io — Ethereum transaction statistics https://etherscan.io/ ↩
-
Ethereum.org — Ethereum node operation guide https://ethereum.org/en/developers/docs/nodes-and-clients/ ↩
-
Bitcoin Whitepaper — SPV Verification Section https://bitcoin.org/bitcoin.pdf ↩
-
Bitcoin Improvement Proposals — BIP-37 / BIP-157/158 https://github.com/bitcoin/bips ↩
-
Bitnodes.io — Bitcoin node real-time statistics https://bitnodes.io/ ↩
-
Ethernodes.org — Ethereum node real-time statistics https://ethernodes.org/ ↩