lighthouse icon indicating copy to clipboard operation
lighthouse copied to clipboard

/eth/v1/config/spec does not return Altair constants

Open mcdee opened this issue 4 years ago • 2 comments
trafficstars

Description

The /eth/v1/config/spec endpoint does not return all Altair constants.

Version

1.5.2

Present Behaviour

Not all Altair constants not returned (although some are, for example SYNC_COMMITTEE_SIZE).

Expected Behaviour

Altair constants should be returned:

  • DOMAIN_CONTRIBUTION_AND_PROOF
  • DOMAIN_SYNC_COMMITTEE
  • DOMAIN_SYNC_COMMITTEE_SELECTION_PROOF
  • SYNC_COMMITTEE_SUBNET_COUNT
  • TARGET_AGGREGATORS_PER_SYNC_SUBCOMMITTEE

Steps to resolve

Query /eth/v1/config/spec and examine output.

mcdee avatar Sep 27 '21 17:09 mcdee

Ah, I wasn't aware that a decision had been made to include constants in the spec endpoint. As in, I hadn't seen this paragraph before:

Retrieve specification configuration used on this node. The configuration should include:

Constants for all hard forks known by the beacon node, for example the phase 0 and altair values Presets for all hard forks supplied to the beacon node, for example the phase 0 and altair values Configuration for the beacon node, for example the mainnet values

Lighthouse's current behaviour is to return the preset + configs, and some constants from phase0 for backwards compatibility that we were hoping to eventually remove.

IMO including constants in the endpoint is kind of clunky because the set of constants is expansive and defined over multiple spec documents (there's no straightforward single source of truth). I had hoped the preset/config distinction would simplify and clearly define the configuration parameters, yet adding constants back in to the mix seems to work against that. You've listed a few constants that you want access to, but there are many more, e.g.

https://github.com/sigp/lighthouse/blob/f9bba92db3468321b28ddd9010e26b359f88bafe/consensus/types/src/consts.rs#L1-L21

Does Vouch not hard-code the constants from the specification? If it's a matter of wanting to avoid hard-coding values, maybe we need to address the root issue which is the lack of a canonical list of constants in the spec.

Of course, we're also pragmatic, and we want to follow the spec, so if this is something you really need we can kick the can down the road on adding all constants and just add the ones you mentioned

michaelsproul avatar Sep 28 '21 00:09 michaelsproul

Vouch does use the beacon node information for all of its constants (I've never trusted constants; they're shifty). I can see the other constants being useful as well (e.g. externally calculating rewards for a given epoch) but up to you if you want to add them as well.

mcdee avatar Sep 28 '21 07:09 mcdee