-
Notifications
You must be signed in to change notification settings - Fork 1.6k
impl guide: Update Collator Generation #7250
impl guide: Update Collator Generation #7250
Conversation
|
||
## With Async Backing | ||
|
||
### Protocol |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was it discussed somewhere? As long as we don't have a plan for collation generation, we shouldn't put it into the guide. We're still in the middle of cumulus changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops sorry, thought I removed this section.
node/collation-generation/src/lib.rs
Outdated
//! * Determine an occupied core assumption to make about the para. Scheduled cores can make [`OccupiedCoreAssumption::Free`]. | ||
//! * TODO: What does this mean? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's worth mentioning assumptions mechanism here. In short, collation generation only builds new candidates when the parachain core is free, meaning, previous candidate accepted by the runtime reached availability threshold. See pending availability in the inclusion pallet for reference.
This will change with asynchronous backing.
To understand the assumption mechanism: it is also used by candidate validation. When validation data is supplied with candidate, we try to match it with Runtime. The main "matching" point here is parachain head. With free or timed-out assumption the runtime will ignore pending-availability candidate and read latest para head.
With included-assumption it will apply pendind-availability candidate (if any) to the storage and return new para head. This is ok because storage changes done during api calls are discarded.
I don't remember why I did this. Maybe it only made sense with the async backing changes.
- *Slot:* Time is divided into discrete slots. Each validator in the validator | ||
set produces a verifiable random value, using a VRF, per slot. If below a | ||
threshold, this allows the validator to author a new block for that slot. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
leftover
bot merge |
* master: XCM: Tools for uniquely referencing messages (#7234) Companion: Substrate#13869 (#7119) Companion for Substrate#14214 (#7283) Fix flaky test and error reporting (#7282) impl guide: Update Collator Generation (#7250) Add staking-miner bin (#7273) metrics: tests: Fix flaky runtime_can_publish_metrics (#7279)
…slashing-client * ao-past-session-slashing-runtime: XCM: Tools for uniquely referencing messages (#7234) Companion: Substrate#13869 (#7119) Companion for Substrate#14214 (#7283) Fix flaky test and error reporting (#7282) impl guide: Update Collator Generation (#7250) Add staking-miner bin (#7273) metrics: tests: Fix flaky runtime_can_publish_metrics (#7279) [companion] Fix request-response protocols backpressure mechanism (#7276) PVF: instantiate runtime from bytes (#7270)
Re-raising changes I made in #6938, with async-backing content removed.
I think I added the "Summary in plain English" section because we are trying to move away from code in the impl guide, but let me know if it's not necessary.