Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify BlocksByRange request #1795

Merged
merged 2 commits into from
May 11, 2020
Merged

Clarify BlocksByRange request #1795

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
01eaf6c
Clarify the response of BlocksByRange to address #1765
djrtwo May 8, 2020
b4bc203
clarify that clients MAY stop block requests if fork choice changes
djrtwo May 11, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion specs/phase0/p2p-interface.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -537,7 +537,9 @@ 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. In particular, blocks from slots before the finalization MUST lead to the finalized block reported in the `Status` handshake.
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.

#### BeaconBlocksByRoot

Expand Down