pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-07-15 13:45:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add PVF module documentation (#6293)

Browse Source 
* Add PVF module documentation

TODO (once the PRs land):

- [ ] Document executor parametrization.

- [ ] Document CPU time measurement of timeouts.

* Update node/core/pvf/src/lib.rs

Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com>

* Clarify meaning of PVF acronym

* Move PVF doc to implementer's guide

* Clean up implementer's guide a bit

* Add page for PVF types

* pvf: Better separation between crate docs and implementer's guide

* ci: Add "prevalidating" to the dictionary

* ig: Remove types/chain.md

The types contained therein did not exist and the file was not referenced
anywhere.

Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com>
This commit is contained in:
Marcin S
2022-11-23 08:20:25 -05:00
committed by GitHub
parent 17ad9f5694
commit 1dec2433ae
13 changed files with 91 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/roadmap/implementers-guide/src/node/utility/candidate-validation.md
+35
View File
@@ -48,4 +48,39 @@ Once we have all parameters, we can spin up a background task to perform the val
If we can assume the presence of the relay-chain state (that is, during processing [`CandidateValidationMessage`][CVM]`::ValidateFromChainState`) we can run all the checks that the relay-chain would run at the inclusion time thus confirming that the candidate will be accepted.
### PVF Host
The PVF host is responsible for handling requests to prepare and execute PVF
code blobs.
One high-level goal is to make PVF operations as deterministic as possible, to
reduce the rate of disputes. Disputes can happen due to e.g. a job timing out on
one machine, but not another. While we do not yet have full determinism, there
are some dispute reduction mechanisms in place right now.
#### Retrying execution requests
If the execution request fails during **preparation**, we will retry if it is
possible that the preparation error was transient (e.g. if the error was a panic
or time out). We will only retry preparation if another request comes in after
15 minutes, to ensure any potential transient conditions had time to be
resolved. We will retry up to 5 times.
If the actual **execution** of the artifact fails, we will retry once if it was
an ambiguous error after a 1 second delay, to allow any potential transient
conditions to clear.
#### Preparation timeouts
We use timeouts for both preparation and execution jobs to limit the amount of
time they can take. As the time for a job can vary depending on the machine and
load on the machine, this can potentially lead to disputes where some validators
successfuly execute a PVF and others don't.
One mitigation we have in place is a more lenient timeout for preparation during
execution than during pre-checking. The rationale is that the PVF has already
passed pre-checking, so we know it should be valid, and we allow it to take
longer than expected, as this is likely due to an issue with the machine and not
the PVF.
[CVM]: ../../types/overseer-protocol.md#validationrequesttype