Activation
RLPx selects the highest shared eth version. Both peers then send Status
before they send any other eth message.
Status contains:
[version, network-id, genesis-hash, fork-id,
earliest, latest, latest-hash]
fork-id is EIP-2124 [fork-hash, fork-next]. The genesis hash and network ID
identify the chain. The network ID is not necessarily the EIP-155 chain ID.
earliest, latest, and latest-hash describe the full blocks and receipts
that the peer serves. Headers remain available from genesis.
Compatibility
A peer checks version, genesis, network, and ForkID before it activates the session. The ForkID rules accept peers that share the current fork history and have compatible future fork knowledge.
The history range is a serving claim. It does not affect consensus validity.
Request correlation
The chain-data, pooled-transaction, block-access-list, and cell request pairs
start with a requester-chosen unsigned 64-bit request ID. The response repeats
that ID. Status, NewBlockHashes, Transactions, NewBlock,
NewPooledTransactionHashes, and BlockRangeUpdate do not use this envelope.
Size limits
RLPx has a 16 MiB uncompressed limit. The eth specification recommends lower
soft limits for each message. A client can enforce a practical hard limit near
10 MiB.
A peer can return less data because of size, service time, or local policy. The requester uses ordering and protocol-specific continuation fields to separate truncation from unavailable data.
Failure handling
- Do not process other
ethmessages beforeStatus. - Disconnect an incompatible genesis hash or active fork.
- Match every response to a pending request ID.
- Reject malformed RLP and invalid field lengths.
- Treat an advertised history range as untrusted until requests succeed.
Design rationale
RLPx negotiates a message grammar. Status then binds that grammar to one chain
and one fork schedule. History bounds let peers select suitable data providers.
History
eth/64 added ForkID. eth/69 removed total difficulty from Status and added the
available block range.