Node_types
Chapter 3: Types of Blockchain Nodes
Section titled “Chapter 3: Types of Blockchain Nodes”Overview
Section titled “Overview”Understanding the different types of blockchain nodes is crucial for infrastructure engineers. Each node type serves a specific purpose and has different resource requirements. In production environments, you may run multiple node types to meet various needs.
3.1 Node Types Comparison
Section titled “3.1 Node Types Comparison”┌─────────────────────────────────────────────────────────────────────────────┐│ BLOCKCHAIN NODE TYPES │├─────────────────────────────────────────────────────────────────────────────┤│ ││ ┌─────────────────┐ ││ │ FULL NODE │ ◄── Most common, validates everything ││ └────────┬────────┘ ││ │ ││ ┌────────▼────────┐ ┌─────────────────┐ ││ │ LIGHT NODE │ ◄── │ ARCHIVE NODE │ ││ │ Limited data │ │ Full history │ ││ └─────────────────┘ └────────┬────────┘ ││ │ ││ ┌─────────────────┐ │ ││ │ RPC NODE │◄─────────────┘ ││ │ API services │ ││ └────────┬────────┘ ││ │ ││ ┌────────▼────────┐ ││ │ VALIDATOR │ ◄── Consensus participation ││ │ / MINER │ ││ └─────────────────┘ ││ │└─────────────────────────────────────────────────────────────────────────────┘3.2 Full Nodes
Section titled “3.2 Full Nodes”What is a Full Node?
Section titled “What is a Full Node?”A full node downloads and validates every block and transaction from the genesis block. It independently verifies the entire blockchain history.
Characteristics
Section titled “Characteristics”| Feature | Description |
|---|---|
| Storage | Stores complete blockchain data |
| Validation | Validates all transactions and blocks |
| Independence | Can operate without other nodes |
| Network Role | Backbone of decentralization |
Storage Requirements (Approximate)
Section titled “Storage Requirements (Approximate)”| Blockchain | Mainnet Data Size |
|---|---|
| Ethereum | ~1.2 TB (after Merge) |
| Bitcoin | ~600 GB |
| Cosmos | ~200 GB |
| Solana | ~10 TB |
Running a Full Node
Section titled “Running a Full Node”# Example: Running Ethereum Full Node with Gethgeth --syncmode full --http --http.addr 0.0.0.0 --http.port 8545Advantages
Section titled “Advantages”- ✅ Complete independence and privacy
- ✅ Maximum security and trustlessness
- ✅ Contribute to network health
Disadvantages
Section titled “Disadvantages”- ❌ High storage requirements
- ❌ Initial sync takes significant time
- ❌ Resource intensive
3.3 Light Nodes
Section titled “3.3 Light Nodes”What is a Light Node?
Section titled “What is a Light Node?”A light node (or light client) only downloads block headers and verifies a small subset of transactions. It relies on full nodes for most data.
Use Cases
Section titled “Use Cases”- Mobile wallets
- Browser extensions
- Resource-constrained devices
- Quick transaction verification
How Light Nodes Work
Section titled “How Light Nodes Work”┌─────────────────────────────────────────────────────────────────┐│ LIGHT NODE OPERATION │├─────────────────────────────────────────────────────────────────┤│ ││ Light Node ││ ┌─────────────┐ ││ │ Block │────── Download only headers ││ │ Headers │ ││ └──────┬──────┘ ││ │ ││ ▼ ││ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ││ │ Want TX │────▶│ Full Node A │────▶│ Return TX │ ││ │ Proof │ │ │ │ + Merkle │ ││ └─────────────┘ └─────────────┘ │ Proof │ ││ └─────────────┘ ││ ││ Light Node verifies: ││ 1. Transaction is in block (Merkle proof) ││ 2. Block follows consensus rules ││ │└─────────────────────────────────────────────────────────────────┘Running a Light Node
Section titled “Running a Light Node”# Example: Running Ethereum Light Node with Gethgeth --syncmode light --httpAdvantages
Section titled “Advantages”- ✅ Low storage requirements (~1 GB)
- ✅ Fast initial sync (minutes vs days)
- ✅ Suitable for mobile devices
Disadvantages
Section titled “Disadvantages”- ❌ Depends on full nodes for data
- ❌ Lower security guarantees
- ❌ Cannot verify all state independently
3.4 Archive Nodes
Section titled “3.4 Archive Nodes”What is an Archive Node?
Section titled “What is an Archive Node?”An archive node stores the complete blockchain history AND all historical states. It’s essentially a full node plus complete historical snapshots at every block.
When to Use Archive Nodes
Section titled “When to Use Archive Nodes”- Blockchain explorers (Etherscan, Blockscout)
- Analytics and data indexing
- Historical state queries
- Auditing and compliance
- dApp backends requiring historical data
Storage Comparison
Section titled “Storage Comparison”┌────────────────────────────────────────────────────────────────┐│ STORAGE COMPARISON │├────────────────────────────────────────────────────────────────┤│ ││ Ethereum Mainnet (approximate): ││ ││ ┌──────────────────┬────────────────────────────────────┐ ││ │ Node Type │ Storage Required │ ││ ├──────────────────┼────────────────────────────────────┤ ││ │ Light Node │ ~1 GB │ ││ │ Full Node │ ~1.2 TB │ ││ │ Archive Node │ ~12 TB │ ││ └──────────────────┴────────────────────────────────────┘ ││ ││ Note: Archive nodes require 10x more storage than full nodes ││ │└────────────────────────────────────────────────────────────────┘Running an Archive Node
Section titled “Running an Archive Node”# Example: Running Ethereum Archive Node with Gethgeth --syncmode full --history.state 0 --httpAdvantages
Section titled “Advantages”- ✅ Query any historical state
- ✅ Required for block explorers
- ✅ Complete historical data
Disadvantages
Section titled “Disadvantages”- ❌ Extremely high storage (10+ TB)
- ❌ Very slow initial sync
- ❌ High RAM requirements (32GB+)
3.5 Validator Nodes
Section titled “3.5 Validator Nodes”What is a Validator?
Section titled “What is a Validator?”A validator is a node that participates in the consensus mechanism by proposing and validating new blocks. In Proof of Stake networks, validators stake cryptocurrency as collateral.
Validator Responsibilities
Section titled “Validator Responsibilities”- Block Proposal: Create new blocks
- Block Validation: Verify other validators’ blocks
- Attestation: Vote on block validity
- Participation: Stay online and responsive
Validator Setup
Section titled “Validator Setup”┌─────────────────────────────────────────────────────────────────┐│ VALIDATOR WORKFLOW │├─────────────────────────────────────────────────────────────────┤│ ││ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ││ │ Stake │────▶│ Become │────▶│ Start │ ││ │ Tokens │ │ Validator │ │ Validating │ ││ └─────────────┘ └─────────────┘ └──────┬──────┘ ││ │ ││ ▼ ││ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ││ │ Receive │◀────│ Participate│◀────│ Propose │ ││ │ Rewards │ │ in Consensus │ Blocks │ ││ └─────────────┘ └─────────────┘ └─────────────┘ ││ │└─────────────────────────────────────────────────────────────────┘Becoming a Validator
Section titled “Becoming a Validator”Ethereum (PoS):
- Minimum 32 ETH stake
- Run a consensus client (Lighthouse, Prysm, Teku)
- Run an execution client (Geth, Nethermind, Besu)
Cosmos:
- Stake ATOM tokens
- Run validator software
- Meet technical requirements
Slashing
Section titled “Slashing”Validators can be slashed (penalized) for:
- Downtime (being offline)
- Double signing (proposing two blocks at same height)
- Incorrect attestations
3.6 RPC Nodes
Section titled “3.6 RPC Nodes”What is an RPC Node?
Section titled “What is an RPC Node?”An RPC (Remote Procedure Call) node is a full node that exposes API endpoints for external applications to interact with the blockchain.
Common RPC Methods
Section titled “Common RPC Methods”// Ethereum JSON-RPC Example// eth_blockNumber - Get latest block number{ "jsonrpc": "2.0", "method": "eth_blockNumber", "params": [], "id": 1}
// eth_getBalance - Get account balance{ "jsonrpc": "2.0", "method": "eth_getBalance", "params": ["0x742d35Cc6634C0532925a3b844Bc9e7595f1e3E4", "latest"], "id": 1}
// eth_sendTransaction - Send transaction{ "jsonrpc": "2.0", "method": "eth_sendTransaction", "params": [{ "from": "0x...", "to": "0x...", "value": "0x...", "gas": "0x...", "gasPrice": "0x..." }], "id": 1}RPC vs. Full Node
Section titled “RPC vs. Full Node”| Aspect | Full Node | RPC Node |
|---|---|---|
| API Access | Optional | Required |
| Network | Can be private | Usually public-facing |
| Rate Limiting | N/A | Essential |
| Caching | Minimal | Extensive |
Setting Up RPC Node
Section titled “Setting Up RPC Node”# Basic RPC node setup with Gethgeth \ --syncmode full \ --http \ --http.addr 0.0.0.0 \ --http.port 8545 \ --http.api eth,net,web3,debug,txpool \ --ws \ --ws.addr 0.0.0.0 \ --ws.port 85463.7 Bootnodes
Section titled “3.7 Bootnodes”What are Bootnodes?
Section titled “What are Bootnodes?”Bootnodes are special nodes that help new nodes discover and connect to the network. They maintain a list of active peers and share this information with incoming nodes.
How Bootnodes Work
Section titled “How Bootnodes Work”┌─────────────────────────────────────────────────────────────────┐│ BOOTNODE DISCOVERY │├─────────────────────────────────────────────────────────────────┤│ ││ New Node ││ │ ││ │ 1. Connect to Bootnode ││ ▼ ││ ┌─────────────┐ ││ │ Bootnode │────── Return peer list ││ │ (ENR) │ ││ └─────────────┘ ││ │ ││ │ 2. Connect to Peers ││ ▼ ││ ┌─────────┐ ┌─────────┐ ┌─────────┐ ││ │ Peer 1 │ │ Peer 2 │ │ Peer 3 │ ││ └─────────┘ └─────────┘ └─────────┘ ││ │└─────────────────────────────────────────────────────────────────┘Public Bootnodes
Section titled “Public Bootnodes”Ethereum Mainnet:
enode://enr:-KO4QA...@bootnode.mainnet.ethdisco.net:30303Ethereum Goerli Testnet:
enode://enr:-KO4QA...@bootnode.goerli.ethdisco.net:303033.8 Summary Table
Section titled “3.8 Summary Table”| Node Type | Storage | Initial Sync | Use Case |
|---|---|---|---|
| Light | ~1 GB | Minutes | Mobile wallets, quick checks |
| Full | 1-2 TB | Hours-Days | Validation, dApps |
| Archive | 10+ TB | Days-Weeks | Block explorers, analytics |
| Validator | Same as full | Hours-Days | Consensus, block production |
| RPC | Same as full | Hours-Days | API services, dApps |
3.9 Interview Questions
Section titled “3.9 Interview Questions”| Question | Answer |
|---|---|
| Difference between full and light nodes? | Full nodes validate everything; light nodes only headers |
| When to use archive nodes? | Block explorers, analytics, historical queries |
| What is an RPC node used for? | Providing API access for dApps and wallets |
| What is slashing in validators? | Penalty for malicious behavior or downtime |
Summary
Section titled “Summary”- Full Nodes: Complete validation, backbone of network
- Light Nodes: Resource-efficient, for light use cases
- Archive Nodes: Complete history, for analytics/explorers
- Validators: Consensus participation, block production
- RPC Nodes: API access for applications
Next Chapter
Section titled “Next Chapter”In Chapter 4: Node Architecture & Components, we’ll explore the internal architecture of blockchain nodes.
Last Updated: 2026-02-20