From 29f3ffbc6f66507c2974c2a327562864a3658f07 Mon Sep 17 00:00:00 2001 From: Peter Goodspeed-Niklaus Date: Fri, 12 Jun 2020 16:51:03 +0200 Subject: [PATCH 1/5] update provisioner subsystem Closes #1143 --- .../src/node/backing/candidate-backing.md | 2 +- .../src/node/utility/provisioner.md | 44 ++++++++++++------- .../src/type-definitions.md | 18 ++++++++ 3 files changed, 47 insertions(+), 17 deletions(-) diff --git a/roadmap/implementors-guide/src/node/backing/candidate-backing.md b/roadmap/implementors-guide/src/node/backing/candidate-backing.md index 697db2381ebb..c4737f75e01e 100644 --- a/roadmap/implementors-guide/src/node/backing/candidate-backing.md +++ b/roadmap/implementors-guide/src/node/backing/candidate-backing.md @@ -6,7 +6,7 @@ Its role is to produce backable candidates for inclusion in new relay-chain bloc Note that though the candidate backing subsystem attempts to produce as many backable candidates as possible, it does _not_ attempt to choose a single authoritative one. The choice of which actually gets included is ultimately up to the block author, by whatever metrics it may use; those are opaque to this subsystem. -Once a sufficient quorum has agreed that a candidate is valid, this subsystem notifies the [Overseer](/node/overseer.html), which in turn engages block production mechanisms to include the parablock. +Once a sufficient quorum has agreed that a candidate is valid, this subsystem notifies the [Provisioner](/node/utility/provisioner.html), which in turn engages block production mechanisms to include the parablock. ## Protocol diff --git a/roadmap/implementors-guide/src/node/utility/provisioner.md b/roadmap/implementors-guide/src/node/utility/provisioner.md index 6c6c3c17cd3b..190f9cb7ae73 100644 --- a/roadmap/implementors-guide/src/node/utility/provisioner.md +++ b/roadmap/implementors-guide/src/node/utility/provisioner.md @@ -1,30 +1,42 @@ # Provisioner -This subsystem is responsible for providing data to an external block authorship service beyond the scope of the [Overseer](/node/overseer.html) so that the block authorship service can author blocks containing data produced by various subsystems. +Relay chain block authorship authority is governed by BABE and is beyond the scope of the Overseer and the rest of the subsystems. That said, ultimately the block author needs to select a set of backable parachain candidates and other consensus data, and assemble a block from them. This subsystem is responsible for providing the necessary data to all potential block authors. -In particular, the data to provide: +A major feature of the provisioner: this subsystem is responsible for ensuring that parachain block candidates are sufficiently available before sending them to potential block authors. -- backable candidates and their backings -- signed bitfields -- misbehavior reports -- dispute inherent - > TODO: needs fleshing out in validity module, related to blacklisting +## Provisionable Data -## Protocol +### Backable Candidates + +The block author can choose 0 or 1 backable parachain candidates per parachain; the only constraint is that each backable candidate has the appropriate relay parent. However, the choice of a backable candidate must be the block author's; the provisioner must ensure that block authors are aware of all available backable candidates. + +> TODO: "and their backings": why? + +### Signed Bitfields + +Signed bitfields are attestations from a particular validator about which candidates it believes are available. + +> TODO: Are these actually included in the relay chain block, or just used to help decide whether a block is available and therefore a backable candidate? + +### Misbehavior Reports -Input: +Misbehavior reports contain proof that a validator or set of validators has misbehaved; they consist of a proof of some kind of misbehavior: double-voting, being the minority vote in a disputed block's vote, etc. These cause dots to be slashed and must be included in the block. -- Bitfield(relay_parent, signed_bitfield) -- BackableCandidate(relay_parent, candidate_receipt, backing) -- RequestBlockAuthorshipData(relay_parent, response_channel) +> TODO: This problem is mentioned elsewhere, but how do we force the block author to include a misbehavior report if they don't like its effects, i.e. they are among the nodes which get slashed? + +### Dispute Inherent + +> TODO: Is this different from a misbehavior report? How? + +## Protocol + +Input: [`ProvisionerMessage`](/type-definitions.html#provisioner-message) ## Functionality Use `StartWork` and `StopWork` to manage a set of jobs for relay-parents we might be building upon. -Forward all messages to corresponding job, if any. +Forward all messages to corresponding job. ## Block Authorship Provisioning Job -Track all signed bitfields, all backable candidates received. Provide them to the `RequestBlockAuthorshipData` requester via the `response_channel`. If more than one backable candidate exists for a given `Para`, provide the first one received. - -> TODO: better candidate-choice rules. +Track all signed bitfields, all backable candidates received. Provide them to the `RequestBlockAuthorshipData` requester via the `response_channel`. diff --git a/roadmap/implementors-guide/src/type-definitions.md b/roadmap/implementors-guide/src/type-definitions.md index 793078610818..7843fbddfef9 100644 --- a/roadmap/implementors-guide/src/type-definitions.md +++ b/roadmap/implementors-guide/src/type-definitions.md @@ -173,6 +173,24 @@ enum MisbehaviorArbitrationMessage { } ``` +## Provisioner Message + +```rust +/// Message to the Provisioner. +/// +/// In all cases, the Hash is that of the relay parent. +enum ProvisionerMessage { + /// This bitfield indicates the availability of various candidate blocks. + Bitfield(Hash, SignedAvailabilityBitfield), + /// The Candidate Backing subsystem believes that this candidate is backable, pending availability. + /// TODO: do we need any more data than this? + BackableCandidate(Hash, CandidateReceipt), + /// This message allows potential block authors to be kept updated with all new authorship data + /// as it becomes available. + RequestBlockAuthorshipData(Hash, Sender), +} +``` + ## Host Configuration The internal-to-runtime configuration of the parachain host. This is expected to be altered only by governance procedures. From 44e25d572d97a0d86945f94bbab96673e56cae8b Mon Sep 17 00:00:00 2001 From: Peter Goodspeed-Niklaus Date: Mon, 15 Jun 2020 10:56:27 +0200 Subject: [PATCH 2/5] update with answers to the questions posed by previous todos --- .../src/node/utility/provisioner.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/roadmap/implementors-guide/src/node/utility/provisioner.md b/roadmap/implementors-guide/src/node/utility/provisioner.md index 190f9cb7ae73..37a88148de0e 100644 --- a/roadmap/implementors-guide/src/node/utility/provisioner.md +++ b/roadmap/implementors-guide/src/node/utility/provisioner.md @@ -6,27 +6,27 @@ A major feature of the provisioner: this subsystem is responsible for ensuring t ## Provisionable Data -### Backable Candidates +There are several distinct types of provisionable data, but they share this property in common: all should eventually be included in a relay chain block. -The block author can choose 0 or 1 backable parachain candidates per parachain; the only constraint is that each backable candidate has the appropriate relay parent. However, the choice of a backable candidate must be the block author's; the provisioner must ensure that block authors are aware of all available backable candidates. +### Backed Candidates -> TODO: "and their backings": why? +The block author can choose 0 or 1 backed parachain candidates per parachain; the only constraint is that each backed candidate has the appropriate relay parent. However, the choice of a backed candidate must be the block author's; the provisioner must ensure that block authors are aware of all available [`BackedCandidate`s](/type-definitions.html#backed-candidate). ### Signed Bitfields -Signed bitfields are attestations from a particular validator about which candidates it believes are available. - -> TODO: Are these actually included in the relay chain block, or just used to help decide whether a block is available and therefore a backable candidate? +[Signed bitfields](/type-definitions.html#signed-availability-bitfield) are attestations from a particular validator about which candidates it believes are available. ### Misbehavior Reports -Misbehavior reports contain proof that a validator or set of validators has misbehaved; they consist of a proof of some kind of misbehavior: double-voting, being the minority vote in a disputed block's vote, etc. These cause dots to be slashed and must be included in the block. +Misbehavior reports are self-contained proofs of misbehavior by a validator or group of validators. For example, it is very easy to verify a double-voting misbehavior report: the report contains two votes signed by the same key, advocating different outcomes. Concretely, misbehavior reports become inherents which cause dots to be slashed. -> TODO: This problem is mentioned elsewhere, but how do we force the block author to include a misbehavior report if they don't like its effects, i.e. they are among the nodes which get slashed? +Note that there is no mechanism in place which forces a block author to include a misbehavior report which it doesn't like, for example if it would be slashed by such a report. The chain's defense against this is to have a relatively long slash period, such that it's likely to encounter an honest author before the slash period expires. ### Dispute Inherent -> TODO: Is this different from a misbehavior report? How? +The dispute inherent is similar to a misbehavior report in that it is an attestation of misbehavior on the part of a validator or group of validators. Unlike a misbehavior report, it is not self-contained: resolution requires coordinated action by several validators. The canonical example of a dispute inherent involves a fisherman discovering that a set of validators has improperly approved an invalid parachain block: resolving this requires the entire validator set to re-validate the block, so that the minority can be slashed. + +> TODO: Is this statement accurate: "Resolution of a dispute produces a misbehavior report."? ## Protocol From eefa2e137537bb1953fd710eb534ded6d9a2a9c5 Mon Sep 17 00:00:00 2001 From: Peter Goodspeed-Niklaus Date: Mon, 15 Jun 2020 11:30:19 +0200 Subject: [PATCH 3/5] add misbehavior reports, disputes to provisioner messages --- roadmap/implementors-guide/src/type-definitions.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/roadmap/implementors-guide/src/type-definitions.md b/roadmap/implementors-guide/src/type-definitions.md index 7843fbddfef9..1d78453abefa 100644 --- a/roadmap/implementors-guide/src/type-definitions.md +++ b/roadmap/implementors-guide/src/type-definitions.md @@ -156,7 +156,7 @@ enum StatementDistributionMessage { ## Misbehavior Arbitration Message ```rust -enum MisbehaviorArbitrationMessage { +enum MisbehaviorReport { /// These validator nodes disagree on this candidate's validity, please figure it out /// /// Most likely, the list of statments all agree except for the final one. That's not @@ -188,6 +188,10 @@ enum ProvisionerMessage { /// This message allows potential block authors to be kept updated with all new authorship data /// as it becomes available. RequestBlockAuthorshipData(Hash, Sender), + /// Misbehavior reports are self-contained proofs of validator misbehavior. + MisbehaviorReport(MisbehaviorReport), + /// Disputes trigger a broad dispute resolution process. + Dispute(Hash, Signature), } ``` From 7a79e74852eafb1f9f7a6a124dd0ee105122f670 Mon Sep 17 00:00:00 2001 From: Peter Goodspeed-Niklaus Date: Mon, 15 Jun 2020 11:59:10 +0200 Subject: [PATCH 4/5] expand on the protocol --- .../src/node/utility/provisioner.md | 20 +++++++++++++---- .../src/type-definitions.md | 22 ++++++++++++------- 2 files changed, 30 insertions(+), 12 deletions(-) diff --git a/roadmap/implementors-guide/src/node/utility/provisioner.md b/roadmap/implementors-guide/src/node/utility/provisioner.md index 37a88148de0e..6c2ed95b0590 100644 --- a/roadmap/implementors-guide/src/node/utility/provisioner.md +++ b/roadmap/implementors-guide/src/node/utility/provisioner.md @@ -30,13 +30,25 @@ The dispute inherent is similar to a misbehavior report in that it is an attesta ## Protocol -Input: [`ProvisionerMessage`](/type-definitions.html#provisioner-message) +Input: [`ProvisionerMessage`](/type-definitions.html#provisioner-message). Backed candidates come from the [Candidate Backing subsystem](/node/backing/candidate-backing.html), signed bitfields come from the [Bitfield Distribution subsystem](/node/availability/bitfield-distribution.html), and misbehavior reports and disputes come from the [Misbehavior Arbitration subsystem](/node/utility/misbehavior-arbitration.html). + +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. + +Note that block authors must re-send a `ProvisionerMessage::RequestBlockAuthorshipData` for each relay parent they are interested in receiving provisionable data for. ## Functionality -Use `StartWork` and `StopWork` to manage a set of jobs for relay-parents we might be building upon. -Forward all messages to corresponding job. +The subsystem should maintain a set of handles to Block Authorship Provisioning Jobs that are currently live. + +### On Overseer Signal + +- `StartWork`: spawn a Block Authorship Provisioning Job with the given relay parent, storing a bidirectional channel with that job. +- `StopWork`: terminate the Block Authorship Provisioning Job for the given relay parent, if any. + +### On `ProvisionerMessage` + +Forward the message to the appropriate Block Authorship Provisioning Job, or discard if no appropriate job is currently active. ## Block Authorship Provisioning Job -Track all signed bitfields, all backable candidates received. Provide them to the `RequestBlockAuthorshipData` requester via the `response_channel`. +Maintain the set of channels to block authors. On receiving provisionable data, send a copy over each channel. diff --git a/roadmap/implementors-guide/src/type-definitions.md b/roadmap/implementors-guide/src/type-definitions.md index 1d78453abefa..e210ed111ac0 100644 --- a/roadmap/implementors-guide/src/type-definitions.md +++ b/roadmap/implementors-guide/src/type-definitions.md @@ -176,23 +176,29 @@ enum MisbehaviorReport { ## Provisioner Message ```rust -/// Message to the Provisioner. -/// -/// In all cases, the Hash is that of the relay parent. -enum ProvisionerMessage { +/// This data becomes intrinsics or extrinsics which should be included in a future relay chain block. +enum ProvisionableData { /// This bitfield indicates the availability of various candidate blocks. Bitfield(Hash, SignedAvailabilityBitfield), /// The Candidate Backing subsystem believes that this candidate is backable, pending availability. /// TODO: do we need any more data than this? BackableCandidate(Hash, CandidateReceipt), - /// This message allows potential block authors to be kept updated with all new authorship data - /// as it becomes available. - RequestBlockAuthorshipData(Hash, Sender), /// Misbehavior reports are self-contained proofs of validator misbehavior. - MisbehaviorReport(MisbehaviorReport), + MisbehaviorReport(Hash, MisbehaviorReport), /// Disputes trigger a broad dispute resolution process. Dispute(Hash, Signature), } + +/// Message to the Provisioner. +/// +/// 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), + /// This data should become part of a relay chain block + ProvisionableData(ProvisionableData), +} ``` ## Host Configuration From 682fc609523a1a6eea8868343344b23a48ce10d4 Mon Sep 17 00:00:00 2001 From: Peter Goodspeed-Niklaus Date: Mon, 15 Jun 2020 15:24:51 +0200 Subject: [PATCH 5/5] updates per code review --- roadmap/implementors-guide/src/node/utility/provisioner.md | 6 ++++-- roadmap/implementors-guide/src/type-definitions.md | 5 ++--- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/roadmap/implementors-guide/src/node/utility/provisioner.md b/roadmap/implementors-guide/src/node/utility/provisioner.md index 6c2ed95b0590..460ee9c33d34 100644 --- a/roadmap/implementors-guide/src/node/utility/provisioner.md +++ b/roadmap/implementors-guide/src/node/utility/provisioner.md @@ -24,9 +24,11 @@ Note that there is no mechanism in place which forces a block author to include ### Dispute Inherent -The dispute inherent is similar to a misbehavior report in that it is an attestation of misbehavior on the part of a validator or group of validators. Unlike a misbehavior report, it is not self-contained: resolution requires coordinated action by several validators. The canonical example of a dispute inherent involves a fisherman discovering that a set of validators has improperly approved an invalid parachain block: resolving this requires the entire validator set to re-validate the block, so that the minority can be slashed. +The dispute inherent is similar to a misbehavior report in that it is an attestation of misbehavior on the part of a validator or group of validators. Unlike a misbehavior report, it is not self-contained: resolution requires coordinated action by several validators. The canonical example of a dispute inherent involves an approval checker discovering that a set of validators has improperly approved an invalid parachain block: resolving this requires the entire validator set to re-validate the block, so that the minority can be slashed. -> TODO: Is this statement accurate: "Resolution of a dispute produces a misbehavior report."? +Dispute resolution is complex and is explained in substantially more detail [here](/runtime/validity.html). + +> TODO: The provisioner is responsible for selecting remote disputes to replay. Let's figure out the details. ## Protocol diff --git a/roadmap/implementors-guide/src/type-definitions.md b/roadmap/implementors-guide/src/type-definitions.md index e210ed111ac0..6ab70d123a32 100644 --- a/roadmap/implementors-guide/src/type-definitions.md +++ b/roadmap/implementors-guide/src/type-definitions.md @@ -180,9 +180,8 @@ enum MisbehaviorReport { enum ProvisionableData { /// This bitfield indicates the availability of various candidate blocks. Bitfield(Hash, SignedAvailabilityBitfield), - /// The Candidate Backing subsystem believes that this candidate is backable, pending availability. - /// TODO: do we need any more data than this? - BackableCandidate(Hash, CandidateReceipt), + /// The Candidate Backing subsystem believes that this candidate is valid, pending availability. + BackedCandidate(BackedCandidate), /// Misbehavior reports are self-contained proofs of validator misbehavior. MisbehaviorReport(Hash, MisbehaviorReport), /// Disputes trigger a broad dispute resolution process.