-
Notifications
You must be signed in to change notification settings - Fork 5.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add EIP: Extension of EIP-778 for "client" ENR Entry
Merged by EIP-Bot.
- Loading branch information
1 parent
13b858c
commit 33db65e
Showing
1 changed file
with
76 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,76 @@ | ||
--- | ||
eip: 7636 | ||
title: Extension of EIP-778 for "client" ENR Entry | ||
description: Add aditional ENR entry to specify client information such as name and version number. | ||
author: James Kempton (@JKincorperated) | ||
discussions-to: https://ethereum-magicians.org/t/eip7636-extension-of-eip-778-for-client-enr-entry/18935 | ||
status: Draft | ||
type: Standards Track | ||
category: Networking | ||
created: 2024-02-25 | ||
requires: 778 | ||
--- | ||
|
||
## Abstract | ||
|
||
The Ethereum network consists of nodes running various client implementations. Each client has its own set of features, optimizations, and unique behaviors. Introducing a standardized way to identify client software and its version in the ENR allows for more effective network analysis, compatibility checks, and troubleshooting. This EIP proposes the addition of a "client" field to the ENR. | ||
|
||
## Motivation | ||
|
||
Understanding the landscape of client software in the Ethereum network is crucial for developers, nodes, and network health assessment. Currently, there is no standardized method for nodes to announce their software identity and version, which can lead to compatibility issues or difficulty in diagnosing network-wide problems. Adding this to the ENR allows clients to audit network health only using discv5, and additionally track discv5 adoption across different services. | ||
|
||
## Specification | ||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. | ||
|
||
The "client" entry is proposed to be added to the ENR following the specifications in [EIP-778](./eip-778.md). This entry is OPTIONAL and can be omitted by clients that choose not to disclose such information. The key for this entry is `"client"`. | ||
|
||
All elements MUST be encoded as a string using the ASCII standard as described in [RFC 20](https://www.rfc-editor.org/rfc/rfc20). | ||
|
||
The value for this entry MUST be an RLP list: | ||
|
||
``` | ||
[ClientName, Version, (BuildVersion)] | ||
``` | ||
|
||
- `ClientName`: A string identifier for the client software. It SHOULD be concise, free of spaces, and representative of the client application. | ||
- `Version`: A string representing the version of the client software in a human-readable format. It is RECOMMENDED to follow semantic versioning. | ||
- `BuildVersion`: An OPTIONAL string representing the build or commit version of the client software. This can be used to identify specific builds or development versions. | ||
|
||
## Rationale | ||
|
||
One key was chosen over using many keys to make efficient use of space. The use of one string, however, does not align with other EIPs of similar purpose and as such the RLP list was decided as the best encoding. | ||
|
||
## Backwards Compatibility | ||
|
||
This EIP is fully backwards compatible as it extends the ENR specification by adding an optional entry. Existing implementations that do not recognize the "client" entry will ignore it without any adverse effects on ENR processing or network behavior. | ||
|
||
## Test Cases | ||
|
||
A node running Geth version 1.10.0 on the mainnet might have an ENR `client` entry like: | ||
|
||
``` | ||
["Geth", "1.10.0"] | ||
``` | ||
|
||
A node running an experimental build of Nethermind might include: | ||
|
||
``` | ||
["Nethermind", "1.9.53", "7fcb567"] | ||
``` | ||
|
||
and an ENR of | ||
|
||
``` | ||
enr:-MO4QBn4OF-y-dqULg4WOIlc8gQAt-arldNFe0_YQ4HNX28jDtg41xjDyKfCXGfZaPN97I-MCfogeK91TyqmWTpb0_AChmNsaWVudNqKTmV0aGVybWluZIYxLjkuNTOHN2ZjYjU2N4JpZIJ2NIJpcIR_AAABg2lwNpAAAAAAAAAAAAAAAAAAAAABiXNlY3AyNTZrMaECn-TTdCwfZP4XgJyq8Lxoj-SgEoIFgDLVBEUqQk4HnAqDdWRwgiMshHVkcDaCIyw | ||
``` | ||
|
||
which can be decoded to yield normal data such as `seq`, `siqnature`, `id` and `secp256k1`. Additionally, it would yield the client value of `["0x4e65746865726d696e64","0x312e392e3533","0x37666362353637"]` or `["Nethermind", "1.9.53", "7fcb567"]` | ||
|
||
## Security Considerations | ||
|
||
Introducing identifiable client information could potentially be used for targeted attacks against specific versions or builds known to have vulnerabilities. It is crucial for clients implementing this EIP to consider the implications of disclosing their identity and version. Users or operators should have the ability to opt-out or anonymize this information if desired. | ||
|
||
## Copyright | ||
|
||
Copyright and related rights waived via [CC0](../LICENSE.md). |