remove redundant index from PoV distribution

roadmap/implementors-guide/src/node/backing/pov-distribution.md

@@ -32,7 +32,7 @@ The view update mechanism of the [Network Bridge](../utility/network-bridge.md)
 
 View updates from peers and our own view updates are received from the network bridge. These will lag somewhat behind the `StartWork` and `StopWork` messages received from the overseer, which will influence the actual data we store. The `OurViewUpdate`s from the [`NetworkBridgeEvent`](../../types/overseer-protocol.md#network-bridge-update) must be considered canonical in terms of our peers' perception of us.
 
-Lastly, the system needs to be bootstrapped with our own perception of which PoVs we are cognizant of but awaiting data for. This is done by receipt of the [`PoVDistributionMessage`](../../types/overseer-protocol.md#pov-distribution-message)::ValidatorStatement variant. We can ignore anything except for `Seconded` statements.
+Lastly, the system needs to be bootstrapped with our own perception of which PoVs we are cognizant of but awaiting data for. This is done by receipt of the [`PoVDistributionMessage`](../../types/overseer-protocol.md#pov-distribution-message)::FetchPoV variant. Proper operation of this subsystem depends on the descriptors passed faithfully representing candidates which have been seconded by other validators.
 
 ## Formal Description
 
@@ -47,7 +47,6 @@ struct State {
 
 struct BlockBasedState {
 	known: Map<Hash, PoV>, // should be a shared PoV in practice. these things are heavy.
-	awaited: Set<Hash>, // awaited PoVs by blake2-256 hash.
 	fetching: Map<Hash, [ResponseChannel<PoV>]>,
 	n_validators: usize,
 }
@@ -83,12 +82,11 @@ Here is the logic of the state machine:
 *PoV Distribution Messages*
 - On `ValidatorStatement(relay_parent, statement)`
 	- If this is not `Statement::Seconded`, ignore.
-	- If there is an entry under `relay_parent` in `relay_parent_state`, add the `pov_hash` of the seconded Candidate's [`CandidateDescriptor`](../../types/candidate.md#candidate-descriptor) to the `awaited` set of the entry.
-	- If the `pov_hash` was not previously awaited and there are `n_validators` or fewer entries in the `awaited` set, send `NetworkMessage::Awaiting(relay_parent, vec![pov_hash])` to all peers.
 - On `FetchPoV(relay_parent, descriptor, response_channel)`
 	- If there is no entry in `relay_parent_state` under `relay_parent`, ignore.
 	- If there is a PoV under `descriptor.pov_hash` in the `known` map, send that PoV on the channel and return.
 	- Otherwise, place the `response_channel` in the `fetching` map under `descriptor.pov_hash`.
+	- If the `pov_hash` had no previous entry in `fetching` and there are `n_validators` or fewer entries in the `fetching` set, send `NetworkMessage::Awaiting(relay_parent, vec![pov_hash])` to all peers.
 - On `DistributePoV(relay_parent, descriptor, PoV)`
 	- If there is no entry in `relay_parent_state` under `relay_parent`, ignore.
 	- Complete and remove any channels under `descriptor.pov_hash` in the `fetching` map.
@@ -105,13 +103,13 @@ Here is the logic of the state machine:
 	- If this is `NetworkMessage::Awaiting(relay_parent, pov_hashes)`:
 		- If there is no entry under `peer_state.awaited` for the `relay_parent`, report and ignore.
 		- If `relay_parent` is not contained within `our_view`, report and ignore.
-		- Otherwise, if the `awaited` map combined with the `pov_hashes` would have more than ` 2 * relay_parent_state[relay_parent].n_validators` entries, report and ignore. Note that we are leaning on the property of the network bridge that it sets our view based on `StartWork` messages.
+		- Otherwise, if the peer's `awaited` map combined with the `pov_hashes` would have more than ` 2 * relay_parent_state[relay_parent].n_validators` entries, report and ignore. Note that we are leaning on the property of the network bridge that it sets our view based on `StartWork` messages.
 		- For each new `pov_hash` in `pov_hashes`, if there is a `pov` under `pov_hash` in the `known` map, send the peer a `NetworkMessage::SendPoV(relay_parent, pov_hash, pov)`.
 		- Otherwise, add the `pov_hash` to the `awaited` map
 	- If this is `NetworkMessage::SendPoV(relay_parent, pov_hash, pov)`:
 		- If there is no entry under `relay_parent` in `relay_parent_state` or no entry under `pov_hash` in our `awaited` map for that `relay_parent`, report and ignore.
 		- If the blake2-256 hash of the pov doesn't equal `pov_hash`, report and ignore.
-		- Complete and remove any listeners in the `fetching` map under `pov_hash`.
+		- Complete and remove any listeners in the `fetching` map under `pov_hash`. However, leave an empty set of listeners in the `fetching` map to denote that this was something we once awaited. This will allow us to recognize peers who have sent us something we were expecting, but just a little late.
 		- Add to `known` map.
 		- Send `NetworkMessage::SendPoV(relay_parent, descriptor.pov_hash, PoV)` to all peers who have the `descriptor.pov_hash` in the set under `relay_parent` in the `peer.awaited` map and remove the entry from `peer.awaited`.
 - On `PeerViewChange(peer_id, view)`

roadmap/implementors-guide/src/types/overseer-protocol.md

@@ -172,11 +172,10 @@ If this subsystem chooses to second a parachain block, it dispatches a `Candidat
 
 ```rust
 enum PoVDistributionMessage {
-	/// Note a statement by a validator on a relay-parent. `Seconded` statements must always
-	/// have been passed in before `Valid` or `Invalid` statements.
-	ValidatorStatement(Hash, SignedFullStatement),
 	/// Fetch a PoV from the network.
-	/// (relay_parent, PoV-hash, Response channel).
+	///
+	/// This `CandidateDescriptor` should correspond to a candidate seconded under the provided
+	/// relay-parent hash.
 	FetchPoV(Hash, CandidateDescriptor, ResponseChannel<PoV>),
 	/// Distribute a PoV for the given relay-parent and CandidateDescriptor.
 	/// The PoV should correctly hash to the PoV hash mentioned in the CandidateDescriptor