Collation protocol: stricter validators (#2810)

* guide: declare one para as a collator

* add ParaId to Declare messages and clean up

* fix build

* fix the testerinos

* begin adding keystore to collator-protocol

* remove request_x_ctx

* add core_for_group

* add bump_rotation

* add some more helpers to subsystem-util

* change signing_key API to take ref

* determine current and next para assignments

* disconnect collators who are not on current or next para

* add collator peer count metric

* notes for later

* some fixes

* add data & keystore to test state

* add a test utility for answering runtime API requests

* fix existing collator tests

* add new tests

* remove sc_keystore

* update cargo lock

Co-authored-by: Andronik Ordian <write@reusable.software>
This commit is contained in:
Robert Habermeier
2021-04-03 21:48:58 +02:00
committed by GitHub
parent 94b0ccc8f1
commit 11b8e4c821
22 changed files with 1064 additions and 334 deletions
@@ -55,8 +55,6 @@ As with most other subsystems, we track the active leaves set by following `Acti
For the purposes of actually distributing a collation, we need to be connected to the validators who are interested in collations on that `ParaId` at this point in time. We assume that there is a discovery API for connecting to a set of validators.
> TODO: design & expose the discovery API not just for connecting to such peers but also to determine which of our current peers are validators.
As seen in the [Scheduler Module][SCH] of the runtime, validator groups are fixed for an entire session and their rotations across cores are predictable. Collators will want to do these things when attempting to distribute collations at a given relay-parent:
* Determine which core the para collated-on is assigned to.
* Determine the group on that core and the next group on that core.
@@ -100,7 +98,7 @@ digraph G {
}
```
When peers connect to us, they can `Declare` that they represent a collator with given public key. Once they've declared that, and we checked their signature, they can begin to send advertisements of collations. The peers should not send us any advertisements for collations that are on a relay-parent outside of our view.
When peers connect to us, they can `Declare` that they represent a collator with given public key and intend to collate on a specific para ID. Once they've declared that, and we checked their signature, they can begin to send advertisements of collations. The peers should not send us any advertisements for collations that are on a relay-parent outside of our view or for a para outside of the one they've declared.
The protocol tracks advertisements received and the source of the advertisement. The advertisement source is the `PeerId` of the peer who sent the message. We accept one advertisement per collator per source per relay-parent.
@@ -102,16 +102,12 @@ enum StatementDistributionV1Message {
```rust
enum CollatorProtocolV1Message {
/// Declare the intent to advertise collations under a collator ID, attaching a
/// Declare the intent to advertise collations under a collator ID and `Para`, attaching a
/// signature of the `PeerId` of the node using the given collator ID key.
Declare(CollatorId, CollatorSignature),
Declare(CollatorId, ParaId, CollatorSignature),
/// Advertise a collation to a validator. Can only be sent once the peer has
/// declared that they are a collator with given ID.
AdvertiseCollation(Hash, ParaId),
/// Request the advertised collation at that relay-parent.
RequestCollation(RequestId, Hash, ParaId),
/// A requested collation.
Collation(RequestId, CandidateReceipt, CompressedPoV),
AdvertiseCollation(Hash),
/// A collation sent to a validator was seconded.
CollationSeconded(SignedFullStatement),
}