Standardizing the spec endpoint

[mcdee]

The /eth/v1/config/spec endpoint should in theory return the same information from each beacon node client, however in practice it does not. The recent issue with holesky has highlighted the benefit of having a standard configuration, so we should address the inconsistencies in this endpoint.

Addressing the inconsistencies is likely to have multiple facets, for example:

• ensure that existing clients adhere to the spec as-is
• tighten up the spec where it is open to interpretation
• define what to do with values that are not specified in an existing repo (e.g. terminal total difficulty for sepolia)
• how to handle speculative values (e.g. value for future forks which will turn up at different times in different codebases)

This issue is here to be used as a reference point for all such changes to specification and implementations.

[arnetheduck]

Broadly, I think the lesson learned from the past is that this is an excellent endpoint to be "lenient in what you accept and strict in what you send" - ie almost all issues with this endpoint have stemmed from clients being overly strict about which values are there and which are not, even if they don't per se need said values - a vc for example couldn't care less about total difficulty, so there's no reason for it to require it.

[mcdee]

Broadly, I think the lesson learned from the past is that this is an excellent endpoint to be "lenient in what you accept and strict in what you send" - ie almost all issues with this endpoint have stemmed from clients being overly strict about which values are there and which are not, even if they don't per se need said values - a vc for example couldn't care less about total difficulty, so there's no reason for it to require it.

This assumes that the VC is the only consumer of the data. Being able to confirm the various spec parameters as the beacon node sees them allows for confirmation between nodes that they agree, and ideally between the beacon node and some form of "master" data, to avoid issues such as we saw on holesky.

So moving away from a info-for-a-vc purpose to a more general spec-of-the-node purpose for the endpoint provides it with more utility, and an ability for us to have more data for configuration confirmation. I think that we are most of the way there, and it's mainly tidy-ups.

[arnetheduck]

more data for configuration confirmation

I think this is the point I'm trying to make: confirmation for the sake of confirmation gets in the way more often than it's useful - when consumers of the API know that the values provided by spec are best effort and may shift with versions and over time and that there is no specific values that must be provided they can be developed accordingly. I think the intent of the feature has never been to act as a strict blocking feature - that's why there are no specific values required in the endpoint description / yml - instead, it's just a key-value map.

I think it's directly counterproductive for tooling to require specific values to be present unless they need them for their own functionality. This point applies to both VC-like consumers and others.

[mcdee]

I think it's directly counterproductive for tooling to require specific values to be present unless they need them for their own functionality. This point applies to both VC-like consumers and others.

Well the API specification at https://ethereum.github.io/beacon-APIs/#/Config/getSpec already defines a number of items that are expected to be present, so to start with we're talking about spec compliance.

But the overarching point is to get this endpoint to a place where the configuration of a beacon node can be compared either to other beacon nodes or to the spec itself, to confirm correctness. If you think that this should be achieved in a different way, either with a different endpoint or through some sort of other mechanism, that's a conversation worth having, but it feels like we have at least a good starting point with the current endpoint and it should be less effort to standardize this endpoint than to create an entirely new mechanism to achieve the same result.

[arnetheduck]

configuration of a beacon node can be compared either to other beacon nodes or to the spec itself, to confirm correctness

Indeed, I'm arguing that the definition of "correctness" in this case includes "tolerance for values I don't know or need", as is de facto standard for json-based interfaces. Then the tool can act accordingly and accept minor differences.
I think you might be thinking of a different form of correctness in your tool which is rather unusual in this context, namely that of perfect equivalence to "something".

[mcdee]

I don't think we will be able to obtain perfect equivalence, not least because there are lots of values output by various beacon nodes for future forks and specific features that are not part of the official spec, and introduction of these are uneven across different clients. But there are any number of parameters which form part of the Ethereum consensus specification and have defined values, and can have serious consequences if not set correctly, so we should be doing what we can to build a mechanism to allow automated extraction of these values from a running node.

[rolfyone]

even simple things like renaming spec constants does make this challenging to achieve....

In testnets we didnt have 'required' fields defined and no clients seemed to have issues with that so potentially the first challenge is keeping testnet config 'up to date' with required mainnet fields, and that would obviously flow on to beacon-api...