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 an Ethereum Light Client# NOTE: Geth removed light-mode sync in v1.13 (2023). Use a dedicated light client:# - Go-Zero / Geth "les" servers no longer practical; modern options:# - Helios (Rust, RPC-based light client)# - Lodestar light-client (TypeScript)# - nimbus-eth1 / other header-based light clientsAdvantages
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
⚠️ Ecosystem note: “Light node” means different things per chain. Ethereum deprecated geth
--syncmode light(v1.13); light access now happens through dedicated light clients (e.g., Helios) using beacon-chain sync committees. Cosmos chains support light clients natively via Tendermint/CometBFT light-block verification (no full node required). Bitcoin light nodes use SPV headers-only + Merkle proofs.
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 Sentry Nodes
Section titled “3.8 Sentry Nodes”What is a Sentry Node?
Section titled “What is a Sentry Node?”A sentry node is a full node deployed between a validator node and the public P2P network. The validator connects only to its sentry nodes (private, trusted connections); the sentries accept public connections from the rest of the network. This hides the validator’s IP address and shields it from direct peer-based attacks (DDoS, eclipse attacks, gossip flooding).
┌─────────────────────────────────────────────────────────────────┐│ SENTRY ARCHITECTURE │├─────────────────────────────────────────────────────────────────┤│ ││ PUBLIC P2P NETWORK ││ ┌──────────────┐ ┌──────────────┐ ││ │ Peer A │◄─────►│ SENTRY 1 │ ││ └──────────────┘ └──────┬───────┘ ││ ┌──────────────┐ ┌──────┴───────┐ ││ │ Peer B │◄─────►│ SENTRY 2 │ ││ └──────────────┘ └──────┬───────┘ ││ (attackers, DDoS, eclipse │ ││ all hit the sentries) │ private/static peers ││ ▼ ││ ┌──────────────┐ ││ │ VALIDATOR │ (IP hidden) ││ │ (no public │ ││ │ listeners) │ ││ └──────────────┘ ││ │└─────────────────────────────────────────────────────────────────┘Why Sentries Matter
Section titled “Why Sentries Matter”| Risk | How sentries mitigate it |
|---|---|
| DDoS | Attackers see the sentry IP, not the validator IP; swap sentries to heal |
| Eclipse attack | Validator only talks to trusted sentries, so adversaries can’t fill its peer table |
| IP disclosure | Validator’s public IP can be kept entirely private |
| Gossip flooding | Sentries filter/absorb hostile traffic |
Where Sentry Architectures Are Used
Section titled “Where Sentry Architectures Are Used”- Cosmos/CometBFT validators — the classic sentry setup (documented in CometBFT’s own validator guide). Validator runs
--p2p.pex=false --p2p.persistent_peers=<sentry addrs>; sentries run publicly with--p2p.pex=true. - Ethereum validators — beacon nodes are hardened by tying them to trusted peers and using a firewall/lb; full sentry meshes are rarer because EL/CL P2P is more open, but large staking providers use similar isolation.
- Polkadot validators — official docs recommend the validator’s node communicate through a separate “public” node and proxied RPC.
Key Points
Section titled “Key Points”- Sentries run the same full-node software but don’t hold validator keys.
- Connectivity between validator and sentries should use static/trusted peer lists and private networks (VPN/VPC).
- You need at least 2-3 sentries for redundancy (a validator with a single sentry is a single point of failure).
- Sentries must be on different physical/cloud locations from each other.
3.9 Summary Table
Section titled “3.9 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 |
| Sentry | Same as full | Hours-Days | Firewall/relay in front of validators |
| Bootnode | Minimal | N/A | Initial peer discovery |
3.10 Interview Questions
Section titled “3.10 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
- Sentry Nodes: Shield validators from the public network
- Bootnodes/Seeds: Initial bootstrap of peer discovery
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