pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-06-19 17:01:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

Replace StartWork and StopWork with an ActiveLeavesUpdate signal (#1431)

Browse Source
This commit is contained in:
Robert Habermeier
2020-07-22 12:12:49 -04:00
committed by GitHub
parent 42ddcada02
commit 5be366d6dc
10 changed files with 55 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/roadmap/implementers-guide/src/node/backing/pov-distribution.md
+9 -8
View File
@@ -30,7 +30,7 @@ For this, in order to avoid reaching into the internals of the [Statement Distri
The view update mechanism of the [Network Bridge](../utility/network-bridge.md) ensures that peers are only allowed to consider a certain set of relay-parents as live. So this bounding mechanism caps the amount of data we need to store per peer at any time at `sum({ 2 * n_validators_at_head(head) * sizeof(hash) for head in view_heads })`. Additionally, peers should only be allowed to notify us of PoV hashes they are waiting for in the context of relay-parents in our own local view, which means that `n_validators_at_head` is implied to be `0` for relay-parents not in our own local view.
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.
View updates from peers and our own view updates are received from the network bridge. These will lag somewhat behind the `ActiveLeavesUpdate` 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)::FetchPoV variant. Proper operation of this subsystem depends on the descriptors passed faithfully representing candidates which have been seconded by other validators.
@@ -72,12 +72,13 @@ enum NetworkMessage {
Here is the logic of the state machine:
*Overseer Signals*
- On `StartWork(relay_parent)`:
- Get the number of validators at that relay parent by querying the [Runtime API](../utility/runtime-api.md) for the validators and then counting them.
- Create a blank entry in `relay_parent_state` under `relay_parent` with correct `n_validators` set.
- On `StopWork(relay_parent)`:
- Remove the entry for `relay_parent` from `relay_parent_state`.
- On `Concluded`: conclude.
- On `ActiveLeavesUpdate(relay_parent)`:
- For each relay-parent in the `activated` list:
- Get the number of validators at that relay parent by querying the [Runtime API](../utility/runtime-api.md) for the validators and then counting them.
- Create a blank entry in `relay_parent_state` under `relay_parent` with correct `n_validators` set.
- For each relay-parent in the `deactivated` list:
- Remove the entry for `relay_parent` from `relay_parent_state`.
- On `Conclude`: conclude.
*PoV Distribution Messages*
- On `FetchPoV(relay_parent, descriptor, response_channel)`
@@ -101,7 +102,7 @@ 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 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.
- 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 `activated` heads in `ActiveLeavesUpdate` signals.
- 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)`: