From 488ceed4f9de63898d8ebc490d6b044b5a27fec4 Mon Sep 17 00:00:00 2001 From: Danny Ryan Date: Tue, 11 May 2021 11:29:37 -0600 Subject: [PATCH] add notes about repeatedly failing tos erve blocks as being disconncetable --- specs/phase0/p2p-interface.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/specs/phase0/p2p-interface.md b/specs/phase0/p2p-interface.md index a0bd2d4e2..f2c7d8610 100644 --- a/specs/phase0/p2p-interface.md +++ b/specs/phase0/p2p-interface.md @@ -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, 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. -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 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 proposer signatures and (2) that the blocks form a valid chain up to the most 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, and no more than `MAX_REQUEST_BLOCKS` blocks.