0.Ethereum networking

Ethereum has two peer networks. The execution network carries transactions and execution-chain data. The consensus network carries beacon-chain messages and validator operations. The networks use different application stacks, but they meet at the authenticated Engine API on each node.

The two peer networks

The execution network profile uses the devp2p stack. ENRs and DNS lists or UDP discovery find candidates. RLPx authenticates the TCP session. Capability protocols such as eth and snap then exchange execution data. The devp2p source map defines these discovery, transport, and capability protocols.

The consensus network profile uses libp2p. The shared discv5 profile finds ENRs. A client turns a usable ENR into a libp2p peer address, completes the secure channel, and opens gossip or Req/Resp streams. Consensus networking uses these streams for beacon blocks, attestations, validator operations, synchronization, and data-availability messages.

The two networks do not share peer sessions. They share node-record and discovery foundations, and one host can run both stacks on separate endpoints.

Shared foundations

Start with node identity to see why ENR, discv4, RLPx, and libp2p peer IDs use different identity forms. Ethereum node records defines the signed RLP envelope, sequence number, identity scheme, endpoint keys, and 300-byte size limit.

DNS discovery, discv4, and discv5 provide different ways to obtain and check candidates. The execution and consensus profiles add their own fork, capability, and subnet checks after this common discovery step.

Cross-layer control and data flows

The Engine API connection is a local JSON-RPC control channel. Consensus drives execution fork choice, payload construction, payload validation, and blob retrieval through it. The channel uses JWT authentication and a port separate from public JSON-RPC; the default Engine API port is 8551.

The fork-choice and payloads and payload validation pages describe the method versions and result states. The block-production overview connects local payload builds to the beacon block. The Builder API is an external HTTP path for builder-assisted production. It does not replace the Engine API between a consensus client and its execution client.

The data-availability networking pages follow blob sidecars, data-column sidecars, gossip, requests, and retention. These subjects cross the consensus and execution boundary because the consensus block commits to data and the execution client supplies or checks payload data.

Adjacent systems

Portal is a set of content-addressed overlays that uses discv5 messages for transport. It serves historical and other content; it does not become the execution eth session or the consensus gossip mesh.

ethp2p is a future unified L1 networking stack. Its upstream specification pages — ethp2p, erasure-coded broadcast, Reed-Solomon broadcast, and RLNC broadcast — render the pinned upstream documents verbatim. They do not define an active replacement for devp2p or libp2p. Lean records a future consensus implementation profile. Its checked-in implementation is evidence of that profile, not evidence of activation on Ethereum mainnet.

Corpus states

The corpus separates protocol state from authoring state:

• HEAD shows the newest authored page for each topic. It does not change the page's fork or stage.
• Current resolves the active Fusaka and BPO parameter set plus fork-independent protocols. This is the complete system in force at the active network state.
• In progress contains scheduled Glamsterdam and Hegota work, plus independent work with an explicit in-progress stage. It is not active until the schedule and deployment make it active.
• Future contains research and proposals without an activation claim.

A page with since: "*" is independent of the fork schedule. A page with a scheduled since value starts at that fork. A page with stage: in-progress or stage: future keeps its status explicit instead of implying deployment.

Finding a contract

Use the topic tree when you know the layer or subject. Use the wire index for a message, topic, ENR key, or method name. Use the status view for current, in-progress, and future work. Use the sources view to start from a checked-in upstream file. Each page also links to related topics, so a reader can move from a discovery primitive to a layer profile, a cross-layer flow, or an adjacent system without knowing its source repository first.

Reader entry points