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: don't remove NewBlock(Hashes) #9133

Merged
merged 1 commit into from
Dec 20, 2024
Merged

Update EIP-7642: don't remove NewBlock(Hashes) #9133

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
24 changes: 4 additions & 20 deletions EIPS/eip-7642.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,8 +13,8 @@ requires: 5793

## Abstract

After the merge a few fields (`td`) and messages (`NewBlockHashes`, `NewBlock`) in the networking protocol became obsolete.
This EIP modifies the networking messages such that these fields are not sent anymore.
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.

## Motivation
Expand All @@ -26,20 +26,11 @@ The serving node will regenerate roughly 530GB of bloom filters (2.3B txs * 256
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.

Additionally we propose to remove fields and messages that were deprecated by the merge, such as

- Removing the `TD` field in the `Status` message.

- Removing the `NewBlockHashes` message.

- Removing the `NewBlock` message.
Additionally we propose to remove the field that was deprecated by the merge, namely
the `TD` field in the `Status` message.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could make consistent with capitalisation of td / TD

Copy link
Member Author

@yperbasis yperbasis Dec 20, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here I simply kept the original capitalization.


## Specification

Remove the `NewBlockHashes (0x01)` message.

Remove the `NewBlock (0x07)` message.

Modify the `Status (0x00)` message as follows:

- (eth/68): `[version: P, networkid: P, td: P, blockhash: B_32, genesis: B_32, forkid]`
Expand Down Expand Up @@ -79,18 +70,11 @@ 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.

After the merge, the `NewBlock` and `NewBlockHashes` messages have not been used for block propagation,
since block propagation post-merge happens solely on the consensus layer.
These message types error out in the go-ethereum implementation.
Getting rid of them would allow us to disconnect non-mainnet peers earlier.

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.

## Backwards Compatibility

Since this EIP removes the `NewBlock` and `NewBlockHashes` messages, private networks or forks that use them to distribute blocks can not update to this version. All private networks or forks that use a mechanism similar to ethereum mainnet, where the consensus layer takes care of block distribution can update to `eth/69`.

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