Architecture
Chapter 4: Node Architecture & Components
Section titled “Chapter 4: Node Architecture & Components”Overview
Section titled “Overview”Understanding the internal architecture of blockchain nodes is essential for operators, developers, and anyone building blockchain infrastructure. This chapter breaks down the components that make up a blockchain node and how they interact.
4.1 High-Level Architecture
Section titled “4.1 High-Level Architecture”┌─────────────────────────────────────────────────────────────────────────────┐│ BLOCKCHAIN NODE ARCHITECTURE │├─────────────────────────────────────────────────────────────────────────────┤│ ││ ┌──────────────────────────────────────────────────────────────────────┐ ││ │ EXTERNAL INTERFACE │ ││ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ ││ │ │ JSON │ │ WebSocket │ │ GraphQL │ │ P2P │ │ ││ │ │ RPC │ │ │ │ │ │ Protocol │ │ ││ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ ││ └──────────────────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌──────────────────────────────────────────────────────────────────────┐ ││ │ CORE ENGINE │ ││ │ │ ││ │ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │ ││ │ │ Transaction │ │ Block │ │ Consensus │ │ ││ │ │ Pool │ │ Validator │ │ Engine │ │ ││ │ │ (Mempool) │ │ │ │ │ │ ││ │ └────────────────┘ └────────────────┘ └────────────────┘ │ ││ │ │ ││ │ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │ ││ │ │ State │ │ EVM/VM │ │ Crypto │ │ ││ │ │ Database │ │ Interpreter │ │ Operations │ │ ││ │ └────────────────┘ └────────────────┘ └────────────────┘ │ ││ │ │ ││ └──────────────────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌──────────────────────────────────────────────────────────────────────┐ ││ │ STORAGE LAYER │ ││ │ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │ ││ │ │ Block │ │ State │ │ History │ │ ││ │ │ Database │ │ Database │ │ Database │ │ ││ │ └────────────────┘ └────────────────┘ └────────────────┘ │ ││ └──────────────────────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────────────────────┘4.2 Core Components
Section titled “4.2 Core Components”4.2.1 P2P Network Layer
Section titled “4.2.1 P2P Network Layer”The P2P layer handles communication between nodes in the network.
┌─────────────────────────────────────────────────────────────────┐│ P2P NETWORK LAYER │├─────────────────────────────────────────────────────────────────┤│ ││ ┌────────────────────────────────────────────────────────┐ ││ │ NETWORKING SUBSYSTEM │ ││ │ │ ││ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ ││ │ │ Discovery│ │ Peer │ │ Message │ │ ││ │ │ Protocol │ │ Management│ │ Routing │ │ ││ │ └──────────┘ └──────────┘ └──────────┘ │ ││ │ │ ││ └────────────────────────────────────────────────────────┘ ││ ││ Functions: ││ - Discover other nodes ││ - Establish connections ││ - Propagate transactions/blocks ││ - Handle peer rotation ││ │└─────────────────────────────────────────────────────────────────┘Key Responsibilities:
- Node discovery (bootnodes, discv5)
- Connection management
- Message propagation
- NAT traversal
4.2.2 Transaction Pool (Mempool)
Section titled “4.2.2 Transaction Pool (Mempool)”The mempool holds pending transactions that haven’t been included in a block yet.
┌─────────────────────────────────────────────────────────────────┐│ TRANSACTION POOL │├─────────────────────────────────────────────────────────────────┤│ ││ Incoming Transactions ││ │ ││ ▼ ││ ┌──────────────┐ ┌─────────────────────────────────┐ ││ │ Validation │───▶│ Valid: Add to Mempool │ ││ │ Check │ │ Invalid: Reject │ ││ └──────────────┘ └────────────────┬────────────────┘ ││ │ ││ ▼ ││ ┌───────────────────────┐ ││ │ Mempool │ ││ │ │ ││ │ - By nonce (sender) │ ││ │ - By gas price │ ││ │ - By gas fee │ ││ │ │ ││ └───────────┬───────────┘ ││ │ ││ ▼ ││ ┌───────────────────────┐ ││ │ Block Builder │ ││ │ (Miner/Validator) │ ││ └───────────────────────┘ ││ │└─────────────────────────────────────────────────────────────────┘Mempool Operations:
- Transaction validation
- Ordering (by gas price, nonce)
- Broadcasting to peers
- Clearing when included in block
4.2.3 Block Validator
Section titled “4.2.3 Block Validator”The block validator ensures incoming blocks follow consensus rules.
┌─────────────────────────────────────────────────────────────────┐│ BLOCK VALIDATION │├─────────────────────────────────────────────────────────────────┤│ ││ New Block Received ││ │ ││ ▼ ││ ┌──────────────────────────────────────────────────────┐ ││ │ VALIDATION STEPS │ ││ │ │ ││ │ 1. Header Validation │ ││ │ - Timestamp within range │ ││ │ - Difficulty correct │ ││ │ - Parent hash correct │ ││ │ │ ││ │ 2. Transaction Root │ ││ │ - Merkle proof verification │ ││ │ - Number of transactions │ ││ │ │ ││ │ 3. State Root │ ││ │ - Execute all transactions │ ││ │ - Compare resulting state root │ ││ │ │ ││ │ 4. Signatures │ ││ │ - Verify block producer signature │ ││ │ - Check validator attestations │ ││ │ │ ││ └──────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌────────────────┐ ┌────────────────┐ ││ │ Valid │ │ Invalid │ ││ │ Add to DB │ │ Reject │ ││ └────────────────┘ └────────────────┘ ││ │└─────────────────────────────────────────────────────────────────┘4.2.4 State Database
Section titled “4.2.4 State Database”The state database stores the current state of all accounts and contracts.
Ethereum State Structure:
┌─────────────────────────────────────────────────────────────────┐│ ETHEREUM STATE DATABASE │├─────────────────────────────────────────────────────────────────┤│ ││ ┌─────────────────────────────────────────────────────────┐ ││ │ WORLD STATE │ ││ │ │ ││ │ Account: 0x742d35Cc6634C0532925a3b844Bc9e7595f... │ ││ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ nonce: 5 │ │ ││ │ │ balance: 1000000000000000000 (1 ETH) │ │ ││ │ │ codeHash: abcd1234... │ │ ││ │ │ storageRoot: efgh5678... │ │ ││ │ └─────────────────────────────────────────────────┘ │ ││ │ │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Stored as: Patricia Merkle Trie ││ - Efficient key-value lookups ││ - Cryptographic integrity verification ││ - Snapshots for historical states ││ │└─────────────────────────────────────────────────────────────────┘4.2.5 Virtual Machine (EVM)
Section titled “4.2.5 Virtual Machine (EVM)”The Ethereum Virtual Machine executes smart contract bytecode.
┌─────────────────────────────────────────────────────────────────┐│ ETHEREUM VIRTUAL MACHINE │├─────────────────────────────────────────────────────────────────┤│ ││ Transaction (to smart contract) ││ │ ││ ▼ ││ ┌────────────────────────────────────────────────────────┐ ││ │ EVM EXECUTION │ ││ │ │ ││ │ 1. Load contract code │ ││ │ 2. Initialize EVM state │ ││ │ 3. Execute bytecode (opcodes): │ ││ │ - PUSH, POP, DUP, SWAP │ ││ │ - ADD, MUL, SUB, DIV │ ││ │ - CALL, DELEGATECALL, STATICCALL │ ││ │ - SLOAD, SSTORE │ ││ │ - CREATE, CALLCODE │ ││ │ 4. Calculate gas consumption │ ││ │ 5. Update state │ ││ │ │ ││ └────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌────────────────┐ ┌────────────────┐ ││ │ Success │ │ Revert │ ││ │ - State DB │ │ - Gas used │ ││ │ - Gas left │ │ - Error msg │ ││ └────────────────┘ └────────────────┘ ││ │└─────────────────────────────────────────────────────────────────┘4.3 Execution vs Consensus Clients (Ethereum)
Section titled “4.3 Execution vs Consensus Clients (Ethereum)”After The Merge, Ethereum uses a dual-client architecture:
┌─────────────────────────────────────────────────────────────────────────────┐│ ETHEREUM POST-MERGE ARCHITECTURE │├─────────────────────────────────────────────────────────────────────────────┤│ ││ ┌───────────────────────────────────────────────────────────────────┐ ││ │ EXECUTION LAYER (EL) │ ││ │ │ ││ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ││ │ │ Geth │ │ Erigon │ │ Besu │ │ ││ │ │ (Go) │ │ (Go) │ │ (Java) │ │ ││ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ ││ │ │ │ │ │ ││ │ ┌──────┴────────────────┴────────────────┴──────┐ │ ││ │ │ │ │ ││ │ │ - Transaction Pool (Mempool) │ │ ││ │ │ - State Management │ │ ││ │ │ - EVM Execution │ │ ││ │ │ - Block Building │ │ ││ │ │ - JSON-RPC API │ │ ││ │ │ │ │ ││ │ └──────────────────────┬───────────────────────┘ │ ││ └──────────────────────────┼────────────────────────────────────┘ ││ │ ││ │ Engine API (JWT Auth) ││ ▼ ││ ┌──────────────────────────┼────────────────────────────────────┐ ││ │ CONSENSUS LAYER (CL) │ ││ │ │ ││ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ││ │ │ Lighthouse │ │ Prysm │ │ Teku │ │ ││ │ │ (Rust) │ │ (Go) │ │ (Java) │ │ ││ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ ││ │ │ │ │ │ ││ │ ┌──────┴────────────────┴────────────────┴──────┐ │ ││ │ │ │ │ ││ │ │ - Beacon Chain │ │ ││ │ │ - Block Proposals │ │ ││ │ │ - Attestations │ │ ││ │ │ - Validator Management │ │ ││ │ │ - Fork Choice │ │ ││ │ │ │ │ ││ │ └───────────────────────────────────────────────┘ │ ││ └───────────────────────────────────────────────────────────────────┘ ││ ││ Communication: Engine API (JSON-RPC over JWT) ││ │└─────────────────────────────────────────────────────────────────────────────┘4.4 Data Storage Architecture
Section titled “4.4 Data Storage Architecture”Block Storage
Section titled “Block Storage”┌─────────────────────────────────────────────────────────────────┐│ BLOCK STORAGE │├─────────────────────────────────────────────────────────────────┤│ ││ ┌─────────────────────────────────────────────────────────┐ ││ │ LevelDB / RocksDB / LMDB │ ││ │ │ ││ │ Key-Value Database │ ││ │ │ ││ │ ┌────────────┬──────────────────┐ │ ││ │ │ Key │ Value │ │ ││ │ ├────────────┼──────────────────┤ │ ││ │ │ h:0x0000.. │ Block #0 (Genesis) │ ││ │ │ h:0x0001.. │ Block #1 │ │ ││ │ │ h:0x0002.. │ Block #2 │ │ ││ │ │ ... │ ... │ │ ││ │ │ h:0xFFFF.. │ Block #65535 │ │ ││ │ └────────────┴──────────────────┘ │ ││ │ │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ Additional Indexes: ││ - Transaction hash → Block number ││ - Address → Balance (Merkle Trie) ││ │└─────────────────────────────────────────────────────────────────┘4.5 Interview Questions
Section titled “4.5 Interview Questions”| Question | Answer |
|---|---|
| What are the main components of a blockchain node? | P2P layer, mempool, block validator, state DB, VM |
| What’s the difference between execution and consensus clients? | Execution handles transactions/EVM; consensus handles block production |
| How does the EVM work? | Executes smart contract bytecode, manages state changes |
| What is a mempool? | Transaction pool holding pending transactions |
Summary
Section titled “Summary”- Blockchain nodes have multiple layered components
- P2P networking handles node communication
- Mempool manages pending transactions
- Block validator ensures consensus compliance
- State database tracks account balances and contracts
- Ethereum now uses dual-client (execution + consensus) architecture
Next Chapter
Section titled “Next Chapter”In Chapter 5: Blockchain Consensus Mechanisms, we’ll explore how nodes agree on the state of the blockchain.
Last Updated: 2026-02-20