* fix order
* Update frame/support/procedural/src/construct_runtime/mod.rs
Co-authored-by: Alexander Popiak <alexander.popiak@parity.io>
* format
* more accurate description
* format
* better explicit types
* fix tests
* address feedback
* add a type to ease non breaking implementation
* add comment about constraint
* fix test
* add test for generated types
Co-authored-by: Alexander Popiak <alexander.popiak@parity.io>
* pvf-precheck: Add `sign` in subsystem-util
Right now, most of operations that sign stuff in polkadot protocol are
handled by a very convenient tool - `Signed`. However `Signed` assumes
that whatever is signed is anchored to some `parent_hash` which works
for most cases, but does not work for others.
One instance of such a case is pre-checking (#3211). There validators
submit signed votes on-chain. A vote is valid for the entire session. If
we were to use `Signed` we would have to root a vote in some block of
that session and during vote verification check that this block is
indeed within the session. This is especially annoying since we agreed
to use unsigned extrinsics to submit votes and we need to make the
unsigned extrinsic validation as slim as possible.
(FWIW, the definition of a pre-checking vote can be seen in the next
diff in the stack)
That's the reason why we opted-out from using `Signed` for pre-checking
and decided to go with the manual signing approach. Almost every piece
of machinery is in place except for signing which is presented in this
PR.
* pvf-precheck: Add `PvfCheckStatement` to polkadot-primitives
This is an insubstantial PR that just unlocks PRs down the line. This PR
is a part of #3211.
Regarding the `PvfCheckStatement` struct itself: this is a structure
that will be used to convert from/into the binary representation and
ultimately will be used to sign and submit votes onto chain.
Right now, most of operations that sign stuff in polkadot protocol are
handled by a very convenient tool - `Signed`. However `Signed` assumes
that whatever is signed is anchored to some `parent_hash` which works
for most cases, but does not work for others.
One instance of such a case is pre-checking (#3211). There validators
submit signed votes on-chain. A vote is valid for the entire session. If
we were to use `Signed` we would have to root a vote in some block of
that session and during vote verification check that this block is
indeed within the session. This is especially annoying since we agreed
to use unsigned extrinsics to submit votes and we need to make the
unsigned extrinsic validation as slim as possible.
(FWIW, the definition of a pre-checking vote can be seen in the next
diff in the stack)
That's the reason why we opted-out from using `Signed` for pre-checking
and decided to go with the manual signing approach. Almost every piece
of machinery is in place except for signing which is presented in this
PR.
* minor: assure conditions match
This simplifies visual integrity checks that an overseer is connected
when it has to be.
* fix: avoid printing a misleading log in case of the disabled disputes feature
* chore: comments
* add expressive types for the selection algorithm
* 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
Closes https://github.com/paritytech/polkadot/issues/4293
This PR changes the way how we treat a certain subset of PVF preparation
errors. Specifically, now only the deterministic errors are treated as
invalid candidates. That is, the errors that are easily
attributable to either the the PVF contents or the wasmtime code, but
not e.g. I/O errors that could be triggered by the OS (insufficient
memory, disk failure, too much load, etc). The latter are treated as
internal errors and thus do not trigger the disputes.
* Impose new restrictions on paras init and cleanup
For upcoming PVF pre-checking feature we will need to impose a couple of
new restrictions for:
- `schedule_para_initialize`.
- `schedule_para_cleanup`.
Specifically, for the former we do not want to allow registration of
wasm blob that is empty, i.e. 0 bytes. While that currently already
does not make a lot of sense, it allows us to simplify the PVF
pre-checking logic: if this PR is deployed before the following changes
for PVF prechecking then we can be sure that no paras onboarding have to
have to go through the PVF pre-checking. In case, we deploy it
altogether this property will allow us to distingush paras that came in
before PVF pre-checking.
For `schedule_para_cleanup` we do not want to allow offboarding of paras
that are undergoing the upgrade process. While this is not a harsh
restriction this change allows us to avoid making the PVF prechecking
more complicated than it has to be.
* Add a test for schedule_para_initialize
* Link to `ParaLifecycle::is_stable` in docs.
* `schedule_para_{init,cleanup}` docs
Now they link to their original declarations in the pallet for more
details.
Guillaume Thiolliere