guide: validation data refactoring (#1576)

* guide: validation data refactoring

* address grumbles from review

* Update roadmap/implementers-guide/src/types/candidate.md

Co-authored-by: Bernhard Schuster <bernhard@ahoi.io>

* last comments from review

Co-authored-by: Sergei Shulepov <sergei@parity.io>
Co-authored-by: Bernhard Schuster <bernhard@ahoi.io>
This commit is contained in:
Robert Habermeier
2020-08-13 16:22:13 +02:00
committed by GitHub
parent 57aef8eef5
commit 2a96c19370
15 changed files with 106 additions and 114 deletions
@@ -26,7 +26,7 @@ On `ActiveLeavesUpdate`:
* 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 global validation data and local validation data.
* 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`.