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

Jump to bottom

deprecate BeaconBlocksByRange.step #2856

Merged
merged 2 commits into from
May 20, 2022
Merged

deprecate BeaconBlocksByRange.step #2856

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
99186f7
deprecate `BeaconBlocksByRange.step`
arnetheduck Mar 18, 2022
0c4058b
Update specs/phase0/p2p-interface.md
arnetheduck Apr 8, 2022
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
14 changes: 7 additions & 7 deletions specs/phase0/p2p-interface.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -252,7 +252,7 @@ Likewise, clients MUST NOT emit or propagate messages larger than this limit.
The optional `from` (1), `seqno` (3), `signature` (5) and `key` (6) protobuf fields are omitted from the message,
since messages are identified by content, anonymous, and signed where necessary in the application layer.
Starting from Gossipsub v1.1, clients MUST enforce this by applying the `StrictNoSign`
[signature policy](https://github.com/libp2p/specs/blob/master/pubsub/README.md#signature-policy-options).
[signature policy](https://github.com/libp2p/specs/blob/master/pubsub/README.md#signature-policy-options).

The `message-id` of a gossipsub message MUST be the following 20 byte value computed from the message data:
* If `message.data` has a valid snappy decompression, set `message-id` to the first 20 bytes of the `SHA256` hash of
Expand Down Expand Up @@ -727,7 +727,7 @@ Request Content:
(
start_slot: Slot
count: uint64
step: uint64
step: uint64 # Deprecated, must be set to 1
)
```

Expand All @@ -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.

Expand Down