Add offset and min_slot to beacon_blocks_by_head#5265
Open
arnetheduck wants to merge 3 commits into
Open
Conversation
When downloading blocks by head, the ancestry of the given `block_root`
is not known - adding an `offset` to the requests allows clients to make
requests for non-overlapping pages of history.
```
---A---B---C
F
```
If `block_root` is `C` and `-` are other blocks, a request with
`offset=4` would result in `B` being sent.
When requesting by offset, it is not known which slot the blocks have -
this has several consequences:
* clients may not have a by-block index since this is not used elsewhere
in the protocol making the iteration expensive - it is thus limited to
1024 blocks in the current fork - clients with an efficient index may
allow larger offsets but this capability should not be used by
requesting clients.
* `min_slot` is for the situation where `F` finalizes some history and
this request is used to discover a new branch (for example due to an
attestation arriving with unknown root). Previously, clients would use
`by_root` requests and download such histories block but block -
instead, they can use a by_head request and get the full branch -
`min_slot` ensures that we don't transfer blocks past the block `F`, ie
for histories with large slot jumps, it limits transfers to a single
block proving that the history is useless. For backfilling the canonical
history, 0 can be used.
Contributor
Author
really? |
Member
|
What's the maximum value of offset? That can trigger a very long tree traversal without counting towards the rate limit |
Contributor
Author
|
jtraglia
changed the title
beacon_blocks_by_head: add offset, min_slotoffset and min_slot to beacon_blocks_by_head
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When downloading blocks by head, the ancestry of the given
block_rootis not known - adding anoffsetto the requests allows clients to make requests for non-overlapping pages of history.If
block_rootisCand-are other blocks, a request withoffset=4would result inBbeing sent.When requesting by offset, it is not known which slot the blocks have - this has several consequences:
min_slotis for the situation whereFfinalizes some history and this request is used to discover a new branch (for example due to an attestation arriving with unknown root). Previously, clients would useby_rootrequests and download such histories block but block - instead, they can use a by_head request and get the full branch -min_slotensures that we don't transfer blocks past the blockF, ie for histories with large slot jumps, it limits transfers to a single block proving that the history is useless. For backfilling the canonical history, 0 can be used.