From a9c5952658c22b3ec4f70bc0bef72f5937cde5c5 Mon Sep 17 00:00:00 2001 From: Justin Traglia Date: Thu, 16 Jan 2025 13:27:43 -0600 Subject: [PATCH 1/3] Add v1 to req/resp messages in phase0 --- specs/phase0/p2p-interface.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/specs/phase0/p2p-interface.md b/specs/phase0/p2p-interface.md index 41a7b40bb7..71829525c6 100644 --- a/specs/phase0/p2p-interface.md +++ b/specs/phase0/p2p-interface.md @@ -41,12 +41,12 @@ - [Encoding strategies](#encoding-strategies) - [SSZ-snappy encoding strategy](#ssz-snappy-encoding-strategy) - [Messages](#messages) - - [Status](#status) - - [Goodbye](#goodbye) - - [BeaconBlocksByRange](#beaconblocksbyrange) - - [BeaconBlocksByRoot](#beaconblocksbyroot) - - [Ping](#ping) - - [GetMetaData](#getmetadata) + - [Status v1](#status-v1) + - [Goodbye v1](#goodbye-v1) + - [BeaconBlocksByRange v1](#beaconblocksbyrange-v1) + - [BeaconBlocksByRoot v1](#beaconblocksbyroot-v1) + - [Ping v1](#ping-v1) + - [GetMetaData v1](#getmetadata-v1) - [The discovery domain: discv5](#the-discovery-domain-discv5) - [Integration into libp2p stacks](#integration-into-libp2p-stacks) - [ENR structure](#enr-structure) @@ -722,7 +722,7 @@ Each _successful_ `response_chunk` contains a single `SignedBeaconBlock` payload #### Messages -##### Status +##### Status v1 **Protocol ID:** ``/eth2/beacon_chain/req/status/1/`` @@ -770,7 +770,7 @@ SHOULD request beacon blocks from its counterparty via the `BeaconBlocksByRange` the client might need to send `Status` request again to learn if the peer has a higher head. Implementers are free to implement such behavior in their own way. -##### Goodbye +##### Goodbye v1 **Protocol ID:** ``/eth2/beacon_chain/req/goodbye/1/`` @@ -796,7 +796,7 @@ The request/response MUST be encoded as a single SSZ-field. The response MUST consist of a single `response_chunk`. -##### BeaconBlocksByRange +##### BeaconBlocksByRange v1 **Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_range/1/` @@ -875,7 +875,7 @@ In particular when `step == 1`, each `parent_root` MUST match the `hash_tree_roo 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. -##### BeaconBlocksByRoot +##### BeaconBlocksByRoot v1 **Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_root/1/` @@ -918,7 +918,7 @@ Clients SHOULD NOT respond with blocks that fail the beacon chain state transiti `/eth2/beacon_chain/req/beacon_blocks_by_root/1/` is deprecated. Clients MAY respond with an empty list during the deprecation transition period. -##### Ping +##### Ping v1 **Protocol ID:** `/eth2/beacon_chain/req/ping/1/` @@ -950,7 +950,7 @@ The request MUST be encoded as an SSZ-field. The response MUST consist of a single `response_chunk`. -##### GetMetaData +##### GetMetaData v1 **Protocol ID:** `/eth2/beacon_chain/req/metadata/1/` From 7d54cd061315af9e3174a1acf73e0ab8d577ede1 Mon Sep 17 00:00:00 2001 From: Justin Traglia Date: Thu, 16 Jan 2025 13:30:02 -0600 Subject: [PATCH 2/3] For BlobSidecars, put ByRange before ByRoot --- specs/deneb/p2p-interface.md | 128 ++++++++++++++++----------------- specs/electra/p2p-interface.md | 20 +++--- 2 files changed, 74 insertions(+), 74 deletions(-) diff --git a/specs/deneb/p2p-interface.md b/specs/deneb/p2p-interface.md index 2ea35ad500..14a457e203 100644 --- a/specs/deneb/p2p-interface.md +++ b/specs/deneb/p2p-interface.md @@ -30,9 +30,9 @@ - [Messages](#messages) - [BeaconBlocksByRange v2](#beaconblocksbyrange-v2) - [BeaconBlocksByRoot v2](#beaconblocksbyroot-v2) + - [BlobSidecarsByRange v1](#blobsidecarsbyrange-v1) - [BlobSidecarsByRoot v1](#blobsidecarsbyroot-v1) - [Blob retrieval via local execution layer client](#blob-retrieval-via-local-execution-layer-client) - - [BlobSidecarsByRange v1](#blobsidecarsbyrange-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) @@ -271,69 +271,6 @@ No more than `MAX_REQUEST_BLOCKS_DENEB` may be requested at a time. Clients SHOULD include a block in the response as soon as it passes the gossip validation rules. Clients SHOULD NOT respond with blocks that fail the beacon chain state transition. -##### BlobSidecarsByRoot v1 - -**Protocol ID:** `/eth2/beacon_chain/req/blob_sidecars_by_root/1/` - -*[New in Deneb:EIP4844]* - -Request Content: - -``` -( - List[BlobIdentifier, MAX_REQUEST_BLOB_SIDECARS] -) -``` - -Response Content: - -``` -( - List[BlobSidecar, MAX_REQUEST_BLOB_SIDECARS] -) -``` - -Requests sidecars by block root and index. -The response is a list of `BlobSidecar` 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 or sidecars. - -Before consuming the next response chunk, the response reader SHOULD verify the blob sidecar is well-formatted, has valid inclusion proof, and is correct w.r.t. the expected KZG commitments through `verify_blob_kzg_proof`. - -No more than `MAX_REQUEST_BLOB_SIDECARS` may be requested at a time. - -`BlobSidecarsByRoot` is primarily used to recover recent blobs (e.g. when receiving a block with a transaction whose corresponding blob is missing). - -The response MUST consist of zero or more `response_chunk`. -Each _successful_ `response_chunk` MUST contain a single `BlobSidecar` payload. - -Clients MUST support requesting sidecars since `minimum_request_epoch`, where `minimum_request_epoch = max(finalized_epoch, current_epoch - MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, DENEB_FORK_EPOCH)`. If any root in the request content references a block earlier than `minimum_request_epoch`, peers MAY respond with error code `3: ResourceUnavailable` or not include the blob sidecar in the response. - -Clients MUST respond with at least one sidecar, if they have it. -Clients MAY limit the number of blocks and sidecars in the response. - -Clients SHOULD include a sidecar in the response as soon as it passes the gossip validation rules. -Clients SHOULD NOT respond with sidecars related to blocks that fail gossip validation rules. -Clients SHOULD NOT respond with sidecars related to blocks that fail the beacon chain state transition - -For each `response_chunk`, a `ForkDigest`-context based on `compute_fork_version(compute_epoch_at_slot(blob_sidecar.signed_block_header.message.slot))` is used to select the fork namespace of the Response type. - -Per `context = compute_fork_digest(fork_version, genesis_validators_root)`: - -[0]: # (eth2spec: skip) - -| `fork_version` | Chunk SSZ type | -|--------------------------------|---------------------| -| `DENEB_FORK_VERSION` and later | `deneb.BlobSidecar` | - -###### Blob retrieval via local execution layer client - -In addition to `BlobSidecarsByRoot` requests, recent blobs MAY be retrieved by querying the Execution Layer (i.e. via `engine_getBlobsV1`). -Implementers are encouraged to leverage this method to increase the likelihood of incorporating and attesting to the last block when its proposer is not able to publish blobs on time. - -When clients use the local execution layer to retrieve blobs, they MUST behave as if the corresponding `blob_sidecar` had been received via gossip. In particular they MUST: -* publish the corresponding `blob_sidecar` on the `blob_sidecar_{subnet_id}` subnet. -* update gossip rule related data structures (i.e. update the anti-equivocation cache). - ##### BlobSidecarsByRange v1 **Protocol ID:** `/eth2/beacon_chain/req/blob_sidecars_by_range/1/` @@ -418,6 +355,69 @@ Per `context = compute_fork_digest(fork_version, genesis_validators_root)`: |--------------------------------|---------------------| | `DENEB_FORK_VERSION` and later | `deneb.BlobSidecar` | +##### BlobSidecarsByRoot v1 + +**Protocol ID:** `/eth2/beacon_chain/req/blob_sidecars_by_root/1/` + +*[New in Deneb:EIP4844]* + +Request Content: + +``` +( + List[BlobIdentifier, MAX_REQUEST_BLOB_SIDECARS] +) +``` + +Response Content: + +``` +( + List[BlobSidecar, MAX_REQUEST_BLOB_SIDECARS] +) +``` + +Requests sidecars by block root and index. +The response is a list of `BlobSidecar` 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 or sidecars. + +Before consuming the next response chunk, the response reader SHOULD verify the blob sidecar is well-formatted, has valid inclusion proof, and is correct w.r.t. the expected KZG commitments through `verify_blob_kzg_proof`. + +No more than `MAX_REQUEST_BLOB_SIDECARS` may be requested at a time. + +`BlobSidecarsByRoot` is primarily used to recover recent blobs (e.g. when receiving a block with a transaction whose corresponding blob is missing). + +The response MUST consist of zero or more `response_chunk`. +Each _successful_ `response_chunk` MUST contain a single `BlobSidecar` payload. + +Clients MUST support requesting sidecars since `minimum_request_epoch`, where `minimum_request_epoch = max(finalized_epoch, current_epoch - MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, DENEB_FORK_EPOCH)`. If any root in the request content references a block earlier than `minimum_request_epoch`, peers MAY respond with error code `3: ResourceUnavailable` or not include the blob sidecar in the response. + +Clients MUST respond with at least one sidecar, if they have it. +Clients MAY limit the number of blocks and sidecars in the response. + +Clients SHOULD include a sidecar in the response as soon as it passes the gossip validation rules. +Clients SHOULD NOT respond with sidecars related to blocks that fail gossip validation rules. +Clients SHOULD NOT respond with sidecars related to blocks that fail the beacon chain state transition + +For each `response_chunk`, a `ForkDigest`-context based on `compute_fork_version(compute_epoch_at_slot(blob_sidecar.signed_block_header.message.slot))` is used to select the fork namespace of the Response type. + +Per `context = compute_fork_digest(fork_version, genesis_validators_root)`: + +[0]: # (eth2spec: skip) + +| `fork_version` | Chunk SSZ type | +|--------------------------------|---------------------| +| `DENEB_FORK_VERSION` and later | `deneb.BlobSidecar` | + +###### Blob retrieval via local execution layer client + +In addition to `BlobSidecarsByRoot` requests, recent blobs MAY be retrieved by querying the Execution Layer (i.e. via `engine_getBlobsV1`). +Implementers are encouraged to leverage this method to increase the likelihood of incorporating and attesting to the last block when its proposer is not able to publish blobs on time. + +When clients use the local execution layer to retrieve blobs, they MUST behave as if the corresponding `blob_sidecar` had been received via gossip. In particular they MUST: +* publish the corresponding `blob_sidecar` on the `blob_sidecar_{subnet_id}` subnet. +* update gossip rule related data structures (i.e. update the anti-equivocation cache). + ## Design decision rationale ### Why are blobs relayed as a sidecar, separate from beacon blocks? diff --git a/specs/electra/p2p-interface.md b/specs/electra/p2p-interface.md index a34c70478e..a0b0b28422 100644 --- a/specs/electra/p2p-interface.md +++ b/specs/electra/p2p-interface.md @@ -23,8 +23,8 @@ - [Messages](#messages) - [BeaconBlocksByRange v2](#beaconblocksbyrange-v2) - [BeaconBlocksByRoot v2](#beaconblocksbyroot-v2) - - [BlobSidecarsByRoot v1](#blobsidecarsbyroot-v1) - [BlobSidecarsByRange v1](#blobsidecarsbyrange-v1) + - [BlobSidecarsByRoot v1](#blobsidecarsbyroot-v1) @@ -150,9 +150,9 @@ Per `context = compute_fork_digest(fork_version, genesis_validators_root)`: | `DENEB_FORK_VERSION` | `deneb.SignedBeaconBlock` | | `ELECTRA_FORK_VERSION` | `electra.SignedBeaconBlock` | -##### BlobSidecarsByRoot v1 +##### BlobSidecarsByRange v1 -**Protocol ID:** `/eth2/beacon_chain/req/blob_sidecars_by_root/1/` +**Protocol ID:** `/eth2/beacon_chain/req/blob_sidecars_by_range/1/` *[Modified in Electra:EIP7691]* @@ -160,7 +160,8 @@ Request Content: ``` ( - List[BlobIdentifier, MAX_REQUEST_BLOB_SIDECARS_ELECTRA] + start_slot: Slot + count: uint64 ) ``` @@ -174,11 +175,11 @@ Response Content: *Updated validation* -No more than `MAX_REQUEST_BLOB_SIDECARS_ELECTRA` may be requested at a time. +Clients MUST respond with at least the blob sidecars of the first blob-carrying block that exists in the range, if they have it, and no more than `MAX_REQUEST_BLOB_SIDECARS_ELECTRA` sidecars. -##### BlobSidecarsByRange v1 +##### BlobSidecarsByRoot v1 -**Protocol ID:** `/eth2/beacon_chain/req/blob_sidecars_by_range/1/` +**Protocol ID:** `/eth2/beacon_chain/req/blob_sidecars_by_root/1/` *[Modified in Electra:EIP7691]* @@ -186,8 +187,7 @@ Request Content: ``` ( - start_slot: Slot - count: uint64 + List[BlobIdentifier, MAX_REQUEST_BLOB_SIDECARS_ELECTRA] ) ``` @@ -201,4 +201,4 @@ Response Content: *Updated validation* -Clients MUST respond with at least the blob sidecars of the first blob-carrying block that exists in the range, if they have it, and no more than `MAX_REQUEST_BLOB_SIDECARS_ELECTRA` sidecars. +No more than `MAX_REQUEST_BLOB_SIDECARS_ELECTRA` may be requested at a time. From 155d15ebc301c8e4731131b69adaeaa18a056a5e Mon Sep 17 00:00:00 2001 From: Justin Traglia Date: Thu, 16 Jan 2025 13:33:22 -0600 Subject: [PATCH 3/3] For DataColumnSidecars, put ByRange before ByRoot --- specs/fulu/p2p-interface.md | 102 ++++++++++++++++++------------------ 1 file changed, 51 insertions(+), 51 deletions(-) diff --git a/specs/fulu/p2p-interface.md b/specs/fulu/p2p-interface.md index bd4e2fb89c..b721847b02 100644 --- a/specs/fulu/p2p-interface.md +++ b/specs/fulu/p2p-interface.md @@ -29,8 +29,8 @@ - [`data_column_sidecar_{subnet_id}`](#data_column_sidecar_subnet_id) - [The Req/Resp domain](#the-reqresp-domain) - [Messages](#messages) - - [DataColumnSidecarsByRoot v1](#datacolumnsidecarsbyroot-v1) - [DataColumnSidecarsByRange v1](#datacolumnsidecarsbyrange-v1) + - [DataColumnSidecarsByRoot v1](#datacolumnsidecarsbyroot-v1) - [GetMetaData v3](#getmetadata-v3) - [The discovery domain: discv5](#the-discovery-domain-discv5) - [ENR structure](#enr-structure) @@ -208,56 +208,6 @@ The following validations MUST pass before forwarding the `sidecar: DataColumnSi #### Messages -##### DataColumnSidecarsByRoot v1 - -**Protocol ID:** `/eth2/beacon_chain/req/data_column_sidecars_by_root/1/` - -*[New in Fulu:EIP7594]* - -The `` field is calculated as `context = compute_fork_digest(fork_version, genesis_validators_root)`: - -[1]: # (eth2spec: skip) - -| `fork_version` | Chunk SSZ type | -|---------------------|--------------------------| -| `FULU_FORK_VERSION` | `fulu.DataColumnSidecar` | - -Request Content: - -``` -( - List[DataColumnIdentifier, MAX_REQUEST_DATA_COLUMN_SIDECARS] -) -``` - -Response Content: - -``` -( - List[DataColumnSidecar, MAX_REQUEST_DATA_COLUMN_SIDECARS] -) -``` - -Requests sidecars by block root and index. -The response is a list of `DataColumnIdentifier` 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 or sidecars. - -Before consuming the next response chunk, the response reader SHOULD verify the data column sidecar is well-formatted through `verify_data_column_sidecar`, has valid inclusion proof through `verify_data_column_sidecar_inclusion_proof`, and is correct w.r.t. the expected KZG commitments through `verify_data_column_sidecar_kzg_proofs`. - -No more than `MAX_REQUEST_DATA_COLUMN_SIDECARS` may be requested at a time. - -The response MUST consist of zero or more `response_chunk`. -Each _successful_ `response_chunk` MUST contain a single `DataColumnSidecar` payload. - -Clients MUST support requesting sidecars since `minimum_request_epoch`, where `minimum_request_epoch = max(finalized_epoch, current_epoch - MIN_EPOCHS_FOR_DATA_COLUMN_SIDECARS_REQUESTS, FULU_FORK_EPOCH)`. If any root in the request content references a block earlier than `minimum_request_epoch`, peers MAY respond with error code `3: ResourceUnavailable` or not include the data column sidecar in the response. - -Clients MUST respond with at least one sidecar, if they have it. -Clients MAY limit the number of blocks and sidecars in the response. - -Clients SHOULD include a sidecar in the response as soon as it passes the gossip validation rules. -Clients SHOULD NOT respond with sidecars related to blocks that fail gossip validation rules. -Clients SHOULD NOT respond with sidecars related to blocks that fail the beacon chain state transition - ##### DataColumnSidecarsByRange v1 **Protocol ID:** `/eth2/beacon_chain/req/data_column_sidecars_by_range/1/` @@ -339,6 +289,56 @@ Clients MUST respond with data column sidecars that are consistent from a single After the initial data column sidecar, clients MAY stop in the process of responding if their fork choice changes the view of the chain in the context of the request. +##### DataColumnSidecarsByRoot v1 + +**Protocol ID:** `/eth2/beacon_chain/req/data_column_sidecars_by_root/1/` + +*[New in Fulu:EIP7594]* + +The `` field is calculated as `context = compute_fork_digest(fork_version, genesis_validators_root)`: + +[1]: # (eth2spec: skip) + +| `fork_version` | Chunk SSZ type | +|---------------------|--------------------------| +| `FULU_FORK_VERSION` | `fulu.DataColumnSidecar` | + +Request Content: + +``` +( + List[DataColumnIdentifier, MAX_REQUEST_DATA_COLUMN_SIDECARS] +) +``` + +Response Content: + +``` +( + List[DataColumnSidecar, MAX_REQUEST_DATA_COLUMN_SIDECARS] +) +``` + +Requests sidecars by block root and index. +The response is a list of `DataColumnIdentifier` 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 or sidecars. + +Before consuming the next response chunk, the response reader SHOULD verify the data column sidecar is well-formatted through `verify_data_column_sidecar`, has valid inclusion proof through `verify_data_column_sidecar_inclusion_proof`, and is correct w.r.t. the expected KZG commitments through `verify_data_column_sidecar_kzg_proofs`. + +No more than `MAX_REQUEST_DATA_COLUMN_SIDECARS` may be requested at a time. + +The response MUST consist of zero or more `response_chunk`. +Each _successful_ `response_chunk` MUST contain a single `DataColumnSidecar` payload. + +Clients MUST support requesting sidecars since `minimum_request_epoch`, where `minimum_request_epoch = max(finalized_epoch, current_epoch - MIN_EPOCHS_FOR_DATA_COLUMN_SIDECARS_REQUESTS, FULU_FORK_EPOCH)`. If any root in the request content references a block earlier than `minimum_request_epoch`, peers MAY respond with error code `3: ResourceUnavailable` or not include the data column sidecar in the response. + +Clients MUST respond with at least one sidecar, if they have it. +Clients MAY limit the number of blocks and sidecars in the response. + +Clients SHOULD include a sidecar in the response as soon as it passes the gossip validation rules. +Clients SHOULD NOT respond with sidecars related to blocks that fail gossip validation rules. +Clients SHOULD NOT respond with sidecars related to blocks that fail the beacon chain state transition + ##### GetMetaData v3 **Protocol ID:** `/eth2/beacon_chain/req/metadata/3/`