status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

deprecate `BeaconBlocksByRange.step` (#2856) 

* 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>
This commit is contained in:
Jacek Sieka 2022-05-20 21:18:24 +02:00 committed by GitHub
parent 72f7b88f2a
commit 0e6a7cd39a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
specs/phase0/p2p-interface.md
View File

@ -727,7 +727,7 @@ Request Content:
(
start_slot: Slot
count: uint64
step: uint64
step: uint64 # Deprecated, must be set to 1
)
```
@ -738,12 +738,12 @@ Response Content:
)
```
Requests beacon blocks in the slot range `[start_slot, start_slot + count * step)`, leading up to the current head block as selected by fork choice.
`step` defines the slot increment between blocks.
For example, requesting blocks starting at `start_slot` 2 with a step value of 2 would return the blocks at slots [2, 4, 6, …].
Requests beacon blocks in the slot range `[start_slot, start_slot + count)`, leading up to the current head block as selected by fork choice.
For example, requesting blocks starting at `start_slot=2` and `count=4` would return the blocks at slots `[2, 3, 4, 5]`.
In cases where a slot is empty for a given slot number, no block is returned.
For example, if slot 4 were empty in the previous example, the returned array would contain [2, 6, …].
A request MUST NOT have a 0 slot increment, i.e. `step >= 1`.
For example, if slot 4 were empty in the previous example, the returned array would contain `[2, 3, 5]`.
`step` is deprecated and must be set to 1. Clients may respond with a single block if a larger step is returned during the deprecation transition period.
`BeaconBlocksByRange` is primarily used to sync historical blocks.