How the Ethereum P2P Network Works

Ethereum is often described as a "world computer," but that computer only works because thousands of nodes across the globe continuously gossip with each other, propagating transactions, blocks, and now blobs through a peer-to-peer network that has no central server, no master coordinator, and no single point of failure. Understanding how this network actually functions at the protocol level reveals a layered architecture that, surprisingly, shares deep structural similarities with how BGP holds the internet together: both rely on decentralized gossip between autonomous peers to converge on a consistent global view of state.

This article digs into every layer of the Ethereum P2P stack, from raw transport encryption to consensus-layer gossip, blob propagation, MEV infrastructure, and the client diversity that keeps it all resilient.

The Two-Layer Architecture

Since The Merge in September 2022, Ethereum runs as two coupled but distinct networks. The execution layer (EL) handles transactions, smart contracts, and state. The consensus layer (CL) handles proof-of-stake consensus, validator duties, and finality. Each layer has its own P2P protocol stack, its own discovery mechanism, and its own gossip semantics. They communicate locally via the Engine API, but their network protocols are entirely different.

This dual-stack design is unique among blockchains. Bitcoin uses a single P2P protocol. Ethereum originally did too, but the switch to proof-of-stake required adding a new consensus network built on entirely different foundations. The result is that every Ethereum node actually runs two P2P clients that discover, connect to, and gossip with peers independently.

The devp2p Protocol Stack

The execution layer's networking is built on devp2p, a protocol suite designed specifically for Ethereum in its early days. devp2p has three core components: node discovery, the RLPx transport protocol, and application-level sub-protocols like the eth wire protocol.

At its heart, devp2p solves the same fundamental problem that BGP solves for internet routing: how do autonomous participants discover each other, establish trust, and propagate information reliably across an unreliable network? Where BGP peers exchange route advertisements over TCP sessions, Ethereum nodes exchange transactions and blocks over encrypted devp2p connections. The architectural parallel runs deep: both protocols use a form of path-vector gossip where information fans out through the network peer by peer, and both must handle conflicting information (route hijacks in BGP, competing chain forks in Ethereum) through well-defined resolution rules.

RLPx Transport

RLPx is the encrypted transport protocol that underlies all execution-layer communication. When two Ethereum nodes connect, they perform a cryptographic handshake based on the ECIES (Elliptic Curve Integrated Encryption Scheme) algorithm using secp256k1 keys — the same elliptic curve used for Ethereum accounts and transactions.

The handshake works as follows:

The initiator sends an auth message containing its public key, a signature, a random nonce, and an ephemeral public key, all encrypted with the recipient's public key.
The recipient decrypts this, verifies the signature, generates its own ephemeral key and nonce, and responds with an auth-ack message.
Both sides derive symmetric encryption keys (AES-256-CTR for data, SHA-256 HMAC for integrity) from the shared secrets established during the exchange.

After the handshake, all communication is encrypted and authenticated. Messages are framed with RLP (Recursive Length Prefix) encoding — Ethereum's canonical serialization format. Each frame carries a capability-specific message ID, allowing multiple sub-protocols to be multiplexed over a single connection.

Capabilities and Sub-Protocols

After establishing an RLPx connection, nodes exchange a Hello message that advertises their supported capabilities. A capability is a named sub-protocol with a version number. The most important capability is eth/68 (the current version of the Ethereum wire protocol), but nodes may also advertise snap/1 (for fast state synchronization) or les/4 (for light clients, though this is being deprecated).

This capability negotiation is elegant: it allows the protocol to evolve without breaking backward compatibility. Two nodes only communicate using capabilities they both support. If a newer node supports eth/69 but its peer only knows eth/68, they fall back to the common version.

Node Discovery: Finding Peers

Before nodes can exchange data, they need to find each other. Ethereum uses a distributed hash table (DHT) based on the Kademlia algorithm for peer discovery. There are two versions in use: discv4 on the execution layer and discv5 on the consensus layer.

Kademlia and XOR Distance

Kademlia organizes nodes in a virtual space where "distance" between two nodes is defined as the XOR of their node IDs. This is not geographic or network distance — it is purely mathematical. Each node maintains a routing table of k-buckets, where bucket i contains up to k nodes that are at XOR distance between 2ⁱ and 2ⁱ⁺¹ from itself. The standard value of k in Ethereum is 16.

