* Allow the treasury to have a maximum bound on the bond
* Update frame/treasury/src/lib.rs
Co-authored-by: Keith Yeung <kungfukeith11@gmail.com>
Co-authored-by: Keith Yeung <kungfukeith11@gmail.com>
* use free balance rather than total balance
* Docs
* Migration for over-locked phrag voters
* New line
* comment
* Update frame/elections-phragmen/src/migrations/v5.rs
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
* Only set lock, don't remove it
* delete commented out
* docs
* Update migration to just take a set of accounts
Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
if the PVF pre-checking is disabled the runtime dispatchable will reject
any attempts of submission. This is also concern the unsigned tx
validation.
Right now, the `include_pvf_check_statement` dispatchable is effectively
uncallable because of the weight set to the maximum value. If we were to
benchmark it, it would become includable in a block, but since there
will be no active votes, the dispatchable won't do anything.
However, it will execute some code, like signature validation and
querying some storage entries. To be completely safe, we can bail out
early if the `pvf_checking_enabled` config is disabled. That's what this
PR does.
* Gav wrote this code in pull #10195. Extracting to simplify that PR.
* fix potential panics
* prevent panics in slide
* update doc
* fmt
* Update frame/support/src/storage/bounded_vec.rs
Co-authored-by: Keith Yeung <kungfukeith11@gmail.com>
Co-authored-by: Gav Wood <gavin@parity.io>
Co-authored-by: Keith Yeung <kungfukeith11@gmail.com>
* 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
Gavin Wood