mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-06-13 22:11:06 +00:00
PVF: Instantiate wasm in pre-checking (#7246)
* PVF: Instantiate wasm in pre-checking * Move `runtime_construction_check` to prepare thread, use bytes * [minor] Update comment * Fix compile error * Update Cargo.lock * Update docs * Add some missing docs!
This commit is contained in:
@@ -29,8 +29,8 @@ exactly one downward message queue.
|
||||
- **Preimage:** In our context, if `H(X) = Y` where `H` is a hash function and `Y` is the hash, then `X` is the hash preimage.
|
||||
- **Proof-of-Validity (PoV):** A stateless-client proof that a parachain candidate is valid, with respect to some validation function.
|
||||
- **PVF:** Parachain Validation Function. The validation code that is run by validators on parachains or parathreads.
|
||||
- **PVF 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.
|
||||
- **PVF 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.
|
||||
- **PVF 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, plus some additional checks.
|
||||
- **PVF Preparation:** This is the process of preparing the WASM blob and includes both prevalidation and compilation. As there is no prevalidation right now, preparation just consists of compilation.
|
||||
- **Relay Parent:** A block in the relay chain, referred to in a context where work is being done in the context of the state at this block.
|
||||
- **Runtime:** The relay-chain state machine.
|
||||
- **Runtime Module:** See Module.
|
||||
|
||||
@@ -21,7 +21,17 @@ As a result of this issue we need a fairly hard guarantee that the PVFs of regis
|
||||
|
||||
## Solution
|
||||
|
||||
The problem is solved by having a pre-checking process which is run when a new validation code is included in the chain. A new PVF can be added in two cases:
|
||||
The problem is solved by having a pre-checking process.
|
||||
|
||||
### Pre-checking
|
||||
|
||||
Pre-checking mostly consists of attempting to prepare (compile) the PVF WASM blob. We use more strict limits (e.g. timeouts) here compared to regular preparation for execution. This way errors during preparation later are likely unrelated to the PVF itself, as it already passed pre-checking. We can treat such errors as local node issues.
|
||||
|
||||
We also have an additional step where we attempt to instantiate the WASM runtime without running it. This is unrelated to preparation so we don't time it, but it does help us catch more issues.
|
||||
|
||||
### Protocol
|
||||
|
||||
Pre-checking is run when a new validation code is included in the chain. A new PVF can be added in two cases:
|
||||
|
||||
- A new parachain or parathread is registered.
|
||||
- An existing parachain or parathread signalled an upgrade of its validation code.
|
||||
@@ -44,6 +54,8 @@ In case PVF pre-checking process was concluded with rejection, then all the oper
|
||||
|
||||
The logic described above is implemented by the [paras] module.
|
||||
|
||||
### Subsystem
|
||||
|
||||
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].
|
||||
|
||||
## Summary
|
||||
@@ -52,7 +64,7 @@ Parachains' and parathreads' validation function is described by a wasm module t
|
||||
|
||||
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.
|
||||
As part of the registration process, it has to go through pre-checking. Pre-checking is a game of attempting preparation and additional checks, 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 (referred to as an artifact).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user