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

Merge pull request #1835 from ethereum/strict-block-range 

Strict block range (Rebase and extend #1827)
This commit is contained in:
Danny Ryan 2020-05-20 13:00:29 -06:00 committed by GitHub
parent a6d4566f51 522e34efcf
commit aa6352608e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -532,7 +532,10 @@ 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, …]. 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, …].
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, …].
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`.
`BeaconBlocksByRange` is primarily used to sync historical blocks.
@ -542,15 +545,20 @@ The response MUST consist of zero or more `response_chunk`. Each _successful_ `r
Clients MUST keep a record of signed blocks seen since the since the start of the weak subjectivity period and MUST support serving requests of blocks up to their own `head_block_root`.
Clients MUST respond with at least one block, if they have it and it exists in the range. Clients MAY limit the number of blocks in the response.
Clients MUST respond with at least the first block that exists in the range, if they have it.
The following blocks, where they exist, MUST be send in consecutive order.
Clients MAY limit the number of blocks in the response.
The response MUST contain no more than `count` blocks.
Clients MUST order blocks by increasing slot number.
Clients MUST respond with blocks from their view of the current fork choice -- that is, blocks from the single chain defined by the current head. Of note, blocks from slots before the finalization MUST lead to the finalized block reported in the `Status` handshake.
Clients MUST respond with blocks that are consistent from a single chain within the context of the request. After the initial block, clients MAY stop in the process of responding if their fork choice changes the view of the chain in the context of the request.
Clients MUST respond with blocks that are consistent from a single chain within the context of the request.
This applies to any `step` value. In particular when `step == 1`, each `parent_root` MUST match the `hash_tree_root` of the preceding block.
After the initial block, clients MAY stop in the process of responding if their fork choice changes the view of the chain in the context of the request.
#### BeaconBlocksByRoot