Merge pull request #2436 from terencechain/patch-122

Sharding p2p: minor fixes

specs/sharding/p2p-interface.md

@@ -17,9 +17,11 @@
   - [SignedShardBlob](#signedshardblob)
 - [Gossip domain](#gossip-domain)
   - [Topics and messages](#topics-and-messages)
-    - [Shard blobs: `shard_blob_{subnet_id}`](#shard-blobs-shard_blob_subnet_id)
-    - [Shard header: `shard_header`](#shard-header-shard_header)
-    - [Shard proposer slashing: `shard_proposer_slashing`](#shard-proposer-slashing-shard_proposer_slashing)
+    - [Shard blob subnets](#shard-blob-subnets)
+      - [`shard_blob_{subnet_id}`](#shard_blob_subnet_id)
+    - [Global topics](#global-topics)
+      - [`shard_header`](#shard_header)
+      - [`shard_proposer_slashing`](#shard_proposer_slashing)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 <!-- /TOC -->
@@ -28,7 +30,7 @@
 ## Introduction
 
 The specification of these changes continues in the same format as the [Phase0](../phase0/p2p-interface.md) and
-[Altair](../altair/p2p-interface.md) network specifications, and assumes them as pre-requisite. 
+[Altair](../altair/p2p-interface.md) network specifications, and assumes them as pre-requisite.
 The adjustments and additions for Shards are outlined in this document.
 
 ## Constants
@@ -89,12 +91,16 @@ Following the same scheme as the [Phase0 gossip topics](../phase0/p2p-interface.
 | Name                             | Message Type              |
 |----------------------------------|---------------------------|
 | `shard_blob_{subnet_id}`         | `SignedShardBlob`         |
-| `shard_header`                   | `SignedShardHeader`       |
+| `shard_header`                   | `SignedShardBlobHeader`   |
 | `shard_proposer_slashing`        | `ShardProposerSlashing`   |
 
 The [DAS network specification](./das-p2p.md) defines additional topics.
 
-#### Shard blobs: `shard_blob_{subnet_id}`
+#### Shard blob subnets
+
+Shard blob subnets are used to propagate shard blobs to subsections of the network.
+
+##### `shard_blob_{subnet_id}`
 
 Shard block data, in the form of a `SignedShardBlob` is published to the `shard_blob_{subnet_id}` subnets.
 
@@ -119,7 +125,7 @@ The following validations MUST pass before forwarding the `signed_blob` (with in
 - _[IGNORE]_ The `blob` is new enough to be still be processed --
   i.e. validate that `compute_epoch_at_slot(blob.slot) >= get_previous_epoch(state)`
 - _[REJECT]_ The shard blob is for the correct subnet --
-  i.e. `compute_subnet_for_shard_blob(state, blob.slot, blob.shard) == subnet_id`  
+  i.e. `compute_subnet_for_shard_blob(state, blob.slot, blob.shard) == subnet_id`
 - _[IGNORE]_ The blob is the first blob with valid signature received for the `(blob.proposer_index, blob.slot, blob.shard)` combination.
 - _[REJECT]_ As already limited by the SSZ list-limit, it is important the blob is well-formatted and not too large.
 - _[REJECT]_ The `blob.body.data` MUST NOT contain any point `p >= MODULUS`. Although it is a `uint256`, not the full 256 bit range is valid.
@@ -130,27 +136,31 @@ The following validations MUST pass before forwarding the `signed_blob` (with in
   the block MAY be queued for later processing while proposers for the blob's branch are calculated --
   in such a case _do not_ `REJECT`, instead `IGNORE` this message.
 
+#### Global topics
+
+There are two additional global topics for Sharding, one is used to propagate shard blob headers (`shard_header`) to
+all nodes on the network. Another one is used to propagate validator message (`shard_proposer_slashing`).
 
-#### Shard header: `shard_header`
+##### `shard_header`
 
 Shard header data, in the form of a `SignedShardBlobHeader` is published to the global `shard_header` subnet.
 
-The following validations MUST pass before forwarding the `signed_shard_header` (with inner `message` as `header`) on the network.
+The following validations MUST pass before forwarding the `signed_shard_blob_header` (with inner `message` as `header`) on the network.
 - _[IGNORE]_ The `header` is not from a future slot (with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance) --
   i.e. validate that `header.slot <= current_slot`
   (a client MAY queue future headers for processing at the appropriate slot).
 - _[IGNORE]_ The `header` is new enough to be still be processed --
   i.e. validate that `compute_epoch_at_slot(header.slot) >= get_previous_epoch(state)`
 - _[IGNORE]_ The header is the first header with valid signature received for the `(header.proposer_index, header.slot, header.shard)` combination.
-- _[REJECT]_ The proposer signature, `signed_shard_header.signature`, is valid with respect to the `proposer_index` pubkey.
+- _[REJECT]_ The proposer signature, `signed_shard_blob_header.signature`, is valid with respect to the `proposer_index` pubkey.
 - _[REJECT]_ The header is proposed by the expected `proposer_index` for the block's slot
   in the context of the current shuffling (defined by `header.body_summary.beacon_block_root`/`slot`).
   If the `proposer_index` cannot immediately be verified against the expected shuffling,
   the block MAY be queued for later processing while proposers for the block's branch are calculated --
   in such a case _do not_ `REJECT`, instead `IGNORE` this message.
 
 
-#### Shard proposer slashing: `shard_proposer_slashing`
+##### `shard_proposer_slashing`
 
 Shard proposer slashings, in the form of `ShardProposerSlashing`, are published to the global `shard_proposer_slashing` topic.