Stack
The execution peer network has three main layers:
- DNS discovery, discv4, or discv5 supplies candidate nodes.
- RLPx authenticates a TCP connection and negotiates capabilities.
ethmaintains chain and transaction exchange.snapcan add state sync.
ENRs carry discovery identity and endpoints. The RLPx Hello message selects
the application protocols that one connection can carry.
Required and optional protocols
An execution peer that exchanges mainnet chain data uses the eth capability.
The snap capability is optional and depends on a simultaneous eth session.
Discovery methods are complementary. A client can use static bootnodes, signed DNS trees, discv4, and discv5 at the same time.
Size and resource boundaries
RLPx rejects messages whose uncompressed form is larger than 16 MiB. The eth
specification recommends lower message-specific limits, usually 2 MiB for bulk
responses and about 10 MiB as a practical hard bound.
Peers apply local request, response, bandwidth, and connection limits. A local limit does not change the wire encoding or request ID.
Session establishment
- Find a candidate endpoint.
- Open TCP and complete the RLPx cryptographic handshake.
- Exchange
p2pHellomessages. - Select the highest shared capability versions.
- Exchange
ethStatus. - Start chain, history, transaction, and optional state-sync work.
Failure boundaries
Discovery failure does not prove a transport fault. A valid RLPx session does
not prove that the peer belongs to the same chain. eth Status performs that
chain check.
A client keeps identity, chain compatibility, message validity, and reputation as separate decisions.
Design rationale
The stack separates finding a node from trusting a connection and selecting an application. Optional capabilities can evolve without replacing discovery or the encrypted transport.
History
The execution network began with discv4, RLPx, and eth. ENRs, DNS discovery,
discv5, and snap later added new discovery and synchronization paths.