This structure has a useful property: each node knows many peers that are "close" to it (in XOR space) and progressively fewer peers that are "far" away. To find any node in the network, a lookup converges in O(log n) steps by iteratively querying nodes that are closer and closer to the target ID. This is similar to how BGP route lookups converge through longest-prefix matching — each hop in the routing table gets you closer to the most specific match.

discv4: The Original Discovery Protocol

discv4 operates over UDP and implements four basic message types: Ping, Pong, FindNode, and Neighbors. A node joins the network by knowing at least one bootnode (hardcoded addresses maintained by the Ethereum Foundation and client teams). It pings the bootnode, receives a response, and then uses FindNode queries to populate its routing table by searching for nodes near its own ID.

discv4 has limitations: it cannot advertise what capabilities a node supports, so a node might discover a peer only to find out after connecting via RLPx that the peer does not support the needed sub-protocol. This wastes connection attempts.

discv5: The Next Generation

discv5 solves discv4's limitations by adding topic advertisement. Nodes can register themselves under specific "topics" (like "eth" or "beacon"), and searchers can look for nodes by topic. discv5 also uses a proper ECDH key agreement with AES-GCM encryption for its UDP packets, improving security over discv4's simpler scheme.

The consensus layer exclusively uses discv5 for peer discovery. Execution-layer clients are transitioning to discv5 as well, though many still support discv4 for backward compatibility.

Execution Layer Gossip: The eth Protocol

The eth protocol (currently at version 68) defines how execution-layer nodes exchange transactions and blocks. It runs over RLPx connections discovered through the methods described above.

Transaction Propagation

When a user submits a transaction (say, a token transfer or a swap on Uniswap), it enters the submitting node's mempool (memory pool) — a holding area for unconfirmed transactions. The node then announces the transaction to its peers using a NewPooledTransactionHashes message, which contains just the transaction hashes, not the full transaction data.

Peers that do not already have these transactions respond with GetPooledTransactions to fetch the full transaction bodies. This hash-first approach is a bandwidth optimization: most peers will already have recently announced transactions, so there is no point sending the full data proactively. However, for a small fraction of peers (typically the square root of the peer count), the full transaction is sent directly via Transactions messages to ensure fast initial propagation.

This two-tier approach — direct push to a few peers, hash announcement to the rest — is remarkably similar to how BGP route announcements propagate. In BGP, a router sends full updates to its direct peers, who then selectively propagate them further. Both systems balance speed of propagation against bandwidth efficiency.

Block Propagation

When a new block is produced, it propagates through two complementary mechanisms:

Block announcement via NewBlockHashes — nodes announce the hash of the new block to peers, who can then request the full block with GetBlockHeaders and GetBlockBodies.
Direct block broadcast via NewBlock — the full block (header + body) is pushed directly to a subset of peers for speed.

After The Merge, block propagation changed significantly. The consensus layer now drives block production (validators propose blocks at 12-second intervals called slots), and the execution layer's block gossip serves more as a secondary propagation path. The primary path is through the consensus layer's GossipSub network.

Consensus Layer Gossip: libp2p and GossipSub

The consensus layer abandoned devp2p entirely and built its networking on libp2p, a modular networking framework originally created for IPFS. libp2p provides transport multiplexing, peer identity, encryption (Noise protocol framework), and a pub/sub messaging system called GossipSub.

How GossipSub Works

GossipSub (specifically GossipSub v1.1, used by Ethereum) organizes nodes into topic-based mesh networks. Each node maintains a mesh of D peers (target degree, typically 8) for each topic it subscribes to. When a node receives a message on a topic, it forwards it to all mesh peers for that topic. In addition, it sends lightweight metadata (message IDs, called IHAVE/IWANT) to additional gossip peers outside the mesh, providing a fallback propagation path.

The key topics in Ethereum's consensus layer include:

beacon_block — new beacon blocks proposed by validators
beacon_aggregate_and_proof — aggregated attestations
beacon_attestation_{subnet_id} — individual attestations, partitioned across 64 subnets
voluntary_exit — validator exits
proposer_slashing / attester_slashing — evidence of validator misbehavior
sync_committee_contribution_and_proof — sync committee messages for light clients
blob_sidecar_{subnet_id} — EIP-4844 blob data (post-Dencun)

GossipSub includes a scoring system that evaluates peer behavior. Peers that consistently send invalid messages, fail to forward messages promptly, or flood the network get negative scores. Low-scoring peers are pruned from the mesh and eventually disconnected. This is Ethereum's defense against spam and eclipse attacks at the gossip layer.

