|
17 | 17 | - [`verify_data_column_sidecar_kzg_proofs`](#verify_data_column_sidecar_kzg_proofs) |
18 | 18 | - [`verify_data_column_sidecar_inclusion_proof`](#verify_data_column_sidecar_inclusion_proof) |
19 | 19 | - [`compute_subnet_for_data_column_sidecar`](#compute_subnet_for_data_column_sidecar) |
| 20 | + - [MetaData](#metadata) |
20 | 21 | - [The gossip domain: gossipsub](#the-gossip-domain-gossipsub) |
21 | 22 | - [Topics and messages](#topics-and-messages) |
22 | 23 | - [Blob subnets](#blob-subnets) |
|
26 | 27 | - [Messages](#messages) |
27 | 28 | - [DataColumnSidecarsByRoot v1](#datacolumnsidecarsbyroot-v1) |
28 | 29 | - [DataColumnSidecarsByRange v1](#datacolumnsidecarsbyrange-v1) |
| 30 | + - [GetMetaData v3](#getmetadata-v3) |
29 | 31 | - [The discovery domain: discv5](#the-discovery-domain-discv5) |
30 | 32 | - [ENR structure](#enr-structure) |
31 | 33 | - [Custody subnet count](#custody-subnet-count) |
@@ -109,6 +111,24 @@ def compute_subnet_for_data_column_sidecar(column_index: ColumnIndex) -> SubnetI |
109 | 111 | return SubnetID(column_index % DATA_COLUMN_SIDECAR_SUBNET_COUNT) |
110 | 112 | ``` |
111 | 113 |
|
| 114 | +### MetaData |
| 115 | + |
| 116 | +The `MetaData` stored locally by clients is updated with an additional field to communicate the custody subnet count. |
| 117 | + |
| 118 | +``` |
| 119 | +( |
| 120 | + seq_number: uint64 |
| 121 | + attnets: Bitvector[ATTESTATION_SUBNET_COUNT] |
| 122 | + syncnets: Bitvector[SYNC_COMMITTEE_SUBNET_COUNT] |
| 123 | + custody_subnet_count: uint64 |
| 124 | +) |
| 125 | +``` |
| 126 | + |
| 127 | +Where |
| 128 | + |
| 129 | +- `seq_number`, `attnets`, and `syncnets` have the same meaning defined in the Altair document. |
| 130 | +- `custody_subnet_count` represents the node's custody subnet count. Clients MAY reject ENRs with a value less than `CUSTODY_REQUIREMENT`. |
| 131 | + |
112 | 132 | ### The gossip domain: gossipsub |
113 | 133 |
|
114 | 134 | Some gossip meshes are upgraded in the EIP-7594 fork to support upgraded types. |
@@ -279,6 +299,22 @@ Clients MUST respond with data column sidecars that are consistent from a single |
279 | 299 |
|
280 | 300 | 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. |
281 | 301 |
|
| 302 | +##### GetMetaData v3 |
| 303 | + |
| 304 | +**Protocol ID:** `/eth2/beacon_chain/req/metadata/3/` |
| 305 | + |
| 306 | +No Request Content. |
| 307 | + |
| 308 | +Response Content: |
| 309 | + |
| 310 | +``` |
| 311 | +( |
| 312 | + MetaData |
| 313 | +) |
| 314 | +``` |
| 315 | + |
| 316 | +Requests the MetaData of a peer, using the new `MetaData` definition given above that is extended from Altair. Other conditions for the `GetMetaData` protocol are unchanged from the Altair p2p networking document. |
| 317 | + |
282 | 318 | ### The discovery domain: discv5 |
283 | 319 |
|
284 | 320 | #### ENR structure |
|
0 commit comments