* runtime-interface: Implement `register_only` functions
The runtime interface supports versioning of functions. Currently, if you add a new function it will
be used by the runtime automatically. This results in requiring all nodes of a network to upgrade
before the runtime is upgraded, otherwise they will fail to instantiate the new runtime because of
missing host functions. This pr introduces `register_only` functions. This can be used when a new
runtime interface function should be introduced, but the actual usage can be deferred. This means
that nodes will have the host function for this, but the runtime will still use the old version of
the function when being compiled for wasm. However, when a runtime is enacted that uses the new host
function, the "old nodes" will already have the host function and will continue to work.
* Update primitives/runtime-interface/src/lib.rs
Co-authored-by: cheme <emericchevalier.pro@gmail.com>
* Update primitives/runtime-interface/proc-macro/src/utils.rs
Co-authored-by: cheme <emericchevalier.pro@gmail.com>
* FMT
Co-authored-by: cheme <emericchevalier.pro@gmail.com>
* add fast-runtime feature for reduced session times
* make democracy periods fast on fast-runtime
* propagate fast-runtime feature through cargo.toml files
* add fast motion and term durations to Kusama
* Update runtime/westend/Cargo.toml
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
* set session time to 2 minutes to avoid block production issues
* formatting
* update Substrate
* set democracy fast periods back to 1min
* set launch period and enactment period to 1 block in fast-runtime
* remove unnecessary westend period configs
* add prod_or_test macro to allow specifying prod, test and env values for parameter types
* move prod_or_test macro into common module and use it consistently
* rename macro to prod_or_fast
* cargo +nightly fmt
* bump impl_versions
* newline
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
* add note that env variable is evaluated at compile time
* newline
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
* newline
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
* cargo fmt
* impl_version: 0
* impl_version: 0
* use prod_or_fast macro for LeasePeriod and LeaseOffset
* use prod_or_fast macro in WND and ROC constants
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: Giles Cope <gilescope@gmail.com>
In this PR, paras module emit runtime events on certain PVF pre-checking
related conditions.
Specifically, there are 3 new events in the paras module:
1. PvfCheckStarted
2. PvfCheckAccepted
3. PvfCheckRejected
All of those have identifiers for the parachain that triggered the PVF
pre-checking and the validation code that goes through the pre-checking.
The mechanics of those are as follows. Each time a new PVF is added, be
it due to onboarding or upgrading, the `PvfCheckStarted` will be
triggered. If another parachain triggers a pre-checking process for the
validation code which is already being pre-checked, another
`PvfCheckStarted` event will be triggered with the corresponding para
id.
When the PVF pre-checking voting for a PVF was finished, several
`PvfCheckAccepted/Rejected` events will be triggered: one for each para id that
was subscribed to this check (i.e. was a "cause" for it).
If the PVF pre-checking is disabled, then one can still expect these
events to be fired. Since insta PVF approval is syncronous, the
`PvfCheckStarted` will be followed by the `PvfCheckAccepted` with the
same validation code and para id.
If somebody is interested in following validation code changes for a PVF
of a parachain, they would need to subscribe to those events. I did not
supply the topics for the events, since I am not sure if that's needed
or will be used, but they can be added later if needed.
* approval-voting: add more logs
* approval-voting: query finalized block on startup and increase look back
* runtime-api: do not cache None SessionInfo
* Switch types to use `RuntimeDebug` instead of gated `Debug`
This is useful for when you want to debug in wasm and enable the
`force-debug` feature of `sp-debug-derive`.
* Fixes
* 🤦
* Move XCM runtime configurations into their own files
* Update copyright year
* Fix compilation errors
* Import XCM types in westend runtime unit tests
* Remove sleep and use polkadot test service
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
* updates
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
* Fix other tests
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
* Run metrics tests separately
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
* copy some substrate utilities
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
* update runtime metric test
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
* Remove sleep from cli tests
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
* cargo
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
* Polkadot companion for Substrate#10463 (#4519)
* Grandpa and Beefy protocol names include chain id
Signed-off-by: acatangiu <adrian@parity.io>
* chain_spec: include fork id
* use simplified protocol name
* fix after merge
* avoid using hash default, even for protocol names
* update lockfile for substrate
Co-authored-by: parity-processbot <>
* configuration: Update upgrade validation delay doc (#4662)
* typo
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
* review feedback
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
* cargo lock
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
* use testnet profile
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
* Don't run with runtime-benchmark feature
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
* conditional compile up one level
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Co-authored-by: Sergei Shulepov <sergei@parity.io>
`runtime_print!` is printed by default using `debug`, aka not being visible. With `log::error!` it
will be printed directly to the user. Production networks like Polkadot disable logging, but for
them we run special nodes that have logging enabled.
Andronik