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

add notes about repeatedly failing tos erve blocks as being disconncetable

This commit is contained in:
Danny Ryan 2021-05-11 11:29:37 -06:00
parent 5792afca46
commit 488ceed4f9
No known key found for this signature in database
GPG Key ID: 2765A792E42CE07A
1 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -752,18 +752,20 @@ Clients MUST keep a record of signed blocks seen on the epoch range
where `current_epoch` is defined by the current wall-clock time, where `current_epoch` is defined by the current wall-clock time,
and clients MUST support serving requests of blocks on this range. and clients MUST support serving requests of blocks on this range.
Synced clients unable to reply to Block requests within the Peers are *repeatedly* unable to reply to Block requests within the
`MIN_EPOCHS_FOR_BLOCK_REQUESTS` epoch range MAY get descored or disconnected at any time. `MIN_EPOCHS_FOR_BLOCK_REQUESTS` epoch range MAY get descored or disconnected at any time.
Note, due to this it is risky behaviour to begin participating as a full node at the head if having
not yet backfilled on this range.
*Note*: The above requirement implies that nodes that start from a recent weak subjectivity checkpoint *Note*: The above requirement implies that nodes that start from a recent weak subjectivity checkpoint
MUST backfill the local block database to at least epoch `current_epoch - MIN_EPOCHS_FOR_BLOCK_REQUESTS` MUST backfill the local block database to at least epoch `current_epoch - MIN_EPOCHS_FOR_BLOCK_REQUESTS`
to be compliant with `BlocksByRange` requests. To safely perform such a to be fully compliant with `BlocksByRange` requests. To safely perform such a
backfill of blocks to the recent state, the node MUST validate both (1) the backfill of blocks to the recent state, the node MUST validate both (1) the
proposer signatures and (2) that the blocks form a valid chain up to the most proposer signatures and (2) that the blocks form a valid chain up to the most
recent block referenced in the weak subjectivity state. recent block referenced in the weak subjectivity state.
*Note*: Although clients that bootstrap from a weak subjectivity checkpoint can begin
participating in the networking immediately, other peers that are actively block syncing MAY
disconnect and/or temporarily ban such an un-synced or semi-synced client.
Clients MUST respond with at least the first block that exists in the range, if they have it, Clients MUST respond with at least the first block that exists in the range, if they have it,
and no more than `MAX_REQUEST_BLOCKS` blocks. and no more than `MAX_REQUEST_BLOCKS` blocks.