DevP2P

This section will cover the networking protocol used by the Execution Layer (EL). First, as it is referred in the networking section, focusing on the transport layer, the two protocols used by DevP2P are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). Both protocols are used to send data over the internet, but they have different characteristics. Just as Tanenbaum points it out (2021),TCP is a connection-oriented protocol, which means that it establishes a connection between the sender and the receiver before sending data. It is reliable because it ensures that the data is delivered in the correct order and without errors. UDP is a connectionless protocol, which means that it does not establish a connection before sending data. It is faster than TCP because it does not have to establish a connection before sending data, but it is less reliable because it does not ensure that the data is delivered in the correct order or without errors.

Transport protocols

EL's networking specs

As a peer-to-peer network Ethereum implies a series of rules to enable communication between its participant nodes. This section cover an explanation of which are those rules and how they are implemented in the EL. Considering each Ethereum node is built upon two different components: the execution client and the consensus client, each one of them has its own peer-to-peer network with its own purpose. The execution client is responsible for gossiping transactions, while the consensus client is responsible for gossiping the blocks.

There are historical reasons for different CL/EL p2p networks and their underlying technologies. Ethereum was originally built on devp2p as its own custom networking stack. By the time Beacon Chain was created, libp2p was ready for production and adopted there. Keeping this in mind, the scope of the EL network covers two different stacks working in parallel: the discovery one, and the information transport itself. The discovery stack is responsible for finding the node peers, while the transport stack is responsible for sending and receiving messages between them. Taking the computer networks background into account, then we can infer that the discovery stack relies on the UDP protocol, while the information exchange stack relies on the TCP protocol. The reason behind this is that the information exchange requires a reliable connection between the nodes, so they can be able to both confirm the connection before sending the data and have a way to ensure that the data is delivered in the correct order and without errors (or at least to have a way to detect and correct them), while the discovery process does not require the reliable connection, since it is enough to let other knows that the node is available to communicate.

Discv protocol (Discovery)

The process of how the nodes find each other in the network starts with the hard-coded bootnodes listed in the specification. The bootnodes are nodes that are known by all the other nodes in the networks (both Mainnet and testnets), and they are used to bootstrap the discovery peers process. Using the Kademlia-like DHT (Distributed Hash Table) algorithm, the nodes are able to find each other in the network by referring to a routing table where the bootnodes are listed. The TLDR of the Kademlia is that it is a peer-to-peer protocol that enables nodes to find each other in the network by using a distributed hash table, as Leffew mentioned in his article (2019).

That is to say, the connection process starts with a PING-PONG game where the new node send a PING message to the bootnode, and the bootnode responds with a PONG hashed message. If both messages match, then the new node is able to bond with the bootnode. In addition to this, the new node sends a FIND-NEIGHBOURS request to the bootnode, so it can receive a list of neighbours that able to connect with, so it can repeat the PING-PONG game with them and bond with them as well.

Peer discovery

Wire protocol

The PING/PONG game is better known as the wire subprotocol, and it includes the next specifications:

PING packet structure

version = 4
from = [sender-ip, sender-udp-port, sender-tcp-port]
to = [recipient-ip, recipient-udp-port, 0]
packet-data = [version, from, to, expiration, enr-seq ...]

PONG packet structure

packet-data = [to, ping-hash, expiration, enr-seq, ...]

The packet-data is wrapped in 1280 bytes UDP datagram alongside with the header:

packet-header = hash || signature || packet-type
hash = keccak256(signature || packet-type || packet-data)
signature = sign(packet-type || packet-data)
packet = packet-header || packet-data

FindNode packet structure (called FIND-NEIGHBOURS above)

packet-data = [target, expiration, ...]

Where the target is a 64-byte secp256k1 node's public key.

Neighbours packet structure

packet-data = [expiration, neighbours, ...]
neighbours = [ip, udp-port, tcp-port, node-id, ...]

Where the neighbours are the list of 16 nodes that are able to connect with the new node.

ENR Request packet structure

packet-data = [expiration]

ENR Response packet structure

packet-data = [request-hash, ENR]

Where ENR is the Ethereum Node Record, a standard format for connectivity for nodes. Which it is explained below.

---

This Kademlia-like protocol includes the routing table, which keeps information about other nodes in the neighbourhood consisting of k-buckets (where k is the number of nodes in the bucket, currently defined as 16). Worth mentioning that all the table entries are sorted by last seen/least-recently seen at the head, and most-recently seen at the tail. If one of the entities has not been responded to in 12 hours, it is removed from the table, and the next encounter node is added to the tail of the list.

Discovery Protocols (Discv4 & Discv5)

Currently, most execution clients have adopted the Discv5 protocol for the discovery process, while some are still transitioning from Discv4. Below is a table categorizing execution clients based on their Discv5 support status (as of May 2025).

Discv4

A structured, distributed system that allows Ethereum nodes to discover peers without central coordination.

• Node Identities

  • Each node is identified by a secp256k1 key pair.
  • The public key serves as the node's unique identifier (Node ID).
  • Distance between nodes is computed using XOR of hashed public keys.

• Node Records (ENR)

  • Nodes store and share connection details using Ethereum Node Records (ENRs).
  • The "v4" identity scheme is used to verify node authenticity.
  • Peers can request a node's latest ENR via an ENRRequest packet.

• Kademlia Table

  • Nodes maintain a routing table with 256 k-buckets (each holding up to 16 entries).
  • A bucket stores nodes within a specific XOR distance range from the local node.
  • The first bucket (index 0) contains nodes farthest from the local node.
  • Higher-indexed buckets store progressively closer peers.
  • New nodes are added to the tail (most recently seen).
  • Old nodes remain at the head (least recently seen) unless they fail liveness checks.

