Add getNodeVersionV2 endpoint #568
Conversation
eth2353
force-pushed
the
add-v2-node-version-endpoint
branch
from
6fe82bf to
e0ea5c8
Compare
|
Similar to griffiti watermarks, it's reasonable to expect that there are nodes that either can't or choose not to pass back version specifics..... It's also seen sometimes in these watermarks that only one client (typically the CL) is declared (harder to tell if its unknown or no space). |
|
I consider this to be quite different from graffiti data since that is public, whereas the Beacon API is not generally exposed publicly. I don't really see an issue with passing back precise version information here. On the current V1 endpoint most clients already include everything that is proposed in this PR for the CL side, just in a less structured "User-agent" way:
I can see the beacon node not having EL-side information for some reason (e.g. because the EL client is not responding to the beacon node's Engine API requests). In such cases we could either not include the "execution_client" field in the return data (and make that entire field optional), or explicitly define an For the usecase I'm looking for, just the client names would suffice, e.g. this node is running Lodestar+Reth. But since most clients already include much more in their current user-agent, I decided to just reuse the Engine API schema. |
nflaig
left a comment
nflaig
left a comment
There was a problem hiding this comment.
Overall looks good to me, this was pretty straight forward to implement ChainSafe/lodestar#8772 for us.
| @@ -0,0 +1,19 @@ | |||
| ClientVersionV1: | |||
| type: object | |||
| description: "A structure which uniquely identifies a client implementation and its version. Mirrors the client version specification in the [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/identification.md)." | |||
There was a problem hiding this comment.
would suggest to use perma links here (either commit hash or tag if it exists)
| description: "A structure which uniquely identifies a client implementation and its version. Mirrors the client version specification in the [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/identification.md)." | |
| description: "A structure which uniquely identifies a client implementation and its version. Mirrors the client version specification in the [Engine API](https://github.com/ethereum/execution-apis/blob/c4988b1c427645d1b861c8c12488975f5a2f8cb9/src/engine/identification.md)." |
and in other places
| example: "Lodestar" | ||
| version: | ||
| type: string | ||
| description: "the version string of the current implementation e.g. v4.6.0 or 1.0.0-alpha.1 or 1.0.0+20130313144700" |
There was a problem hiding this comment.
| description: "the version string of the current implementation e.g. v4.6.0 or 1.0.0-alpha.1 or 1.0.0+20130313144700" | |
| description: "The version string of the current implementation e.g. v4.6.0 or 1.0.0-alpha.1 or 1.0.0+20130313144700" |
There was a problem hiding this comment.
need to add changelog entries for new api and deprecation note for v1 api
| ClientCode: | ||
| type: string | ||
| description: "A two-character client code that uniquely maps to a client name as defined in the [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/identification.md#clientcode)." | ||
| enum: [BU, EJ, EG, GE, GR, LH, LS, NM, NB, TE, TK, PM, RH] |
There was a problem hiding this comment.
might be worth to specify what to return if client code is unknown, we have a non-spec value of XX for this
| properties: | ||
| code: | ||
| $ref: './primitive.yaml#/ClientCode' | ||
| name: |
There was a problem hiding this comment.
might be worth to specify what name to return if information is missing, eg. if we could not retrieve the EL client info yet, I am just returning Unknown right now
3 participants
Adds a
/eth/v2/node/versionendpoint for structured version information that also includes information about the attached EL client.Changes:
/eth/v1/node/versionendpointThe main motivation for this change is for validator clients to have access to information about the EL client attached to a beacon node. Right now, validator clients cannot see "past" the beacon node easily and are therefore blind to what kind of EL client is validating the execution payload. By exposing this information, multi-node validator clients can make safer decisions, e.g. they can require 3 different EL clients to declare the execution payload as valid before they attest to its validity.