* test new version of zombienet
* use default chain spec command
* use commit ref to get test files
* change test spec for zombienet new versionzombienet_tests/parachains/0001-parachains-smoke-test.toml
* changes for new version of zombienet
* use paritytech zombienet version
* pvf-precheck: Integrate PVF pre-checking into paras module
Closes#4009
This is the most of the runtime-side change needed for #3211.
Here is how it works.
The PVF pre-checking can be triggered either by an upgrade or by
onboarding (i.e. calling `schedule_para_initialize`). The PVF
pre-checking process is identified by the PVF code hash that is being
voted on. If there is already PVF pre-checking process running, then no
new PVF pre-checking process will be started. Instead, we just subscribe
to the existing one.
If there is no PVF pre-checking process running but the PVF code hash
was already saved in the storage, that necessarily means (I invite the
reviewers to double-check this invariant) that the PVF already passed
pre-checking. This is equivalent to instant approving of the PVF.
The pre-checking process can be concluded either by obtaining a
supermajority or if it expires.
Each validator checks the list of PVFs available for voting. The vote is
binary, i.e. accept or reject a given PVF. As soon as the supermajority
of votes are collected for one of the sides of the vote, the voting is
concluded in that direction and the effects of the voting are enacted.
Only validators from the active set can participate in the vote. The set
of active validators can change each session. That's why we reset the
votes each session. A voting that observed a certain number of sessions
will be rejected.
The effects of the PVF accepting depend on the operations requested it:
1. All onboardings subscribed to the approved PVF pre-checking process will
get scheduled and after passing 2 session boundaries they will be onboarded.
2. All upgrades subscribed to the approved PVF pre-checking process will
get scheduled very similarly to the existing process. Upgrades with
pre-checking are really the same process that is just delayed by the
time required for pre-checking voting. In case of instant approval the
mechanism is exactly the same. This is important from parachains
compatibility standpoint since following the delayed upgrade requires
the parachain to implement
https://github.com/paritytech/cumulus/pull/517.
In case, PVF pre-checking process was concluded with rejection, then all
the requesting operations get cancelled. For onboarding it means it gets
without movement: the lifecycle of such parachain is terminated on the
`Onboarding` state and after rejection the lifecycle is none. That in
turn means that the caller can attempt registering the parachain once
more. For upgrading it means that the upgrade process is aborted: that
flashes go-ahead signal with `Abort` flag.
Rejection leads to removing the allegedly bad validation code from the
chain storage. Among other things, this implies that the operation can
be re-requested. That allows for retrying an operation in case there was
some bug. At the same time it does not look as a DoS vector due to the
caching performed by the nodes.
PVF pre-checking can be enabled and disabled. Initially, according to
the changes in #4420, this mechanism is disabled. Triggering the PVF
pre-checking when it is disabled just means that we insta approve the
requesting operation. This should lead to the behavior being unchanged.
Follow-ups:
- expose runtime APIs
* cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=polkadot-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/polkadot/src/weights/runtime_parachains_paras.rs
* cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=westend-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/westend/src/weights/runtime_parachains_paras.rs
* cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=kusama-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/kusama/src/weights/runtime_parachains_paras.rs
* cargo run --quiet --release --features runtime-benchmarks -- benchmark --chain=rococo-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/rococo/src/weights/runtime_parachains_paras.rs
* Review fixes
Co-authored-by: Parity Bot <admin@parity.io>
* Versi chainspec based on Rococo.
* Fix.
* Fix compilation without features.
* Spelling
* Another typo.
* Support versi in native version
* 🤦
* Regenerated genesis for versi.
* Update cli/src/command.rs
Co-authored-by: Bastian Köcher <info@kchr.de>
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
* Make `SimpleSlotWorker::block_import_params()` return function that returns a future
* Simplify `SimpleSlotWorker::block_import_params()` to just async method
* rpc-author: Downgrade the logging level of some logs
Currently these messages are printed with `warn` levels, but they don't bring the node operator
anything. The problem with these log lines is that they are triggered by external users when they
send invalid transactions. This pr "resolves" this by downgrading the log severity to debug, aka not
shown by default.
* FMT
* Remove cargo unleash CI job
The CI job is currently breaking, because we released some crates. We also don't need the job
currently because releases are not done. So, the job currently just annoys people and eats CPU time.
This brings us to the conclusion that this job is currently not required and can be readded at a
later point when we are sure that we need it.
* Hopefully fix UI test
* Another try
* Remove `reserved_keyword` ui
We wanted to change niceness to accomodate the fact that some of the
preparation tasks are low priority. For example, when a node sees that
there is a new para was onboarded the node may start preparing right
away. Since all other activities are more important, such as network I/O
or validation of the backed candidates and preparation of the
immediatelly needed PVFs.
However, it turned out that this approach does not work: generally
non-root processes can only decrease niceness and they cannot increase
it to the previous value, as was assumed by the code.
Apart from that, https://github.com/paritytech/polkadot/pull/4123
assumes all PVFs are prepared in the same way. Specifically, that if a
PVF preparation failed before, then PVF pre-checking will also report
that it was failed, even though it could happen that preparation failed
due to being low-priority. In order to avoid such cases, we decided to
simplify the whole preparation model. Preparation under low priority
does not work well with that.
Closes https://github.com/paritytech/polkadot/issues/4520
As part of #3211 we will need to add a couple of runtime APIs. That
change is coming in a following PR.
The runtime API for pre-checking will be introduced with a version bump
for `ParachainHost`. This commit prepares the ground for that change,
by introducing a error condition that signals that the given API is not
supported.
* Statically register host WASM functions
* Fix `substrate-test-client` compilation
* Move `ExtendedHostFunctions` to `sp-wasm-interface`
* Fix `sp-runtime-interface` tests' compilation
* Fix `sc-executor-wasmtime` tests' compilation
* Use `runtime_interface` macro in `test-runner`
* Fix `sc-executor` tests' compilation
* Reformatting/`rustfmt`
* Add an extra comment regarding the `H` generic arg in `create_runtime`
* Even more `rustfmt`
* Depend on `wasmtime` without default features in `sp-wasm-interface`
* Bump version of `sp-wasm-interface` to 4.0.1
* Bump `sp-wasm-interface` in `Cargo.lock` too
* Bump all of the `sp-wasm-interface` requirements to 4.0.1
Maybe this will appease cargo-unleash?
* Revert "Bump all of the `sp-wasm-interface` requirements to 4.0.1"
This reverts commit 0f7ccf8e0f371542861121b145ab87af6541ac30.
* Make `cargo-unleash` happy (maybe)
* Use `cargo-unleash` to bump the crates' versions
* Align to review comments
Bernhard Schuster