* 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>
- committee_index is used as an input to compute_subnet_for_attestation but it's not previously defined
- attestation.data.committee_index is incorrect, the field is "index"
* deprecate `BeaconBlocksByRange.step`
The `step` parameter has not seen much implementation in real life
clients which instead opt to request variations on a few epochs at a
time (instead of interleaving single blocks, entire epochs are
interleaved).
At the same time, supporting `step` on the server side brings several
complications: more complex bounds checking logic, more complex loading
of blocks from linear storage (which presumably stores all blocks and
not just certain increments).
This PR suggests that we deprecate the whole idea. Backwards
compatibility is kept by simply responding with a single block when
`step > 0` - this is allowed by the spec and should thus be handled
gracefully by requesting clients already, should there exist any that
use larger step counts.
Removing `step` now allows simplifying the EL-CL protocol for serving
execution data from the EL to avoid double storage.
* Update specs/phase0/p2p-interface.md
Co-authored-by: Danny Ryan <dannyjryan@gmail.com>
Co-authored-by: Danny Ryan <dannyjryan@gmail.com>