• Lookup Process

  • A recursive lookup is used to locate a target node.
  • The initiator queries the closest known peers in its routing table.
  • Those peers respond with their closest known peers to the target.
  • The process repeats iteratively until the target node is found or no closer peers exist.
  • Concurrency is used, where multiple FindNode queries run in parallel.

Discv5

An improved version of Discv4 with several enhancements:

• Topic Advertisement

  • Nodes can advertise and search for specific topics (e.g., shard committees, Layer 2 protocols).
  • Uses a distributed advertisement system rather than relying on DHT lookups alone.

• Improved Security

  • Uses authenticated encryption (ECIES) for all packet exchanges.
  • Protects against traffic amplification attacks by enforcing request-response pairing.

• Adaptive Routing

  • More efficient neighbor discovery by using multiple concurrent queries.
  • Reduces lookup time and network overhead.

• ENR-Based Identity

  • Full support for Ethereum Node Records (ENRs), which allow richer metadata storage.
  • ENRs include IP addresses, ports, supported capabilities, and cryptographic signatures.

RLPx protocol (Information exchange)

So far, this article has been referring to the discovering protocol only, but what about the secure information exchange process? Well, RLPx is the TCP-based transport protocol that enables secure peer-to-peer communication in the EL. It handles connection establishment, and message exchange between Ethereum nodes. The name comes from the RLP serialization format.

Before deep diving on the protocol, here it is a summary followed by a digram:

• Secure connection through an encrypted authentication
• Session establishment
• Message framing and information exchange

RLPx diagram

Secure connection establishment

Once the nodes are discovered, RLPx establishes a secure connection between them by authenticating each other through cryptographic-based handshake. This process begins by initating an authentication where the initiator node generates an ephemeral key pair using the secp256k1 elliptic curve. This ephemeral key plays a crucial role in establishing perfect forward secrecy for the session. Then the initiator sends an authentication message including the ephemeral public key and a nonce to the recipient, which accepts the connection, decrypts and verify the auth message with the public key exchanged during the communication.

The recipient sends an acknowledge message back to the initiator, and then sends a first encrypted frame containing a Hello message which includes the port, their IDs and their client's IDs, and the protocol information. Once the nodes have authenticated each other, they can start with the communication.

Session and multiplexing

Once the authentication is proven they can interact by creating a secure session first through the following process:

• RLPx uses Elliptic Curve Integrated Encryption Scheme (ECIES) for secure handshaking and session establishment.
• The cryptosystem consists of:
  • Elliptic Curve: secp256k1
  • Key Derivation Function (KDF): NIST SP 800-56 Concatenation KDF
  • Message Authentication Code (MAC): HMAC-SHA-256
  • Encryption Algorithm: AES-128-CTR

Encryption Process

1. Initiator generates a random ephemeral key pair.
2. Computes shared secret using Elliptic Curve Diffie-Hellman (ECDH).
3. Derives encryption (kE) and MAC (kM) keys from the shared secret.
4. Encrypts the message using AES-128-CTR.
5. Computes a MAC over the encrypted message for integrity.
6. Sends the encrypted payload.

Decryption Process

1. Recipient extracts the sender's ephemeral public key.
2. Computes the shared secret using ECDH.
3. Derives kE and kM, then verifies the MAC.
4. Decrypts the message using AES-128-CTR.

Node Identity

• Ethereum nodes maintain a persistent secp256k1 key pair for identity.
• The public key serves as the Node ID.
• The private key is stored securely and remains unchanged across sessions.

Generated Secrets

Static-Shared-Secret vs. Ephemeral-Key

Static-Shared-Secret

• Derived using Elliptic Curve Diffie-Hellman (ECDH) between a node's long-term (static) private key and the peer's long-term public key.
• Remains unchanged across multiple sessions with the same peer.

If an attacker compromises a node's private key, past and future communications with that peer can be decrypted, making it vulnerable to long-term key exposure.

Ephemeral-Key (Forward Secrecy)

• A temporary key pair generated for each handshake, used to derive a fresh session secret.
• Computed using ECDH between ephemeral private keys exchanged during the handshake.

Since ephemeral keys are discarded after a session ends, even if an attacker later obtains a node's long-term private key, past communications remain secure. This property is known as forward secrecy

Message Framing

• Frames encapsulate encrypted messages for efficient and secure communication.
• Multiplexing allows multiple protocols to run over a single RLPx connection.

Frame Structure

MAC Calculation

• Uses two keccak256 MAC states (one for ingress, one for egress).
• The MAC state is updated as frames are sent or received.
• Ensures message integrity and prevents tampering.

Capability Messaging

• Capabilities define the supported protocols on a given connection.
• Multiplexing enables concurrent usage of multiple capabilities.

Message Structure

P2P Capability Messages

• The "p2p" capability is mandatory and used for initial negotiation.

Core Messages

Disconnect Reasons

Application-Level Subprotocols

• RLPx supports multiple application-level subprotocols that enable specialized communication between Ethereum nodes.
• These subprotocols are built on top of the RLPx transport layer and are used for data exchange, state synchronization, and light client support.

Common Ethereum Subprotocols

Further Reading

• Geth devp2p docs
• Ethereum devp2p GitHub
• Ethereum networking layer
• Ethereum Addresses
• Alchemy (2022). How are Ethereum transactions propagated (broadcast)?
• Andrew S. Tanenbaum, Nick Feamster, David J. Wetherall (2021). Computer Networks. 6th edition. Pearson. London.
• Kevin Leffew (2019). "Kademlia usage in the Ethereum protocol". A brief overview of Kademlia, and its use in various decentralized platforms. Medium.