pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-06-17 21:51:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

PVF timeouts follow-up (#6151)

Browse Source 
* Rename timeout consts and timeout parameter; bump leniency

* Update implementor's guide with info about PVFs

* Make glossary a bit easier to read

* Add a note to LENIENT_PREPARATION_TIMEOUT

* Remove PVF-specific section from glossary

* Fix some typos
This commit is contained in:
Marcin S
2022-11-01 10:59:53 -04:00
committed by GitHub
parent 351d37e324
commit 1f8219767e
10 changed files with 118 additions and 116 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/roadmap/implementers-guide/src/pvf-prechecking.md
+17 -25
View File
@@ -1,32 +1,12 @@
# PVF Pre-checking Overview
> ⚠️ This discusses a mechanism that is currently under-development. Follow the progress under [#3211].
## Terms
This functionality involves several processes which may be potentially
confusing:
- **Prechecking:** This is the process of initially checking the PVF when it is
first added. We attempt *preparation* of the PVF and make sure it succeeds
within a given timeout.
- **Execution:** This actually executes the PVF. The node may not have the
artifact from prechecking, in which case this process also includes a
*preparation* job. The timeout for preparation here is more lenient than when
prechecking.
- **Preparation:** This is the process of preparing the WASM blob and includes
both *prevalidation* and *compilation*. As prevalidation is pretty minimal
right now, preparation mostly consists of compilation. Note that *prechecking*
just consists of preparation, whereas *execution* will also prepare the PVF if
the artifact is not already found.
- **Prevalidation:** Right now this just tries to deserialize the binary with
parity-wasm. It is a part of *preparation*.
- **Compilation:** This is the process of compiling a PVF from wasm code to
machine code. It is a part of *preparation*.
> ⚠️ This discusses a mechanism that is currently under-development. Follow the progress under [#3211][3211].
## Motivation
Parachains' and parathreads' validation function is described by a wasm module that we refer to as a PVF. Since it's a wasm module the typical way of executing it is to compile it to machine code. Typically an optimizing compiler consists of algorithms that are able to optimize the resulting machine code heavily. However, while those algorithms perform quite well for a typical wasm code produced by standard toolchains (e.g. rustc/LLVM), those algorithms can be abused to consume a lot of resources. Moreover, since those algorithms are rather complex there is a lot of room for a bug that can crash the compiler.
Parachains' and parathreads' validation function is described by a wasm module that we refer to as a PVF. Since a PVF is a wasm module the typical way of executing it is to compile it to machine code.
Typically an optimizing compiler consists of algorithms that are able to optimize the resulting machine code heavily. However, while those algorithms perform quite well for a typical wasm code produced by standard toolchains (e.g. rustc/LLVM), those algorithms can be abused to consume a lot of resources. Moreover, since those algorithms are rather complex there is a lot of room for a bug that can crash the compiler.
If compilation of a Parachain Validation Function (PVF) takes too long or uses too much memory, this can leave a node in limbo as to whether a candidate of that parachain is valid or not.
@@ -66,7 +46,19 @@ The logic described above is implemented by the [paras] module.
On the node-side, there is a PVF pre-checking [subsystem][pvf-prechecker-subsystem] that scans the chain for new PVFs via using [runtime APIs][pvf-runtime-api]. Upon finding a new PVF, the subsystem will initiate a PVF pre-checking request and wait for the result. Whenever the result is obtained, the subsystem will use the [runtime API][pvf-runtime-api] to submit a vote for the PVF. The vote is an unsigned transaction. The vote will be distributed via the gossip similarly to a normal transaction. Eventually a block producer will include the vote into the block where it will be handled by the [runtime][paras].
[#3211]: https://github.com/paritytech/polkadot/issues/3211
## Pre-checking Summary
Parachains' and parathreads' validation function is described by a wasm module that we refer to as a PVF.
In order to make the PVF usable for candidate validation it has to be registered on-chain.
As part of the registration process, it has to go through pre-checking. Pre-checking is a game of attempting preparation and reporting the results back on-chain.
We define preparation as a process that: validates the consistency of the wasm binary (aka prevalidation) and the compilation of the wasm module into machine code (refered to as artifact).
Besides pre-checking, preparation can also be triggered by execution, since a compiled artifact is needed for the execution. If an artifact already exists, execution will skip preparation. If it does do preparation, execution uses a more lenient timeout than preparation, to avoid the situation where honest validators fail on valid, pre-checked PVFs.
[3211]: https://github.com/paritytech/polkadot/issues/3211
[paras]: runtime/paras.md
[pvf-runtime-api]: runtime-api/pvf-prechecking.md
[pvf-prechecker-subsystem]: node/utility/pvf-prechecker.md