Abstract
This EIP modifies the 'eth' p2p protocol to announce the historical block range served by
the node. We also simplify the handshake to remove total difficulty information, which
isn't used anymore after the merge. Additionally we propose to remove the Bloom field
from receipts transferred over the protocol.
Motivation
Block range in Status message
In the history expiry working group, it was decided that clients may drop pre-merge
history from their storage after May 1, 2025. For clients that want to sync history
through the 'eth' protocol, it is essential to know whether a peer still serves old
history. A similar idea was proposed in EIP-7542 but was later withdrawn
because a political decision on history expiry had not been reached at the time.
Removing Bloom in Receipts
We recently discovered that none of the clients store the Bloom field of the receipts as
it can be recomputed on demand. However the networking spec requires the Bloom field to
be sent over the network. Thus a syncing node will ask for the Bloom filters for all
receipts. The serving node will regenerate roughly 530GB of bloom filters (2.3B txs * 256
byte). These 530GBs are send over the network to the syncing peer, the syncing peer will
verify them and not store them either. This adds an additional 530GB of unnecessary
bandwidth to every sync.
BlockRangeUpdate message
We want clients to be aware of the available block range in their peers. The new
notification message can be used to detect sync status of peers, and adjust fetching
behavior accordingly.
Specification
Status message changes
Modify the Status (0x00) message as follows:
(eth/68): [version: P, networkid: P, td: P, blockhash: B_32, genesis: B_32, forkid]
(eth/69): [version: P, networkid: P, genesis: B_32, forkid, earliestBlock: P, latestBlock: P, latestBlockHash: B_32]
Note blockhash has moved to the end to match BlockRangeUpdate.
Receipts message changes
Modify the encoding for receipts in the Receipts (0x10) message as follows:
- (eth/68):
receipt = {legacy-receipt, typed-receipt} with
typed-receipt = tx-type || rlp(legacy-receipt)
legacy-receipt = [
post-state-or-status: {B_32, {0, 1}},
cumulative-gas: P,
bloom: B_256,
logs: [log₁, log₂, ...]
]
- (eth/69):
receipt = [tx-type, post-state-or-status, cumulative-gas, logs]
BlockRangeUpdate message
Add a new BlockRangeUpdate (0x11) message, with the following encoding
[earliestBlock: P, latestBlock: P, latestBlockHash: B_32]
The new message should be sent whenever the block range available from this client is
updated. In order to reduce traffic, it is not necessary to send an update for every new
block. Clients should send an update at most once per epoch (32 blocks).
Rationale
Status changes
After the merge, the TD field of the Status message became meaningless since the
difficulty of post-merge blocks are 0. It could in theory be used to distinguish synced
with unsynced nodes, but the same thing can be accomplished with the forkid as well.
The new earliestBlock field is technically not required for history expiry, but there
are a couple reasons why adding it can help:
- It improves peer finding for clients that still want to sync history from p2p after the
agreed-upon removal of pre-merge history has taken place. Without
earliestBlock, the
client would have to perform a request for history to check if the earlier range exists,
and assume that a failed request means it's not there.
- The new field can be used for census in a specialized crawler. We will be able to see
how many users/nodes enable history, and in which implementation.
- It prepares us for a future where the history expiry window is dynamic.
Receipts changes
Removing the bloom filters from the Receipt message reduces the CPU load of serving
nodes as well as the bandwidth significantly. The receiving nodes will need to recompute
the bloom filter in order to fully verify the receipt hash. The recomputation is not very
CPU intensive. The bandwidth gains amount to roughly 530GiB per syncing node or (at least)
95GiB snappy compressed.
In Ethereum consensus, the encoding of receipts differs between legacy transactions and
typed transactions. Typed transaction receipts are 'opaque' and have the data wrapped in a
byte array. However, all receipt types ultimately contain the same four fields. With the
removal of the bloom filter, the networking protocol now deviates from the encoding used
by consensus, and there is no need to replicate the weird and expensive encoding used
there. The proposed receipt encoding is just a flat list of the required data fields.
Backwards Compatibility
This EIP changes the eth protocol and requires rolling out a new version, eth/69.
Supporting multiple versions of a wire protocol is possible. Rolling out a new version
does not break older clients immediately, since they can keep using protocol version
eth/68.
This EIP does not change consensus rules of the EVM and does not require a hard fork.
Security Considerations
None
Copyright
Copyright and related rights waived via CC0.
