Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update EIP-7642: add earliestBlock and update receipts encoding #9237

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
+61 −33
Open

Update EIP-7642: add earliestBlock and update receipts encoding #9237

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
ed70ee1
EIP-7642: add earliestBlock and update receipts encoding
fjl Jan 13, 2025
e7462cb
EIP-7642: update title
fjl Jan 13, 2025
8a4b8e2
EIP-7642: update link
fjl Jan 13, 2025
70d7c25
EIP-7642: add rationale for earliestBlock
fjl Jan 13, 2025
b9ab351
EIP-7642: update deadline
fjl Jan 14, 2025
4dd19d5
EIP-7642: add rationale for receipt encoding
fjl Jan 14, 2025
75925a8
EIP-7642: rephrase
fjl Jan 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
94 changes: 61 additions & 33 deletions EIPS/eip-7642.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
eip: 7642
title: eth/69 - Drop pre-merge fields
description: Drop unnecessary fields after the merge
title: eth/69 - history expiry and simpler receipts
description: Adds history serving window and removes bloom filter in receipt
author: Marius van der Wijden (@MariusVanDerWijden), Felix Lange <[email protected]>
discussions-to: https://ethereum-magicians.org/t/eth-70-drop-pre-merge-fields-from-eth-protocol/19005
status: Stagnant
Expand All @@ -13,35 +13,46 @@ requires: 5793

## Abstract

After the merge the `td` field in the networking protocol became obsolete.
This EIP modifies the networking messages such that this field is not sent anymore.
Additionally we propose to remove the `Bloom` field from the receipts networking messages.
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 transfered over the protocol.

## Motivation

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.
### Removing Bloom in Receipts

Additionally we propose to remove the field that was deprecated by the merge, namely
the `TD` field in the `Status` message.
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.

### earliestBlock 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](./eip-7542.md) but was later withdrawn
because a political decision on history expiry had not been reached at the time.

## Specification

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, blockhash: B_32, genesis: B_32, forkid]`
- (eth/69): `[version: P, networkid: P, blockhash: B_32, genesis: B_32, forkid, earliestBlock: P]`

Modify the encoding for receipts in the `Receipts (0x10)` message as follows:

- (eth/68): `receipt = {legacy-receipt, typed-receipt}` with `typed-receipt = tx-type || receipt-data` and
- (eth/68): `receipt = {legacy-receipt, typed-receipt}` with

```
typed-receipt = tx-type || legacy-receipt

legacy-receipt = [
post-state-or-status: {B_32, {0, 1}},
cumulative-gas: P,
Expand All @@ -50,32 +61,49 @@ legacy-receipt = [
]
```

- (eth/69): `receipt = {legacy-receipt, typed-receipt}` with `typed-receipt = tx-type || receipt-data` and
- (eth/69): `receipt = [tx-type, post-state-or-status, cumulative-gas, logs]`

```
legacy-receipt = [
post-state-or-status: {B_32, {0, 1}},
cumulative-gas: P,
logs: [log₁, log₂, ...]
]
```
## Rationale

We omit the bloom filter from both the legacy and typed receipts.
Receiving nodes will be able to recompute the bloom filter based on the logs.
### Status changes

## Rationale
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

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.
It is not used in the go-ethereum codebase in any way.
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.

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. 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 technically '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 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.

Expand Down
Loading