53 lines
3.0 KiB
Markdown
53 lines
3.0 KiB
Markdown
|
---
|
||
|
|
eip: 4938
|
||
|
|
title: "eth/67 - Removal of GetNodeData"
|
||
|
|
description: "Remove GetNodeData and NodeData messages from the wire protocol"
|
||
|
|
author: Marius van der Wijden (@MariusVanDerWijden), Felix Lange <fjl@ethereum.org>, Gary Rong <garyrong@ethereum.org>
|
||
|
|
discussions-to: https://ethereum-magicians.org/t/eip-4938-removal-of-getnodedata/8893
|
||
|
|
status: Review
|
||
|
|
type: Standards Track
|
||
|
|
category: Networking
|
||
|
|
created: 2022-03-23
|
||
|
|
requires: 2464, 2481
|
||
|
|
---
|
||
|
|
|
||
|
|
## Abstract
|
||
|
|
|
||
|
|
The [Ethereum Wire Protocol](https://github.com/ethereum/devp2p/blob/40ab248bf7e017e83cc9812a4e048446709623e8/caps/eth.md) 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](https://github.com/ethereum/devp2p/blob/40ab248bf7e017e83cc9812a4e048446709623e8/caps/snap.md). Specifically, clients can use the [GetByteCodes](https://github.com/ethereum/devp2p/blob/40ab248bf7e017e83cc9812a4e048446709623e8/caps/snap.md#getbytecodes-0x04) and [GetTrieNodes](https://github.com/ethereum/devp2p/blob/40ab248bf7e017e83cc9812a4e048446709623e8/caps/snap.md#gettrienodes-0x06) 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
|
||
|
|
|
||
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|
||
|
|
|