Attestation Subnets

With over 1,000,000 active validators (as of 2026), broadcasting every attestation to every node would consume enormous bandwidth. Instead, validators are divided into 64 attestation subnets. Each validator subscribes to specific subnets based on their committee assignment, which rotates every epoch (6.4 minutes). Aggregators on each subnet combine individual attestations into a single aggregate, which is then broadcast to the global topic.

This subnet architecture is a form of network sharding — dividing the gossip load so that no single node needs to process all messages. It is conceptually analogous to how CIDR prefix aggregation in BGP reduces the size of the global routing table by combining specific routes into summary announcements.

EIP-4844: Blob Propagation

The Dencun upgrade (March 2024) introduced EIP-4844 (Proto-Danksharding), adding a new data type called blobs to Ethereum. Blobs are large chunks of data (up to ~128 KB each) attached to transactions, designed to provide cheap data availability for Layer 2 rollups like Arbitrum, Optimism, and Base.

Blobs introduced a new challenge for the P2P network. Unlike regular transaction data, which is stored permanently on-chain, blobs are ephemeral — they are guaranteed to be available for approximately 18 days (4096 epochs) and then pruned. This has deep implications for how they propagate:

Sidecar propagation — blobs travel separately from their parent block as "blob sidecars." Each sidecar contains the blob data plus a KZG commitment (a polynomial commitment scheme) that proves the blob corresponds to the commitment in the block header.
Dedicated subnets — blob sidecars are gossiped on dedicated blob_sidecar_{subnet_id} topics. Initially there were 6 blob subnets; the Pectra upgrade (2025) increased the maximum to 9 blobs per block and expanded capacity further.
Data availability sampling (DAS) — Full Danksharding (the end goal) will allow nodes to verify blob availability without downloading the full blob data, using KZG commitments and erasure coding. The P2P layer will eventually need to support DAS queries, requiring new request-response protocols.

The blob propagation subsystem adds significant load to the network. Each blob is ~128 KB, and with up to 6-9 blobs per block every 12 seconds, the network must move an additional 0.8-1.4 MB of data per slot through the gossip mesh. This is why blob count limits are carefully managed — too many blobs could overwhelm nodes with limited bandwidth.

Block Lifecycle: From Proposal to Finality

A block's journey through the network follows a precise choreography within each 12-second slot:

Block building (t=0s) — The selected proposer validator constructs a block (or receives one from a builder via MEV-Boost; see below).
Block gossip (t=0s) — The block is published to the beacon_block GossipSub topic. It propagates through the mesh in under 1 second to most of the network.
Verification (t=0-4s) — Receiving nodes verify the block: checking the proposer signature, executing all transactions via the execution layer (Engine API), and validating state transitions.
Attestation (t=4s) — The committee of validators assigned to this slot casts attestation votes on the block they consider the head of the chain. Attestations are published to subnet-specific GossipSub topics.
Aggregation (t=8s) — Aggregators collect attestations from their subnet and publish the aggregated result to the global beacon_aggregate_and_proof topic.
Finality (~2 epochs / ~13 minutes) — Once two-thirds of all active validators have attested to a block through the Casper FFG finality gadget, the block is finalized and cannot be reverted.

The tight timing within each slot means P2P latency is critical. A block that arrives late (after the 4-second attestation deadline) may receive fewer attestations, hurting the proposer's rewards. This creates a strong incentive for nodes to maintain well-connected gossip meshes with low-latency peers.

The Transaction Mempool

The mempool is each node's local view of pending transactions. There is no single global mempool — each node maintains its own pool, and transactions propagate through gossip. This means different nodes may have slightly different views of which transactions are pending at any given moment.

The mempool serves several functions:

Transaction staging — transactions wait here until they are included in a block by a validator
Validation — nodes check transaction signatures, nonce ordering, and gas limits before accepting transactions into the pool and relaying them
Prioritization — transactions with higher gas prices (priority fees) are generally included first, since they are more profitable for block builders
Eviction — when the mempool is full, low-priority transactions are dropped

After EIP-1559, each transaction specifies a maxFeePerGas and a maxPriorityFeePerGas. The base fee is burned, and the priority fee goes to the block proposer. Mempool management must account for the dynamic base fee — a transaction that is valid now may become invalid in the next block if the base fee rises above its maxFeePerGas.

Client Diversity

