Implementers' Guide: Chain Selection (#3262)

* high-level discussion of fork-choice and chain selection * notes on chain-selection subsystem * send `Approve` messages from approval-voting * remove references to candidate-selection * adjust grandpa voting rule docs * Update roadmap/implementers-guide/src/node/grandpa-voting-rule.md Co-authored-by: Lldenaurois <ljdenaurois@gmail.com> * Update roadmap/implementers-guide/src/protocol-chain-selection.md Co-authored-by: Lldenaurois <ljdenaurois@gmail.com> * Update roadmap/implementers-guide/src/protocol-chain-selection.md Co-authored-by: Lldenaurois <ljdenaurois@gmail.com> Co-authored-by: Lldenaurois <ljdenaurois@gmail.com>
2026-06-11 21:11:07 +00:00 · 2021-06-17 16:10:23 +01:00
parent 4c6dc182b2
commit 9c7a346e4c
8 changed files with 116 additions and 33 deletions
@@ -180,6 +180,7 @@ On receiving an `OverseerSignal::ActiveLeavesUpdate(update)`:
    * If any of the runtime API calls fail, we just warn and skip the block.
  * We use the RuntimeApiSubsystem to determine the set of candidates included in these blocks and use BABE logic to determine the slot number and VRF of the blocks.
  * We also note how late we appear to have received the block. We create a `BlockEntry` for each block and a `CandidateEntry` for each candidate obtained from `CandidateIncluded` events after making a `RuntimeApiRequest::CandidateEvents` request.
