From cb9159fe588178f7cd835380aecc8b1fa5b9be4b Mon Sep 17 00:00:00 2001 From: terence tsao Date: Tue, 8 Nov 2022 10:41:48 -0800 Subject: [PATCH] EIP4844: Add block and sidecar retrival by root --- specs/eip4844/p2p-interface.md | 46 +++++++++++++++++++++++++++------- 1 file changed, 37 insertions(+), 9 deletions(-) diff --git a/specs/eip4844/p2p-interface.md b/specs/eip4844/p2p-interface.md index 1576fe96f..4e08195a5 100644 --- a/specs/eip4844/p2p-interface.md +++ b/specs/eip4844/p2p-interface.md @@ -23,6 +23,7 @@ The specification of these changes continues in the same format as the network s - [Messages](#messages) - [BeaconBlocksByRange v2](#beaconblocksbyrange-v2) - [BeaconBlocksByRoot v2](#beaconblocksbyroot-v2) + - [BeaconBlockAndBlobsSidecarByRoot v1](#beaconblockandblobssidecarbyroot-v1) - [BlobsSidecarsByRange v1](#blobssidecarsbyrange-v1) - [Design decision rationale](#design-decision-rationale) - [Why are blobs relayed as a sidecar, separate from beacon blocks?](#why-are-blobs-relayed-as-a-sidecar-separate-from-beacon-blocks) @@ -129,18 +130,45 @@ Per `context = compute_fork_digest(fork_version, genesis_validators_root)`: **Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_root/2/` -The EIP-4844 fork-digest is introduced to the `context` enum to specify EIP-4844 beacon block type. +`BeaconBlocksByRoot v2` will be disabled in favor of `BeaconBlockAndBlobsSidecarByRoot v1` for tighter coupling of blocks and sidecars. -Per `context = compute_fork_digest(fork_version, genesis_validators_root)`: +Clients MUST disable `BeaconBlocksByRoot v2` after `EIP4844_FORK_EPOCH`. -[1]: # (eth2spec: skip) +#### BeaconBlockAndBlobsSidecarByRoot v1 -| `fork_version` | Chunk SSZ type | -| ------------------------ | -------------------------- | -| `GENESIS_FORK_VERSION` | `phase0.SignedBeaconBlock` | -| `ALTAIR_FORK_VERSION` | `altair.SignedBeaconBlock` | -| `BELLATRIX_FORK_VERSION` | `bellatrix.SignedBeaconBlock` | -| `EIP4844_FORK_VERSION` | `eip4844.SignedBeaconBlock` | +**Protocol ID:** `/eth2/beacon_chain/req/beacon_block_and_blobs_sidecar_by_root/1/` + +Request Content: + +``` +( + List[Root, MAX_REQUEST_BLOCKS] +) +``` + +Response Content: + +``` +( + List[SignedBeaconBlockAndBlobsSidecar, MAX_REQUEST_BLOCKS] +) +``` + +Requests blocks by block root (= `hash_tree_root(SignedBeaconBlockAndBlobsSidecar.beacon_block.message)`). +The response is a list of `SignedBeaconBlockAndBlobsSidecar` whose length is less than or equal to the number of requests. +It may be less in the case that the responding peer is missing blocks and sidecars. + +No more than `MAX_REQUEST_BLOCKS` may be requested at a time. + +`BeaconBlockAndBlobsSidecarByRoot` is primarily used to recover recent blocks and sidecars (e.g. when receiving a block or attestation whose parent is unknown). + +The response MUST consist of zero or more `response_chunk`. +Each _successful_ `response_chunk` MUST contain a single `SignedBeaconBlockAndBlobsSidecar` payload. + +Clients MUST support requesting blocks and sidecars since the latest finalized epoch. + +Clients MUST respond with at least one block and sidecar, if they have it. +Clients MAY limit the number of blocks and sidecars in the response. #### BlobsSidecarsByRange v1