From 607e23949c6e489c2f399bbbbaab7247cd8fc1be Mon Sep 17 00:00:00 2001 From: Jacek Sieka Date: Tue, 19 May 2020 07:51:53 +0200 Subject: [PATCH] require blocks to be ordered consecutively in block range request Per the spec, if I request range 5-10, it is permissible for a client to answer with block 7, 9 - even if the blocks 5, 6 and 8 exist. Because blocks 7 and 9 cannot be validated as they arrive in such a request, it seems better to close this gap - this update adds the spec language that forbids well-behaving clients from answering this way. --- specs/phase0/p2p-interface.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/specs/phase0/p2p-interface.md b/specs/phase0/p2p-interface.md index 0e8699555..fc457c58a 100644 --- a/specs/phase0/p2p-interface.md +++ b/specs/phase0/p2p-interface.md @@ -542,12 +542,14 @@ The response MUST consist of zero or more `response_chunk`. Each _successful_ `r Clients MUST keep a record of signed blocks seen since the since the start of the weak subjectivity period and MUST support serving requests of blocks up to their own `head_block_root`. -Clients MUST respond with at least one block, if they have it and it exists in the range. Clients MAY limit the number of blocks in the response. +Clients MUST respond with at least the first block that exists in the range, if they have it. + +The following blocks MUST be ordered consecutively, with each `parent_root` matching the `hash_tree_root` of the previous block. + +Clients MAY limit the number of blocks in the response. 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 -- 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.