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> |
||
|---|---|---|
| .. | ||
| mainnet | ||
| minimal | ||
| README.md | ||
README.md
Presets
Presets are more extensive than runtime configurations, and generally only applicable during compile-time. Each preset is defined as a directory, with YAML files per fork.
Configurations can extend a preset by setting the PRESET_BASE variable.
An implementation may choose to only support 1 preset per build-target and should validate
the PRESET_BASE variable in the config matches the running build.
Standard presets:
mainnet/: Used in mainnet, mainnet-like testnets (e.g. Prater), and spec-testingminimal/: Used in low-resource local dev testnets, and spec-testing
Client implementers may opt to support additional presets, e.g. for extra large beacon states for benchmarking.
See /configs/ for run-time configuration, e.g. to configure a new testnet.
Forking
Like the config forking, the preset extends with every fork, instead of overwriting previous values. An implementation can ignore preset files as a whole for future forks, and can thus implement stricter compile-time warnings on unrecognized or missing variables in current forks.
Format
The preset format matches the config format.