Networking Layer

 

Networking Layer 


The two brains inside one Ethereum node

Every modern Ethereum node has two separate programs running:

1️⃣ Execution Client (EL)

👉 Think “WHAT happened?”

  • Handles:

    • Transactions

    • Smart contract execution

    • Account balances

    • EVM

  • Examples: Geth, Nethermind, Erigon

2️⃣ Consensus Client (CL)

👉 Think “DO we all agree this happened?”

  • Handles:

    • Blocks

    • Validators

    • Attestations

    • Finality (PoS logic)

  • Examples: Prysm, Lighthouse, Teku

💡 These two must talk to each other, but they also talk to other nodes.

That’s why networking looks complex.

Why TWO P2P networks?

Because different data has different needs.

LayerWhat it gossipsWhy
Execution P2PTransactionsNeed fast spread
Consensus P2PBlocks, attestationsNeed global agreement

So Ethereum uses:

  • Execution-layer P2P network

  • Consensus-layer P2P network

Separate highways 🚧

Step 1: How a new node finds friends (Discovery)

Question:

How does a brand-new node find anyone at all?

Answer: Bootnodes + Discovery

Think like this:

  • You install Ethereum

  • You know nobody

  • Ethereum ships with a few phone numbers hardcoded → bootnodes

Discovery uses UDP (WHY?)

UDP = fast + cheap + no connection

Perfect for:

  • “Hey, I exist”

  • “Who else is here?”

❌ Not for real conversations
✅ Only for finding peers

Discovery flow (very important)

start client
   ↓
connect to bootnode
   ↓
PING → PONG (bonding)
   ↓
FIND_NEIGHBOURS
   ↓
get peer list
   ↓
PING → PONG with peers

After this:
👉 “Okay, I know people now”

What is ENR (Ethereum Node Record)?

Think of ENR as a node’s visiting card:

  • Public key

  • IP address

  • Ports

  • Supported protocols

  • Consensus info (for CL)

Nodes exchange ENRs to know how to talk.

Step 2: Real conversations (DevP2P / libP2P)

Discovery only introduces people.

Now real talking starts.

Execution Layer networking (EL)

Stack:

UDP → Discovery (find peers)
TCP → DevP2P → RLPx → Sub-protocols

Why TCP here?

Because now nodes:

  • exchange transactions

  • need reliability

  • need encryption

  • need session management

RLPx (secure channel)

RLPx does:

  • cryptographic handshake

  • key exchange

  • encrypted communication

Then nodes say “hello” 👋

Hello message includes:

  • client type

  • protocol version

  • supported sub-protocols

Only common protocols are used.

What does Execution layer gossip?

Only this now:

✅ Pending transactions

❌ Blocks (moved to consensus layer after PoS)

Consensus Layer networking (CL)

Consensus does NOT use DevP2P.

It uses:

UDP → discv5
TCP → libP2P

Much more modern.

Why libP2P?

Because consensus needs:

  • high-speed gossip

  • topic-based messaging

  • better scalability

Used in:

  • IPFS

  • Filecoin

  • Ethereum consensus

Two communication styles in CL

1️⃣ Gossip (one → many)

Used for:

  • Beacon blocks

  • Attestations

  • Slashings

Fast spread 🔥

2️⃣ Request–Response (one → one)

Used for:

  • “Give me block X”

  • “Give me blocks from slot A to B”

Precise data 🎯

Why SSZ instead of RLP?

Think performance.

SSZ:

  • Fixed offsets

  • Easy partial decoding

  • Built for Merkle trees

  • Unique encoding (no ambiguity)

Perfect for consensus + hashing.

Step 3: Execution ↔ Consensus communication (Engine API)

Now the most important mental model 

Execution and Consensus are like two apps on the same machine talking via local RPC.

They do NOT gossip with each other over the internet.

When node is NOT block producer

Let’s walk slowly 

1️⃣ Consensus client receives block (from gossip)
2️⃣ Checks:

  • sender valid?

  • metadata correct?

3️⃣ Sends block’s execution payload to execution client
4️⃣ Execution client:

  • runs transactions

  • checks state hashes

5️⃣ Says back:

  • “Yes valid” or “Invalid”

6️⃣ Consensus:

  • adds block

  • attests

  • gossips attestation

When node IS block producer (important)

1️⃣ Consensus client learns:

“You are the proposer”

2️⃣ Consensus → Execution:

“Create a block”

3️⃣ Execution client:

  • pulls transactions from mempool

  • executes them

  • builds execution payload

4️⃣ Consensus client:

  • wraps it into beacon block

5️⃣ Beacon block is gossiped

6️⃣ Other nodes validate → attest → finalize

Comments

Post a Comment

Popular posts from this blog

Frontend-to-Blockchain Flow

Understanding the Frontend-to-Blockchain Flow: A Complete Guide As a Web3 developer, one of the most confusing aspects when starting out is understanding how your frontend actually communicates with the blockchain. Let me break down the entire flow from smart contracts to user interaction. The Complete Development Flow 1. Smart Contract Development & Deployment Your Starting Point: You have an application idea (decentralized, of course!) You write smart contracts with all your application's core logic Choose the right blockchain based on your requirements: Ethereum : Most secure, highest adoption Polygon : Low fees, fast transactions BSC (Binance Smart Chain) : Lower costs, high throughput Avalanche : Fast finality, customizable subnets Deployment Outputs: Contract Address Contract ABI (Application Binary Interface) The Frontend Integration Challenge Now you have a frontend and want users to interact with your deployed contracts. Here's where it gets interestin...
Read more

Top-to-bottom map of how an Ethereum node is structured

 T op-to-bottom map of how an Ethereum node is structured 🔵 TOP LEVEL: The Node A “node” = Execution Client (EL) + Consensus Client (CL) working together. ┌─────────────────────────┐ │ Ethereum Node │ │ (EL client + CL client) │ └─────────────────────────┘ 🔥 1. CONSENSUS CLIENT (CL) Main job: Follow PoS consensus, manage validators, attestations, sync committees, fork-choice. Examples: Prysm, Lighthouse, Teku, Nimbus, Lodestar ✔ Components inside CL Consensus Client │ ├── Beacon Node │ ├── p2p Networking (gossip, sync) │ ├── Beacon Chain database (slots, epochs, states) │ ├── Fork Choice (LMD-GHOST) │ ├── State Transition (processing blocks) │ ├── Sync Committee logic │ └── REST API (for monitoring) │ └── Validator Client ├── Proposer duties ├── Attester duties ├── Aggregator duties ├── Slashing Protection DB └── Signs dut...
Read more

Arbitrum vs Optimism Rollups

Image
  Arbitrum vs Optimism Rollup Big picture first (same for both) Both Optimism and Arbitrum are: Optimistic rollups Assume transactions are correct by default Post: Compressed transaction data to Ethereum (for data availability) State roots to Ethereum Allow fraud proofs during a challenge window (~7 days) So security model = Ethereum L1 Now the real differences are in: Execution model Fraud proof design How user operations are processed internally How user operations (transactions) enter the system Common flow (both) User sends a transaction It goes to a Sequencer Sequencer: Orders transactions Executes them Produces a new L2 state Sequencer submits: Transaction data → Ethereum calldata State root → Ethereum contract Now differences begin. 2️⃣ Optimism: EVM-equivalent, simple execution 🧠 Core idea “Make L2 behave exactly like Ethereum, just cheaper.” How Optimism handles user operations Execution mo...
Read more