pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-04-30 16:37:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

pvf-precheck: update implementers' guide (#4612)

Browse Source 
This commit incorporates the changes made to the runtime in the
following PRs:

- https://github.com/paritytech/polkadot/pull/4408
- https://github.com/paritytech/polkadot/pull/4457
- https://github.com/paritytech/polkadot/pull/4540
- https://github.com/paritytech/polkadot/pull/4542
- https://github.com/paritytech/polkadot/pull/4581

Note that this PR does not include the description of the PVF
pre-checker subsystem. This should be addressed within
https://github.com/paritytech/polkadot/issues/4611

Co-authored-by: sandreim <54316454+sandreim@users.noreply.github.com>
This commit is contained in:
Sergei Shulepov
2021-12-29 14:32:08 +01:00
committed by GitHub
parent cf509bdb51
commit 1394b70d49
10 changed files with 257 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/roadmap/implementers-guide/src/node/utility/candidate-validation.md
+6 -2
View File
@@ -12,15 +12,19 @@ Output: Validation result via the provided response side-channel.
## Functionality
This subsystem answers two types of requests: one which draws out validation data from the state, and another which accepts all validation data exhaustively. The goal of both request types is to validate a candidate. There are three possible outputs of validation: either the candidate is valid, the candidate is invalid, or an internal error occurred. Whatever the end result is, it will be returned on the response channel to the requestor.
This subsystem groups the requests it handles in two categories: *candidate validation* and *PVF pre-checking*.
Parachain candidates are validated against their validation function: A piece of Wasm code that is describes the state-transition of the parachain. Validation function execution is not metered. This means that an execution which is an infinite loop or simply takes too long must be forcibly exited by some other means. For this reason, we recommend dispatching candidate validation to be done on subprocesses which can be killed if they time-out.
The first category can be further subdivided in two request types: one which draws out validation data from the state, and another which accepts all validation data exhaustively. Validation returns three possible outcomes on the response channel: the candidate is valid, the candidate is invalid, or an internal error occurred.
Parachain candidates are validated against their validation function: A piece of Wasm code that describes the state-transition of the parachain. Validation function execution is not metered. This means that an execution which is an infinite loop or simply takes too long must be forcibly exited by some other means. For this reason, we recommend dispatching candidate validation to be done on subprocesses which can be killed if they time-out.
Upon receiving a validation request, the first thing the candidate validation subsystem should do is make sure it has all the necessary parameters to the validation function. These are:
* The Validation Function itself.
* The [`CandidateDescriptor`](../../types/candidate.md#candidatedescriptor).
* The [`ValidationData`](../../types/candidate.md#validationdata).
* The [`PoV`](../../types/availability.md#proofofvalidity).
The second category is for PVF pre-checking. This is primarly used by the [PVF pre-checker](pvf-prechecker.md) subsystem.
### Determining Parameters
polkadot/roadmap/implementers-guide/src/node/utility/pvf-prechecker.md
+17
View File
@@ -0,0 +1,17 @@
# PVF Pre-checker
The PVF pre-checker is a subsystem that is responsible for watching the relay chain for new PVFs that require pre-checking. Head over to [overview] for the PVF pre-checking process overview.
## Protocol
There is no dedicated input mechanism for PVF pre-checker. Instead, PVF pre-checker looks on the `ActiveLeavesUpdate` event stream for work.
This subsytem does not produce any output messages either. The subsystem will, however, send messages to the [Runtime API] subsystem to query for the pending PVFs and to submit votes. In addition to that, it will also communicate with [Candidate Validation] Subsystem to request PVF pre-check.
## Functionality
TODO: Write up the description of the functionality of the PVF pre-checker. https://github.com/paritytech/polkadot/issues/4611
[overview]: ../../pvf-prechecking.md
[Runtime API]: runtime-api.md
[Candidate Validation]: candidate-validation.md