One of Ethereum's unique strengths is its multi-client architecture. Unlike Bitcoin (dominated by Bitcoin Core) or most other blockchains, Ethereum has multiple independent implementations of both the execution and consensus layers, each written in a different programming language.

Execution Layer Clients

Geth (Go) — the original Ethereum client, maintained by the Ethereum Foundation. Historically dominant (60-80% of the network), though the community actively works to reduce its supermajority share.
Nethermind (C#/.NET) — a performant client popular with institutional stakers, known for its advanced tracing and analytics capabilities.
Besu (Java) — maintained by Consensys (now Hyperledger), designed for enterprise use with features like permissioning and privacy.
Erigon (Go) — a fork of Geth with a completely redesigned database architecture, optimized for archival nodes and disk efficiency.
Reth (Rust) — the newest production client, developed by Paradigm. Its modular Rust architecture makes it a foundation for custom node implementations and rollup infrastructure.

Consensus Layer Clients

Prysm (Go) — developed by Prysmatic Labs (now Offchain Labs). Was the most popular CL client at launch, though its share has decreased toward healthier distribution.
Lighthouse (Rust) — developed by Sigma Prime. Known for its performance and security focus, with a strong track record in formal auditing.
Teku (Java) — developed by Consensys. Emphasizes enterprise features and runs alongside Besu for all-Consensys stacks.
Lodestar (TypeScript) — developed by ChainSafe. The only JavaScript/TypeScript implementation, important for browser-based and light client use cases.
Nimbus (Nim) — developed by Status. Designed for resource-constrained devices like Raspberry Pis, proving that consensus participation does not require powerful hardware.

Why Client Diversity Matters for the Network

If a single client has a supermajority (greater than two-thirds of validators) and that client has a consensus bug, the faulty chain could be finalized before the bug is detected. Validators running the buggy client would then face inactivity leak penalties or slashing for having attested to an incorrect chain. With client diversity, a bug in one client affects only a minority of validators, and the network continues correctly with the remaining clients.

This is a distinctly different resilience model than what we see in internet routing. BGP has a practical monoculture problem too — a bug in a dominant router operating system (say, Cisco IOS or Juniper Junos) could cause cascading routing failures across the internet, much like a BGP hijack but caused by software rather than misconfiguration. Ethereum's multi-client approach is a deliberate architectural choice to avoid this single-point-of-failure risk.

MEV and Proposer-Builder Separation (PBS)

Maximal Extractable Value (MEV) refers to the profit a block producer can earn by strategically ordering, inserting, or censoring transactions within a block. MEV has profound implications for the P2P network because it has spawned an entire parallel infrastructure for block construction.

The MEV Supply Chain

In the current PBS architecture (implemented through MEV-Boost, a middleware by Flashbots), the block production process is split into specialized roles:

Searchers — scan the mempool for MEV opportunities (arbitrage, liquidations, sandwich attacks). They construct bundles of transactions and submit them to builders.
Builders — assemble complete blocks by combining searcher bundles with regular mempool transactions. They bid for the right to have their block included.
Relays — act as trusted intermediaries between builders and proposers. They verify builder blocks, hold them in escrow, and forward the highest bid to the proposer.
Proposers (validators) — instead of building their own block, they query relays for the most profitable block and publish it.

This architecture means that most Ethereum blocks (roughly 90% as of 2025-2026) are not built by the proposing validator at all. The validator simply selects the highest-bidding builder's block and signs it. The P2P network carries the final block through normal GossipSub channels, but the block's contents are determined through an off-protocol marketplace.

The Ethereum community is working toward enshrined PBS (ePBS), which would move this builder-proposer separation into the protocol itself, replacing the trust assumptions of external relays with cryptographic guarantees. This will require new P2P message types and gossip topics to support in-protocol builder auctions.

Network Topology and Connectivity

The Ethereum P2P network is a largely unstructured overlay. Nodes connect to 25-50 peers on the execution layer and maintain GossipSub meshes of 8-12 peers per topic on the consensus layer. The network has several topological characteristics worth noting:

Small-world property — despite having thousands of nodes, most messages reach the entire network within 3-6 hops. Research measurements show that new blocks reach over 95% of the network within 2 seconds.
Geographic distribution — nodes are concentrated in North America and Europe, with growing presence in Asia. Unlike BGP routers, Ethereum nodes are not tied to physical network infrastructure — anyone with a consumer internet connection can run one.
Cloud concentration — a significant portion of nodes (estimated 30-50%) run on cloud providers like AWS, Google Cloud, and Hetzner. This creates a centralization risk: if a major cloud provider experiences an outage or decides to ban Ethereum nodes, it could temporarily reduce the network's capacity. However, the remaining home stakers and non-cloud nodes would continue to operate, and the network would recover as cloud-based nodes come back online.
NAT traversal — many nodes run behind Network Address Translation. libp2p supports hole-punching and relay protocols to help NAT'd nodes receive incoming connections, improving their connectivity.

The network's topology is constantly shifting as nodes join, leave, and re-establish connections. This dynamism is a feature, not a bug — it makes the network resilient to targeted attacks. An attacker cannot predict the topology because it changes continuously. Compare this to BGP, where the topology of autonomous system interconnections is relatively stable and well-known through public data (you can explore it by looking up any ASN). Ethereum's opaque, shifting topology is a deliberate security property.

Comparing Ethereum Gossip to BGP

At a conceptual level, Ethereum's P2P gossip and the internet's BGP routing protocol solve remarkably similar problems through different means. Both need to disseminate state information across a decentralized network of autonomous participants who do not fully trust each other.

State propagation — BGP propagates IP prefix reachability through route advertisements. Ethereum propagates transactions through mempool gossip and blocks through GossipSub. Both use a fan-out mechanism where each node forwards to its peers.
Convergence — BGP converges on consistent routing tables across the internet, though convergence can take minutes after a change. Ethereum converges on a canonical chain through attestations and finality, which takes about 13 minutes. Both tolerate temporary inconsistency (different routers seeing different best paths; different nodes seeing different chain heads).
Conflict resolution — BGP resolves conflicting route announcements through its best-path selection algorithm (shortest AS path, local preference, etc.). Ethereum resolves competing chain forks through LMD-GHOST (Latest Message Driven, Greedy Heaviest Observed Sub-Tree), which selects the fork with the most attestation weight.
Security — BGP is vulnerable to route hijacking because it lacks built-in authentication; RPKI is being deployed to address this. Ethereum's consensus layer authenticates all messages via BLS signatures, making message forgery computationally infeasible. In this regard, Ethereum's gossip is more secure by design than BGP.
Peer management — BGP routers maintain explicit peering sessions with configured neighbors. Ethereum nodes dynamically discover peers through DHT-based discovery. Both need to handle peer failures gracefully.

An interesting divergence: BGP operates on a policy-rich model where each autonomous system applies complex routing policies based on business relationships (peering, transit). Ethereum nodes are policy-minimal — they forward all valid messages to all mesh peers. The incentive alignment comes from the economic layer (staking rewards and slashing), not from per-peer policy decisions.

Future Directions

The Ethereum P2P layer continues to evolve. Several major changes are on the horizon:

PeerDAS (Peer Data Availability Sampling) — extending the P2P layer to support data availability sampling for full Danksharding. Nodes will be able to verify blob availability by downloading only small random samples, requiring new request-response protocols and gossip topics for distributing erasure-coded data columns.
Enshrined PBS — moving proposer-builder separation into the protocol, replacing MEV-Boost relays with in-protocol builder auctions. This will add new gossip topics for builder bids and execution payloads.
Verkle trees — replacing Merkle Patricia trees with Verkle trees for state storage. This enables stateless clients that can verify blocks without maintaining the full state trie, dramatically reducing node requirements and potentially enabling new P2P sync protocols.
Portal Network — a new overlay network for ultra-light clients, using a DHT to distribute historical data, state data, and block headers. This would allow resource-constrained devices (phones, browsers) to interact with Ethereum without trusting a centralized RPC provider, similar to how a BGP looking glass provides a read-only view of routing data without requiring you to run a BGP router.
SSZ over RLP — the consensus layer already uses Simple Serialize (SSZ) for encoding. There is ongoing work to migrate the execution layer from RLP to SSZ as well, unifying the serialization format across both layers.

The Ethereum P2P network is one of the most sophisticated distributed systems in production. Its layered architecture, multi-client design, and continuously evolving protocol stack demonstrate how a decentralized network can operate reliably at global scale — processing tens of thousands of transactions per day while maintaining security properties that even the internet's own routing infrastructure (via BGP) does not yet fully achieve. You can explore the actual internet infrastructure that carries Ethereum's traffic by looking up the IP addresses of Ethereum bootnodes, CDN endpoints, and RPC providers in our looking glass.