Prepare for network protocol version upgrades (#5084)

* explicitly tag network requests with version * fmt * make PeerSet more aware of versioning * some generalization of the network bridge to support upgrades * walk back some renaming * walk back some version stuff * extract version from fallback * remove V1 from NetworkBridgeUpdate * add accidentally-removed timer * implement focusing for versioned messages * fmt * fix up network bridge & tests * remove inaccurate version check in bridge * remove some TODO [now]s * fix fallout in statement distribution * fmt * fallout in gossip-support * fix fallout in collator-protocol * fix fallout in bitfield-distribution * fix fallout in approval-distribution * fmt * use never! * fmt
2026-04-30 07:17:56 +00:00 · 2022-04-21 11:34:59 -05:00
parent 203441981f
commit fc4b04db20
45 changed files with 942 additions and 594 deletions
@@ -39,7 +39,7 @@ Input:
  - `ApprovalDistributionMessage::NewBlocks`
  - `ApprovalDistributionMessage::DistributeAssignment`
  - `ApprovalDistributionMessage::DistributeApproval`
-  - `ApprovalDistributionMessage::NetworkBridgeUpdateV1`
+  - `ApprovalDistributionMessage::NetworkBridgeUpdate`
  - `OverseerSignal::BlockFinalized`

 Output:
@@ -10,7 +10,7 @@ This version of the availability recovery subsystem is based off of direct conne

 Input:

- `NetworkBridgeUpdateV1(update)`
+- `NetworkBridgeUpdate(update)`
 - `AvailabilityRecoveryMessage::RecoverAvailableData(candidate, session, backing_group, response)`

 Output:
@@ -14,7 +14,7 @@ Input:
 Output:

 - `NetworkBridge::SendMessage(PeerId, message)`
- `NetworkBridge::SendRequests(StatementFetching)`
+- `NetworkBridge::SendRequests(StatementFetchingV1)`
 - `NetworkBridge::ReportPeer(PeerId, cost_or_benefit)`

 ## Functionality
@@ -86,7 +86,7 @@ example. For this reason, there exists a `LargeStatement` constructor for the
 of a statement. The actual candidate data is not included. This message type is
 used whenever a message is deemed large. The receiver of such a message needs to
 request the actual payload via request/response by means of a
-`StatementFetching` request.
+`StatementFetchingV1` request.

 This is necessary as distribution of a large payload (mega bytes) via gossip
 would make the network collapse and timely distribution of statements would no
@@ -104,7 +104,7 @@ The protocol tracks advertisements received and the source of the advertisement.

 As a validator, we will handle requests from other subsystems to fetch a collation on a specific `ParaId` and relay-parent. These requests are made with the request response protocol `CollationFetchingRequest` request. To do so, we need to first check if we have already gathered a collation on that `ParaId` and relay-parent. If not, we need to select one of the advertisements and issue a request for it. If we've already issued a request, we shouldn't issue another one until the first has returned.

-When acting on an advertisement, we issue a `Requests::CollationFetching`. However, we only request one collation at a time per relay parent. This reduces the bandwidth requirements and as we can second only one candidate per relay parent, the others are probably not required anyway. If the request times out, we need to note the collator as being unreliable and reduce its priority relative to other collators.
+When acting on an advertisement, we issue a `Requests::CollationFetchingV1`. However, we only request one collation at a time per relay parent. This reduces the bandwidth requirements and as we can second only one candidate per relay parent, the others are probably not required anyway. If the request times out, we need to note the collator as being unreliable and reduce its priority relative to other collators.

 As a validator, once the collation has been fetched some other subsystem will inspect and do deeper validation of the collation. The subsystem will report to this subsystem with a [`CollatorProtocolMessage`][CPM]`::ReportCollator`. In that case, if we are connected directly to the collator, we apply a cost to the `PeerId` associated with the collator and potentially disconnect or blacklist it. If the collation is seconded, we notify the collator and apply a benefit to the `PeerId` associated with the collator.

@@ -103,11 +103,11 @@ digraph {
    coll_prot   -> net_brdg     [arrowhead = "onormal", label = "RequestCollation"]
    coll_prot   -> cand_sel     [arrowhead = "onormal", label = "Collation"]

-    net_brdg    -> avail_dist   [arrowhead = "onormal", label = "NetworkBridgeUpdateV1"]
-    net_brdg    -> bitf_dist    [arrowhead = "onormal", label = "NetworkBridgeUpdateV1"]
-    net_brdg    -> pov_dist     [arrowhead = "onormal", label = "NetworkBridgeUpdateV1"]
-    net_brdg    -> stmt_dist    [arrowhead = "onormal", label = "NetworkBridgeUpdateV1"]
-    net_brdg    -> coll_prot    [arrowhead = "onormal", label = "NetworkBridgeUpdateV1"]
+    net_brdg    -> avail_dist   [arrowhead = "onormal", label = "NetworkBridgeUpdate"]
+    net_brdg    -> bitf_dist    [arrowhead = "onormal", label = "NetworkBridgeUpdate"]
+    net_brdg    -> pov_dist     [arrowhead = "onormal", label = "NetworkBridgeUpdate"]
+    net_brdg    -> stmt_dist    [arrowhead = "onormal", label = "NetworkBridgeUpdate"]
+    net_brdg    -> coll_prot    [arrowhead = "onormal", label = "NetworkBridgeUpdate"]

    pov_dist    -> net_brdg     [arrowhead = "onormal", label = "SendValidationMessage"]
    pov_dist    -> net_brdg     [arrowhead = "onormal", label = "ReportPeer"]
@@ -264,7 +264,7 @@ sequenceDiagram

        Note right of NB: Bridge sends validation message to all appropriate peers
    else On receipt of peer validation message
-        NB ->> SD: NetworkBridgeUpdateV1
+        NB ->> SD: NetworkBridgeUpdate

        % fn handle_incoming_message
        alt if we aren't already aware of the relay parent for this statement
@@ -21,10 +21,10 @@ Input: [`NetworkBridgeMessage`][NBM]


 Output:
-	- [`ApprovalDistributionMessage`][AppD]`::NetworkBridgeUpdateV1`
-	- [`BitfieldDistributionMessage`][BitD]`::NetworkBridgeUpdateV1`
-	- [`CollatorProtocolMessage`][CollP]`::NetworkBridgeUpdateV1`
-	- [`StatementDistributionMessage`][StmtD]`::NetworkBridgeUpdateV1`
+	- [`ApprovalDistributionMessage`][AppD]`::NetworkBridgeUpdate`
+	- [`BitfieldDistributionMessage`][BitD]`::NetworkBridgeUpdate`
+	- [`CollatorProtocolMessage`][CollP]`::NetworkBridgeUpdate`
+	- [`StatementDistributionMessage`][StmtD]`::NetworkBridgeUpdate`

 ## Functionality

@@ -108,7 +108,7 @@ Map the message onto the corresponding [Event Handler](#event-handlers) based on

 ### `NewGossipTopology`

- Map all `AuthorityDiscoveryId`s to `PeerId`s and issue a corresponding `NetworkBridgeUpdateV1`
+- Map all `AuthorityDiscoveryId`s to `PeerId`s and issue a corresponding `NetworkBridgeUpdate`
  to all validation subsystems.

 ## Event Handlers
@@ -117,13 +117,13 @@ Network bridge event handlers are the intended recipients of particular network

 ### Validation V1

-* `ApprovalDistributionV1Message -> ApprovalDistributionMessage::NetworkBridgeUpdateV1`
-* `BitfieldDistributionV1Message -> BitfieldDistributionMessage::NetworkBridgeUpdateV1`
-* `StatementDistributionV1Message -> StatementDistributionMessage::NetworkBridgeUpdateV1`
+* `ApprovalDistributionV1Message -> ApprovalDistributionMessage::NetworkBridgeUpdate`
+* `BitfieldDistributionV1Message -> BitfieldDistributionMessage::NetworkBridgeUpdate`
+* `StatementDistributionV1Message -> StatementDistributionMessage::NetworkBridgeUpdate`

 ### Collation V1

-* `CollatorProtocolV1Message -> CollatorProtocolMessage::NetworkBridgeUpdateV1`
+* `CollatorProtocolV1Message -> CollatorProtocolMessage::NetworkBridgeUpdate`

 [NBM]: ../../types/overseer-protocol.md#network-bridge-message
 [AppD]: ../../types/overseer-protocol.md#approval-distribution-message