+  * For each candidate, if the amount of needed approvals is more than the validators remaining after the backing group of the candidate is subtracted, then the candidate is insta-approved as approval would be impossible otherwise. If all candidates in the block are insta-approved, or there are no candidates in the block, then the block is insta-approved. If the block is insta-approved, a [`ChainSelectionMessage::Approvedl][CSM] should be sent for the block.
  * Ensure that the `CandidateEntry` contains a `block_assignments` entry for the block, with the correct backing group set.
  * If a validator in this session, compute and assign `our_assignment` for the `block_assignments`
    * Only if not a member of the backing group.
@@ -240,6 +241,7 @@ On receiving an `ApprovedAncestor(Hash, BlockNumber, response_channel)`:
  * Checks the `ApprovalEntry` for the block.
    * [determine the tranches to inspect](#determine-required-tranches) of the candidate,
    * [the candidate is approved under the block](#check-approval), set the corresponding bit in the `block_entry.approved_bitfield`.
+    * If the block is now fully approved and was not before, send a [`ChainSelectionMessage::Approved`][CSM].
    * Otherwise, [schedule a wakeup of the candidate](#schedule-wakeup)
  * If the approval vote originates locally, set the `our_approval_sig` in the candidate entry.

@@ -370,3 +372,5 @@ Likewise, when considering how many tranches to take, the no-show depth should b
 #### Current Tranche
  * Given the slot number of a block, and the current time, this informs about the current tranche.
  * Convert `time.saturating_sub(slot_number.to_time())` to a delay tranches value
+
+[CSM]: ../../types/overseer-protocol.md#chainselectionmessage
@@ -16,16 +16,16 @@ Output:

 - [`CandidateValidationMessage`][CVM]
 - [`RuntimeApiMessage`][RAM]
- [`CandidateSelectionMessage`][CSM]
+- [`CollatorProtocolMessage`][CPM]
 - [`ProvisionerMessage`][PM]
 - [`AvailabilityDistributionMessage`][ADM]
 - [`StatementDistributionMessage`][SDM]

 ## Functionality

-The [Candidate Selection][CS] subsystem is the primary source of non-overseer messages into this subsystem. That subsystem generates appropriate [`CandidateBackingMessage`s][CBM] and passes them to this subsystem.
+The [Collator Protocol][CP] subsystem is the primary source of non-overseer messages into this subsystem. That subsystem generates appropriate [`CandidateBackingMessage`s][CBM] and passes them to this subsystem.

-This subsystem requests validation from the [Candidate Validation][CV] and generates an appropriate [`Statement`][Statement]. All `Statement`s are then passed on to the [Statement Distribution][SD] subsystem to be gossiped to peers. When [Candidate Validation][CV] decides that a candidate is invalid, and it was recommended to us to second by our own [Candidate Selection][CS] subsystem, a message is sent to the [Candidate Selection][CS] subsystem with the candidate's hash so that the collator which recommended it can be penalized.
+This subsystem requests validation from the [Candidate Validation][CV] and generates an appropriate [`Statement`][Statement]. All `Statement`s are then passed on to the [Statement Distribution][SD] subsystem to be gossiped to peers. When [Candidate Validation][CV] decides that a candidate is invalid, and it was recommended to us to second by our own [Collator Protocol][CP] subsystem, a message is sent to the [Collator Protocol][CP] subsystem with the candidate's hash so that the collator which recommended it can be penalized.

 The subsystem should maintain a set of handles to Candidate Backing Jobs that are currently live, as well as the relay-parent to which they correspond.

@@ -117,7 +117,7 @@ fn spawn_validation_work(candidate, parachain head, validation function) {
 ### Fetch Pov Block

 Create a `(sender, receiver)` pair.
-Dispatch a [`AvailabilityDistributionMessage`][PDM]`::FetchPoV{ validator_index, pov_hash, candidate_hash, tx, } and listen on the passed receiver for a response. Availability distribution will send the request to the validator specified by `validator_index`, which might not be serving it for whatever reasons, therefore we need to retry with other backing validators in that case.
+Dispatch a [`AvailabilityDistributionMessage`][ADM]`::FetchPoV{ validator_index, pov_hash, candidate_hash, tx, } and listen on the passed receiver for a response. Availability distribution will send the request to the validator specified by `validator_index`, which might not be serving it for whatever reasons, therefore we need to retry with other backing validators in that case.


 ### Validate PoV Block
@@ -127,12 +127,12 @@ Dispatch a `CandidateValidationMessage::Validate(validation function, candidate,

 ### Distribute Signed Statement

-Dispatch a [`StatementDistributionMessage`][PDM]`::Share(relay_parent, SignedFullStatement)`.
+Dispatch a [`StatementDistributionMessage`][SDM]`::Share(relay_parent, SignedFullStatement)`.

 [OverseerSignal]: ../../types/overseer-protocol.md#overseer-signal
 [Statement]: ../../types/backing.md#statement-type
 [STMT]: ../../types/backing.md#statement-type
-[CSM]: ../../types/overseer-protocol.md#candidate-selection-message
+[CPM]: ../../types/overseer-protocol.md#collator-protocol-message
 [RAM]: ../../types/overseer-protocol.md#runtime-api-message
 [CVM]: ../../types/overseer-protocol.md#validation-request-type
 [PM]: ../../types/overseer-protocol.md#provisioner-message
@@ -141,7 +141,7 @@ Dispatch a [`StatementDistributionMessage`][PDM]`::Share(relay_parent, SignedFul
 [SDM]: ../../types/overseer-protocol.md#statement-distribution-message
 [DCM]: ../../types/overseer-protocol.md#dispute-coordinator-message

-[CS]: candidate-selection.md
+[CP]: ../collators/collator-protocol.md
 [CV]: ../utility/candidate-validation.md
 [SD]: statement-distribution.md
 [RA]: ../utility/runtime-api.md
@@ -1,11 +1,10 @@
 # GRANDPA Voting Rule

-[GRANDPA](https://w3f-research.readthedocs.io/en/latest/polkadot/finality.html) is the finality engine of Polkadot.
-
-One broad goal of finality, which applies across many different blockchains, is that there should exist only one finalized block at each height in the finalized chain. Before a block at a given height is finalized, it may compete with other forks.
+Specifics on the motivation and types of constraints we apply to the GRANDPA voting logic as well as the definitions of **viable** and **finalizable** blocks can be found in the [Chain Selection Protocol](../protocol-chain-selection.md) section.
+The subsystem which provides us with viable leaves is the [Chain Selection Subsystem](utility/chain-selection.md). 

 GRANDPA's regular voting rule is for each validator to select the longest chain they are aware of. GRANDPA proceeds in rounds, collecting information from all online validators and determines the blocks that a supermajority of validators all have in common with each other.

-For parachains, we extend the security guarantee of finality to be such that no invalid parachain candidate may be included in a finalized block. Candidates may be included in some fork of the relay chain with only a few backing votes behind them. After that point, we run the [Approvals Protocol](../protocol-approval.md), which is implemented as the [Approval Voting](approval/approval-voting.md) subsystem. This system involves validators self-selecting to re-check candidates included in all observed forks of the relay chain as well as an algorithm for observing validators' statements about assignment and approval in order to determine which candidates, and thus blocks, are with high probability valid. The highest approved ancestor of a given block can be determined by querying the Approval Voting subsystem via the [`ApprovalVotingMessage::ApprovedAncestor`](../types/overseer-protocol.md#approval-voting) message. If the response of `ApprovedAncestor` is `Some`, we further constrain the voting rule to avoid unfinalized blocks. The list of block hashes and candidates should be reversed, and passed to the [`DisputeCoordinatorMessage::DetermineUndisputedChain`](../types/overseer-protocol.md#dispute-coordinator-message) for a final result.
+The low-level GRANDPA logic will provide us with a **required block**. We can find the best leaf containing that block in its chain with the [`ChainSelectionMessage::BestLeafContaining`](../types/overseer-protocol.md#chain-selection-message). If the result is `None`, then we will simply cast a vote on the required block.

-Lastly, we refuse to finalize any block including a candidate for which we are aware of an ongoing dispute or of a dispute resolving against the candidate. The exact means of doing this has not been determined yet.
+The **viable** leaves provided from the chain selection subsystem are not necessarily **finalizable**, so we need to perform further work to discover the finalizable ancestor of the block. The first constraint is to avoid voting on any unapproved block. The highest approved ancestor of a given block can be determined by querying the Approval Voting subsystem via the [`ApprovalVotingMessage::ApprovedAncestor`](../types/overseer-protocol.md#approval-voting) message. If the response is `Some`, we continue and apply the second constraint. The second constraint is to avoid voting on any block containing a candidate undergoing an active dispute. The list of block hashes and candidates returned from `ApprovedAncestor` should be reversed, and passed to the [`DisputeCoordinatorMessage::DetermineUndisputedChain`](../types/overseer-protocol.md#dispute-coordinator-message) to determine the **finalizable** block which will be our eventual vote.
@@ -0,0 +1,34 @@
+# Chain Selection Subsystem
+
+This subsystem implements the necessary metadata for the implementation of the [chain selection](../../protocol-chain-selection.md) portion of the protocol.
+
+The subsystem wraps a database component which maintains a view of the unfinalized chain and records the properties of each block: whether the block is **viable**, whether it is **stagnant**, and whether it is **reverted**. It should also maintain an updated set of active leaves in accordance with this view, which should be cheap to query.
+
+This subsystem needs to update its information on the unfinalized chain:
+  * On every leaf-activated signal
+  * On every block-finalized signal
+  * On every `ChainSelectionMessage::Approve`
+  * Periodically, to detect stagnation.
+
+Simple implementations of these updates do O(n_unfinalized_blocks) disk operations. If the amount of unfinalized blocks is relatively small, the updates should not take very much time. However, in cases where there are hundreds or thousands of unfinalized blocks the naive implementations of these update algorithms would have to be replaced with more sophisticated versions.
+
+### `OverseerSignal::ActiveLeavesUpdate`
+
+Determine all new blocks implicitly referenced by any new active leaves and add them to the view. Update the set of viable leaves accordingly
+
+### `OverseerSignal::BlockFinalized`
+
+Delete data for all orphaned chains and update all metadata descending from the new finalized block accordingly, along with the set of viable leaves. Note that finalizing a **reverted** or **stagnant** block means that the descendants of those blocks may lose that status because the definitions of those properties don't include the finalized chain. Update the set of viable leaves accordingly.
+
+### `ChainSelectionMessage::Approved`
+
+Update the approval status of the referenced block. If the block was stagnant and thus non-viable and is now viable, then the metadata of all of its descendants needs to be updated as well, as they may no longer be stagnant either. Update the set of viable leaves accordingly.
+
+### `ChainSelectionMessage::BestLeafContaining`
+
+If the required block is unknown or not viable, then return `None`.
+Iterate over all leaves, returning the first leaf containing the required block in its chain, and `None` otherwise.
+
+### Periodically
+
+Detect stagnant blocks and apply the stagnant definition to all descendants. Update the set of viable leaves accordingly.