pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-05-30 15:11:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

remove unused RequestBlockAuthorshipData (#2455)

Browse Source
This commit is contained in:
Robert Habermeier
2021-02-17 11:54:51 -06:00
committed by GitHub
parent 4004217059
commit 59e2a810bb
5 changed files with 5 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/roadmap/implementers-guide/src/node/subsystems-and-jobs.md
+2 -6
View File
@@ -382,10 +382,7 @@ sequenceDiagram
participant RA as RuntimeApi
participant PO as Proposer
alt receive request to forward block authorship data
A ->> PV: RequestBlockAuthorshipData
Note over A,PV: This request contains a mpsc::Sender, which the Provisioner keeps
else receive provisionable data
alt receive provisionable data
alt
CB ->> PV: ProvisionableData
else
@@ -415,8 +412,7 @@ sequenceDiagram
```
In principle, any arbitrary subsystem could send a `RequestInherentData` to the `Provisioner`. In practice,
only the `Proposer` does so. Likewise, any arbitrary subsystem could send a `RequestBlockAuthorshipData`; the
distinction is that no subsystem currently does so.
only the `Proposer` does so.
The proposer is an atypical subsystem in that, unlike most of them, it is not primarily driven by
the `Overseer`, but instead by the `sp_consensus::Environment` and `sp_consensus::Proposer` traits
polkadot/roadmap/implementers-guide/src/node/utility/provisioner.md
+2 -4
View File
@@ -34,9 +34,9 @@ Dispute resolution is complex and is explained in substantially more detail [her
Input: [`ProvisionerMessage`](../../types/overseer-protocol.md#provisioner-message). Backed candidates come from the [Candidate Backing subsystem](../backing/candidate-backing.md), signed bitfields come from the [Bitfield Distribution subsystem](../availability/bitfield-distribution.md), and misbehavior reports and disputes come from the [Misbehavior Arbitration subsystem](misbehavior-arbitration.md).
At initialization, this subsystem has no outputs. Block authors can send a `ProvisionerMessage::RequestBlockAuthorshipData`, which includes a channel over which provisionable data can be sent. All appropriate provisionable data will then be sent over this channel, as it is received.
At initialization, this subsystem has no outputs.
Note that block authors must re-send a `ProvisionerMessage::RequestBlockAuthorshipData` for each relay parent they are interested in receiving provisionable data for.
Block authors request the inherent data they should use for constructing the inherent in the block which contains parachain execution information.
## Block Production
@@ -89,8 +89,6 @@ To compute bitfield availability, then:
See also: [Scheduler Module: Availability Cores](../../runtime/scheduler.md#availability-cores).
One might ask: given `ProvisionerMessage::RequestInherentData`, what's the point of `ProvisionerMessage::RequestBlockAuthorshipData`? The answer is that the block authorship data includes more information than is present in the inherent data; disputes, for example.
## Functionality
The subsystem should maintain a set of handles to Block Authorship Provisioning Jobs that are currently live.
polkadot/roadmap/implementers-guide/src/types/overseer-protocol.md
-3
View File
@@ -453,9 +453,6 @@ enum ProvisionableData {
///
/// In all cases, the Hash is that of the relay parent.
enum ProvisionerMessage {
/// This message allows potential block authors to be kept updated with all new authorship data
/// as it becomes available.
RequestBlockAuthorshipData(Hash, Sender<ProvisionableData>),
/// This message allows external subsystems to request current inherent data that could be used for
/// advancing the state of parachain consensus in a block building upon the given hash.
///