HomeEIPs
EIPsEIP-4938
EIP-4938

eth/67 - Removal of GetNodeData

Remove GetNodeData and NodeData messages from the wire protocol
StagnantStandards Track: Networking
Created: 2022-03-23
Requires: EIP-2464, EIP-2481
Marius van der Wijden (@MariusVanDerWijden), Felix Lange <fjl@ethereum.org>, Gary Rong <garyrong@ethereum.org>
DiscussionsOriginal linkEdit
1 min read

EIP-4938 proposes to remove the GetNodeData and NodeData messages from the Ethereum Wire Protocol. These messages were introduced in protocol version eth/63 to support a sync mode called "fast sync", which downloads the Ethereum state without executing all blocks. However, serving GetNodeData requests requires clients to store state as a mapping of hashes to trie nodes, which is not compatible with some client implementations. Therefore, removing these messages from the protocol would accurately reflect the capabilities of clients and avoid the need to store such a mapping in the database.

The EIP specifies that the eth protocol should remove the following message types: GetNodeData (0x0d) and NodeData (0x0e). A replacement for GetNodeData is available in the snap protocol, where clients can use the GetByteCodes and GetTrieNodes messages instead. The snap protocol can be used to implement the "fast sync" algorithm, but it is recommended to use it for "snap sync".

The EIP does not change the consensus rules of the Ethereum Virtual Machine (EVM) and does not require a hard fork. It only changes the eth protocol and requires rolling out a new version, eth/67. Supporting multiple versions of a wire protocol is possible, and rolling out a new version does not break older clients immediately, since they can keep using protocol version eth/66.

In summary, EIP-4938 proposes to remove the GetNodeData and NodeData messages from the Ethereum Wire Protocol to accurately reflect the capabilities of clients and avoid the need to store a mapping of hashes to trie nodes. A replacement for GetNodeData is available in the snap protocol, and rolling out a new version of the eth protocol does not require a hard fork and does not change the consensus rules of the EVM.

Video
Anyone may contribute to propose contents.
Go propose
Original

Abstract

The Ethereum Wire Protocol defines request and response messages for exchanging data between clients. The GetNodeData request retrieves a set of trie nodes or contract code from the state trie by hash. We propose to remove the GetNodeData and NodeData messages from the wire protocol.

Motivation

GetNodeData and NodeData were introduced in protocol version eth/63 to allow for a sync mode called "fast sync", which downloads the Ethereum state without executing all blocks. The sync algorithm works by requesting all state trie nodes and contract codes by their hash.

Serving GetNodeData requests requires clients to store state as a mapping of hashes to trie nodes. Avoiding the need to store such a mapping in the database is the main motivation for removing this request type.

At this time, some client implementations cannot serve GetNodeData requests because they do not store the state in a compatible way. The Ethereum Wire Protocol should accurately reflect the capabilities of clients, and should not contain messages which are impossible to implement in some clients.

Specification

Remove the following message types from the eth protocol:

  • GetNodeData (0x0d)
    • (eth/66): [request_id: P, [hash_0: B_32, hash_1: B_32, ...]]
  • NodeData (0x0e)
    • (eth/66): [request_id: P, [value_0: B, value_1: B, ...]]

Rationale

A replacement for GetNodeData is available in the snap protocol. Specifically, clients can use the GetByteCodes and GetTrieNodes messages instead of GetNodeData. The snap protocol can be used to implement the "fast sync" algorithm, though it is recommended to use it for "snap sync".

Backwards Compatibility

This EIP changes the eth protocol and requires rolling out a new version, eth/67. 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/66.

This EIP does not change consensus rules of the EVM and does not require a hard fork.

Security Considerations

None

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve EIP builders, scale Ethereum.
Resources
GitHub
Supported by