This commit hooks up the API provided by #4457 to the runtime API
subsystem. In a following PR this API will be consumed by the PVF
pre-checking subsystem.
Co-authored-by: Chris Sosnin <chris125_@live.com>
Co-authored-by: Chris Sosnin <chris125_@live.com>
* parachains: Fix configuration module
Closes#4529Closes#4533
I figured that trying to avoid updates does not really worth it to keep.
This is because we seem to not update the configuration often and when
we do we approach this carefully. Thus possibility of a redundant update
is really negligable. At the same time, if such a redundant update does
happen then the effects of that are really small: just some wasted
storage interactions.
On the other hand, making it work was a little bit annoying. With the
proper fix for the pending updates this would be even more annoying
since now we would have to add combinatorically more cases to test this.
So I figured that I will just scrap that and simplify the code.
* cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=kusama-dev --steps=50 --repeat=20 --pallet=runtime_parachains::configuration --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/kusama/src/weights/runtime_parachains_configuration.rs
* cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=polkadot-dev --steps=50 --repeat=20 --pallet=runtime_parachains::configuration --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/polkadot/src/weights/runtime_parachains_configuration.rs
* cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=westend-dev --steps=50 --repeat=20 --pallet=runtime_parachains::configuration --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/westend/src/weights/runtime_parachains_configuration.rs
* review fixes
Co-authored-by: Parity Bot <admin@parity.io>
* 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>
* rococo-runtime: Switch to latest `construct_runtime!` syntax
Besides that it fixes pallet macro errors in other crates that popped up
because of this switch.
* FMT
* Introduce `OriginPrivilegeCmp`
Make use of the new `OriginPrivilegeCmp` feature of pallet scheduler.
The idea is to make sure that a council origin with more yes votes has
higher privileges than a council origin with less yes votes. This solves
a problem that happened recently on Kusama where the council tried to
cancel a scheduled task, but that required that the same council origin
was used while the cancel motion had more yes votes than the origin
motion that scheduled this task. With this origin privilege compare it
should now be solved by checking the yes votes directly.
* Feedback
* update lockfile for substrate
Co-authored-by: parity-processbot <>
* Introduce new Runtime API endpoint
`persisted_validation_data_with_code_hash` that will be used
by the candidate validation subsystem in order to decrease amount
of runtime API requests.
* Node-side part of new runtime API request
* Define code hash getter via macro
* Rename new endpoint to `assumed_validation_data`
* Docs for runtime API impl of new endpoint
* AssumedValidationData specialized request function
* fmt
* export xcm_pallet config
Signed-off-by: Cheng JIANG <alex_cj96@foxmail.com>
* run format
Signed-off-by: Cheng JIANG <alex_cj96@foxmail.com>
* fix typo
Signed-off-by: Cheng JIANG <alex_cj96@foxmail.com>
* add generic parameter to support different runtimes
* Revert "add generic parameter to support different runtimes"
This reverts commit 4405ea9fab24307318ffc20a833010fe864b3be3.
* dummy: impl another runtime API
* query the on chain disputes, and inform self
* make use of the refactor
* minro
* SPLIT ME
* write dispute values
* wip
* impl for all runtimes
* chore: fmt
* [] -> get
* fixup mock runtime
* fixup
* fixup discovery for overseer init
* chore: fmt
* spellcheck
* rename imported_on_chain_disputes -> on_chain_votes
* reduction
* make it mockable
* rename and refactor
* don't query on chain info if it's not needed
* yikes
* fmt
* fix test
* minimal fix for existing tests
* attempt to fetch the session info from the rolling window before falling back
* moved
* comments
* comments
* test for backing votes
* rename
* Update runtime/polkadot/src/lib.rs
* chore: spellcheck + dict
* chore: fmt
* fixup cache size
* add warning
* logging, rationale, less defense
* introduce new unchecked, that still checks in debug builds
* fix
* draft alt approach
* fix unused imports
* include the session
* Update node/core/dispute-coordinator/src/real/mod.rs
Co-authored-by: Robert Habermeier <rphmeier@gmail.com>
* provide where possible
* expand comment
* fixin
* fixup
* ValidityVote <-> ValidityAttestation <-> CompactStatement has a 1:1 representation
* mark TODO
* Update primitives/src/v1/mod.rs
Co-authored-by: Robert Habermeier <rphmeier@gmail.com>
* address review comments
* update docs
Co-authored-by: Robert Habermeier <rphmeier@gmail.com>
* add slot offset for slots
* trying things out
* fix test
* improve api to return the first block of a new lease period
* add an integration test with offset
* de-duplicate test
* hide lease period_period_length from public api
* fix benchmarks
* Update runtime/common/src/slots.rs
* support the exact same range of crowdloans
* fix docs
* fix docs again
* introduce offset to runtimes
* fix and check edge case w/ offset and lease period first block
* remove newline
* turn into an option
* fix benchmarks
Co-authored-by: Robert Habermeier <rphmeier@gmail.com>
* bump version and spec_version
* bump transaction version
* Bump of the default value in CI
* bump tx version for westend and kusama
Co-authored-by: Wilfried Kopp <wilfried@parity.io>
* Adding MaxSegmentLength and MaxAuthorities
to pallet babe
* Missed a few to_vec
* Removing `MaxSegmentLength` as not needed anymore
* Adding `MaxAuthorities` to couple of missing place
* Adding missing definition of `MaxAuthorities`
* Adding a missing to_vec
* update Substrate
Co-authored-by: thiolliere <gui.thiolliere@gmail.com>
Co-authored-by: parity-processbot <>
* Adding `MaxAuthorities` to pallet grandpa
This is neede after changes to substrate
* Adding `MaxAuthorities` to granda in test-runtime
* Missed one `MaxAuthorities`
* update Substrate
Co-authored-by: parity-processbot <>
Sergei Shulepov