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

implement collation generation subsystem (#1557)

Browse Source 
* start sketching out a collation generation subsystem

* invent a basic strategy for double initialization

* clean up warnings

* impl util requests from runtime assuming a context instead of a FromJob sender

* implement collation generation algorithm from guide

* update AllMessages in tests

* fix trivial review comments

* remove another redundant declaration from merge

* filter availability cores by para_id

* handle new activations each in their own async task

* update guide according to the actual current implementation

* add initialization to guide

* add general-purpose subsystem_test_harness helper

* write first handle_new_activations test

* add test that handle_new_activations filters local_validation_data requests

* add (failing) test of collation distribution message sending

* rustfmt

* broken: work on fixing sender test

Unfortunately, for reasons that are not yet clear, despite the public key
and checked data being identical, the signer is not producing an identical
signature. This commit produces this output (among more):

signing with  Public(c4733ab0bbe3ba4c096685d1737a7f498cdbdd167a767d04a21dc7df12b8c858 (5GWHUNm5...))
checking with Public(c4733ab0bbe3ba4c096685d1737a7f498cdbdd167a767d04a21dc7df12b8c858 (5GWHUNm5...))
signed payload:  [4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 10, 0, 0, 0, c7, e5, c0, 64, 7a, db, fe, 44, 81, e5, 51, 11, 79, 9f, a5, 63, 93, 94, 3c, c4, 36, c6, 30, 36, c2, c5, 44, a2, 1b, db, b7, 82, 3, 17, a, 2e, 75, 97, b7, b7, e3, d8, 4c, 5, 39, 1d, 13, 9a, 62, b1, 57, e7, 87, 86, d8, c0, 82, f2, 9d, cf, 4c, 11, 13, 14]
checked payload: [4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 10, 0, 0, 0, c7, e5, c0, 64, 7a, db, fe, 44, 81, e5, 51, 11, 79, 9f, a5, 63, 93, 94, 3c, c4, 36, c6, 30, 36, c2, c5, 44, a2, 1b, db, b7, 82, 3, 17, a, 2e, 75, 97, b7, b7, e3, d8, 4c, 5, 39, 1d, 13, 9a, 62, b1, 57, e7, 87, 86, d8, c0, 82, f2, 9d, cf, 4c, 11, 13, 14]

* fix broken test

* collation function returns commitments hash

It doesn't look like we use the actual commitments data anywhere, and
it's not obvious if there are any fields of `CandidateCommitments`
not available to the collator, so this commit just assigns them the
entire responsibility of generating the hash.

* add missing overseer impls

* calculating erasure coding is polkadot's responsibility, not cumulus

* concurrentize per-relay_parent requests
This commit is contained in:
Peter Goodspeed-Niklaus
2020-08-17 14:27:37 +02:00
committed by GitHub
parent ab1a513265
commit 54bec3bfc0
13 changed files with 1031 additions and 108 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/roadmap/implementers-guide/src/node/collators/collation-generation.md
+28 -13
View File
@@ -4,33 +4,48 @@ The collation generation subsystem is executed on collator nodes and produces ca
## Protocol
Input: None
Input: `CollationGenerationMessage`
Output: CollationDistributionMessage
```rust
enum CollationGenerationMessage {
Initialize(CollationGenerationConfig),
}
```
No more than one initialization message should ever be sent to the collation generation subsystem.
Output: `CollationDistributionMessage`
## Functionality
The process of generating a collation for a parachain is very parachain-specific. As such, the details of how to do so are left beyond the scope of this description. The subsystem should be implemented as an abstract wrapper, which is aware of this configuration:
```rust
pub struct Collation {
/// Hash of `CandidateCommitments` as understood by the collator.
pub commitments_hash: Hash,
pub proof_of_validity: PoV,
}
struct CollationGenerationConfig {
key: CollatorPair,
collation_producer: Fn(params) -> async (HeadData, Vec<UpwardMessage>, PoV),
key: CollatorPair,
collator: Box<dyn Fn(&GlobalValidationData, &LocalValidationData) -> Box<dyn Future<Output = Collation>>>
para_id: ParaId,
}
```
The configuration should be optional, to allow for the case where the node is not run with the capability to collate.
On `ActiveLeavesUpdate`:
* If there is no collation generation config, ignore.
* Otherwise, for each `activated` head in the update:
* Determine if the para is scheduled or is next up on any occupied core by fetching the `availability_cores` Runtime API.
* Determine an occupied core assumption to make about the para. The simplest thing to do is to always assume that if the para occupies a core, that the candidate will become available. Further on, this might be determined based on bitfields seen or validator requests.
* Use the Runtime API subsystem to fetch the full validation data.
* Construct validation function params based on validation data.
* Invoke the `collation_producer`.
* Construct a `CommittedCandidateReceipt` using the outputs of the `collation_producer` and signing with the `key`.
* Dispatch a [`CollatorProtocolMessage`][CPM]`::DistributeCollation(receipt, pov)`.
* If there is no collation generation config, ignore.
* Otherwise, for each `activated` head in the update:
* Determine if the para is scheduled on any core by fetching the `availability_cores` Runtime API.
> TODO: figure out what to do in the case of occupied cores; see [this issue](https://github.com/paritytech/polkadot/issues/1573).
* Determine an occupied core assumption to make about the para. Scheduled cores can make `OccupiedCoreAssumption::Free`.
* Use the Runtime API subsystem to fetch the full validation data.
* Invoke the `collator`, and use its outputs to produce a `CandidateReceipt`, signed with the configuration's `key`.
* Dispatch a [`CollatorProtocolMessage`][CPM]`::DistributeCollation(receipt, pov)`.
[CP]: collator-protocol.md
[CPM]: ../../types/overseer-protocol.md#collatorprotocolmessage