5576d0e685
* Moved configuration into network preset instead of constants. Now that `MAX_CHUNK_SIZE` and `GOSSIP_MAX_SIZE` are in configuration, we no longer need separate constants to represent them in the spec when they change in Bellatrix. I've changed the usage, and put the values into the presets, but I'm not sure if I've updated the descriptions in the best way... This is following on from the work in #3375 where a number of constants got moved into configuration, so we no longer need these constants to be separately represented, they can simply be updated in presets. * Update presets/minimal/bellatrix.yaml Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com> * Update presets/mainnet/bellatrix.yaml Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com> * Moved preset items into the correct section and updated TOC. It looked like the items listed in configuration about the max size and chunk size were no longer needed since we're updating preset values now and the preset changes seem to only be listed in the changes at the top. * review feedback * hopefully correct this time! Moved the 2 fields from configs into presets completely as suggested. * WIP - changing back to being in config and updating the phase 0 value... I think this should be close but want to see what's outstanding. * fix intellij's formatting of table. * more fixes --------- Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com> |
||
|---|---|---|
| .. | ||
| README.md | ||
| mainnet.yaml | ||
| minimal.yaml | ||
README.md
Configurations
This directory contains a set of configurations used for testing, testnets, and mainnet.
A client binary may be compiled for a specific PRESET_BASE,
and then load different configurations around that preset to participate in different networks or tests.
Standard configs:
mainnet.yaml: Mainnet configurationminimal.yaml: Minimal configuration, used in spec-testing along with theminimalpreset.
Not all network configurations are in scope for the specification,
see github.com/eth-clients/eth2-networks for common networks,
and additional testnet assets.
Forking
Variables are not replaced but extended with forks. This is to support syncing from one state to another over a fork boundary, without hot-swapping a config.
Instead, for forks that introduce changes in a variable, the variable name is suffixed with the fork name, e.g. INACTIVITY_PENALTY_QUOTIENT_ALTAIR.
Future-fork variables can be ignored, e.g. ignore Sharding variables as a client that only supports Phase 0 currently.
Over time, the need to sync an older state may be deprecated. In this case, the suffix on the new variable may be removed, and the old variable will keep a special name before completely being removed.
A previous iteration of forking made use of "timelines", but this collides with the definitions used in the spec (variables for special forking slots, etc.), and was not integrated sufficiently in any of the spec tools or implementations.
Instead, the config essentially doubles as fork definition now, e.g. changing the value for ALTAIR_FORK_EPOCH changes the fork.
Format
Each preset and configuration is a key-value mapping.
Key: an UPPER_SNAKE_CASE (a.k.a. "macro case") formatted string, name of the variable.
Value can be either:
- an unsigned integer number, can be up to 64 bits (incl.)
- a hexadecimal string, prefixed with
0x
This format is fully YAML compatible. The presets and configurations may contain comments to describe the values.