lighthouse icon indicating copy to clipboard operation
lighthouse copied to clipboard

Cannot rewrite `SLOTS_PER_EPOCH` through `config.yaml`

Open varasev opened this issue 3 years ago • 5 comments

Description

It seems that something is wrong when we try to define SLOTS_PER_EPOCH explicitly in config.yaml:

If I set PRESET_BASE to mainnet in config.yaml and set SLOTS_PER_EPOCH to 16, it doesn't rewrite mainnet's value and the epoch length is still 32. But if I try to set PRESET_BASE to gnosis, the epoch length becomes 16.

Version

It is observed for v2.1.2-modern (docker image).

varasev avatar Feb 18 '22 10:02 varasev

This is due to some values only being configurable at compile-time. The specs from the EF define two types of configuration: presets and configs, and Lighthouse only allows the latter to be set from a config.yaml file.

If the Gnosis preset matches the chain you want to run then it would be great if you could use that, as we would like to keep the set of presets maintained upstream to a minimum. Alternatively you can create your own *EthSpec type and set the compile-time constants accordingly. You can see the EthSpec implementation for Gnosis here:

https://github.com/sigp/lighthouse/blob/c3a793fd73a3b11b130b82032904d39c952869e4/consensus/types/src/eth_spec.rs#L329-L365

I'll leave this issue open as this seems to be an increasingly common question (surely a good sign for LH adoption :blush: ), and there are two things Lighthouse could probably do better in this case:

  1. Output a warning when the config.yaml read for a network contains extra unread fields (like SLOTS_PER_EPOCH), and/or fields that are mismatched with the selected preset.
  2. Make it easier to drop in new presets at compile time by adding a preset.yaml file to some directory. We could use a procedural macro to generate EthSpec instances from these files.

michaelsproul avatar Feb 18 '22 23:02 michaelsproul

This is due to some values only being configurable at compile-time

So, SLOTS_PER_EPOCH is not rewritable through config.yaml?

However, we could override it when using Lighthouse v2.0.1 (our LH fork, though). Example: https://github.com/gnosischain/lighthouse-launch/blob/c6c74ac05b04217868e94042e369b21f5c733d01/config/config.yaml#L76

I guess, that was rewritable, but became unrewritable in the latest releases, right?

varasev avatar Feb 21 '22 09:02 varasev

And do I get it correctly that all configurable fields are listed in the file https://github.com/ethereum/consensus-specs/blob/dev/configs/mainnet.yaml?

varasev avatar Feb 21 '22 10:02 varasev

So, SLOTS_PER_EPOCH is not rewritable through config.yaml?

Yeah that's right

I guess, that was rewritable, but became unrewritable in the latest releases, right?

Nah, it's been like this since before Lighthouse v2.0.0 and the Altair fork (this PR: #2279).

However, we could override it when using Lighthouse v2.0.1 (our LH fork, though).

I think that config value is just being ignored by Lighthouse as it would be today. The gbc-lighthouse fork also contained commits like this one to hardcode the type-level values: https://github.com/gnosischain/gbc-lighthouse/commit/087af83ee92ee234161c4d13daa4e3e2240a9d27.

And do I get it correctly that all configurable fields are listed in the file https://github.com/ethereum/consensus-specs/blob/dev/configs/mainnet.yaml?

Yep! That's right :+1:

michaelsproul avatar Feb 21 '22 10:02 michaelsproul

@michaelsproul Got it, thank you for your answers

varasev avatar Feb 21 '22 12:02 varasev

Would be good to at least implement this suggestion:

Output a warning when the config.yaml read for a network contains extra unread fields (like SLOTS_PER_EPOCH), and/or fields that are mismatched with the selected preset.

As it seems like one of the most common custom testnet issues we've seen (user overriding preset config that gets silently ignored).

jimmygchen avatar Aug 01 '23 03:08 jimmygchen