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