consensus-specs
consensus-specs copied to clipboard
ethereum
Add BeaconBlocksByRange v3
BeaconBlocksByRange v2 allows to sync blocks exclusively from the peer's canonical chain.
Consider an unstable network with a competing forks. One can group peers by their head with status Req Resp messages. However, there's asynchrony between receiving that status message and requesting blocks by range, as the head of the remote peer can change at any time.
Consider a case where you syncing a head chain with BeaconBlocksByRange v2 and peer changes its head before you issue a by range request. It changes into a fork that has all missed slots in the requested range. You should downscore the peer since its giving incorrect blocks for the segment you are intending to sync. However, the root of the issue is the risk of mixing ranges of blocks from different forks without being aware of it.
BeaconBlocksByRange v3 allows requesters to specify which fork they intend to sync. An exemplary consumer would:
- Status all its peers
- Group them by head_root
- Issue BeaconBlocksByRange v3 requests to each group where block_root = head_root
If other clients believe this protocol to be unnecessary I'm keen to know how you handle these situations with the existing protocols.
I'm a bit surprised that this didn't exist in the beginning. Do we have any reason why we didn't do it in phase0? or we just didn't do it.
Should we do the same with BlobSidecarsByRange as well? I feel that there is no reason to do it only with one but not the other.
On Nimbus, there is branch feat/splitview which pulls in blocks via BeaconBlocksByRoot in a backward motion, from peers specifically advertising unknown branches.
One issue on Goerli was that when there is heavy branching, that there are also longer gaps, so range requests are very inefficient due to sometimes long gaps between blocks.
On Nimbus, there is branch feat/splitview which pulls in blocks via BeaconBlocksByRoot in a backward motion, from peers specifically advertising unknown branches.
If the branch is long you can easily get DOS-ed, you can't validate any block until you root the branch on a known block
I am closing this issue because it seems stale. Please, do not hesitate to reopen it if this is a mistake
keen to know how you handle these situations
If you receive a chain segment that you didn't know about (can't link to a block you know), you've just received a signal that there's another fork you should probably consider syncing (either now or in the future) - this is a feature really, not a bug (because that chain might become canonical).
