* Happy New Year!
* Remove year entierly
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Remove years from copyright notice in the entire repo
---------
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Remove use of Store trait from runtime directory
* Remove Store trait usage from xcm directory
* Run cargo fmt
* update lockfile for {"substrate"}
---------
Co-authored-by: parity-processbot <>
* Use a `BoundedVec` in `ValidationResult`
> Use a `BoundedVec` for `upward_messages` and `horizontal_messages` in order to
> limit the number of individual messages/memory allocations right at decoding
> time. The reason for this is that the `ValidationResult` may contain a code
> upgrade (including a full PVF binary), so the total size limit can't be set
> too low and this limit will still allow several millions of upward messages,
> which will (due to the memory allocator overhead) already have a
> non-negligible memory footprint in decoded form.
* List all fields when hashing so we don't miss one
* Define types for `BoundedVec`s of messages
* Fix test compile errors
* Depend on `bounded-collections` 0.1.4 (fixes allocation issue)
* Fix compilation issue
* Derive `Hash` instead of manual `impl`
* Avoid use of unwrap
* disputes pallet: Filter disputes with votes less than supermajority threshold
* Remove `max_spam_slots` usages
* Remove `SpamSlots`
* Remove `SpamSlotChange`
* Remove `Error<T>::PotentialSpam` and stale comments
* `create_disputes_with_no_spam` -> `create_disputes`
* Make tests compile - wip commit
* Rework `test_dispute_timeout`. Rename `update_spam_slots` to `filter_dispute_set`
* Remove `dispute_statement_becoming_onesided_due_to_spamslots_is_accepted` and `filter_correctly_accounts_spam_slots` -> they bring no value with removed spam slots
* Fix `test_provide_multi_dispute_success_and_other`
* Remove an old comment
* Remove spam slots from tests - clean todo comments
* Remove test - `test_decrement_spam`
* todo comments
* Update TODO comments
* Extract `test_unconfirmed_are_ignored` as separate test case
* Remove dead code
* Fix `test_unconfirmed_are_ignored`
* Remove dead code in `filter_dispute_data`
* Fix weights (related to commit "Remove `SpamSlots`")
* Disputes migration - first try
* Remove `dispute_max_spam_slots` + storage migration
* Fix `HostConfig` migration tests
* Deprecate `SpamSlots`
* Code review feedback
* add weight for storage version update
* fix bound for clear()
* Fix weights in disputes migration
* Revert "Deprecate `SpamSlots`"
This reverts commit 8c4d967c7b061abd76ba8b551223918c0b9e6370.
* Make mod migration public
* Remove `SpamSlots` from disputes pallet and use `storage_alias` in the migration
* Fix call to `clear()` for `SpamSlots` in migration
* Update migration and add a `try-runtime` test
* Add `pre_upgrade` `try-runtime` test
* Fix some test names in `HostConfiguration` migration
* Link spamslots migration in all runtimes
* Add `test_unconfirmed_disputes_cause_block_import_error`
* Update guide
- Remove `SpamSlots` related information from roadmap/implementers-guide/src/runtime/disputes.md
- Add 'Disputes filtering' to Runtime section of the Implementor's guide
* Update runtime/parachains/src/configuration/migration.rs
Co-authored-by: Marcin S. <marcin@bytedude.com>
* Code review feedback - update logs
* Code review feedback: fix weights
* Update runtime/parachains/src/disputes.rs
Co-authored-by: s0me0ne-unkn0wn <48632512+s0me0ne-unkn0wn@users.noreply.github.com>
* Additional logs in disputes migration
* Fix merge conflicts
* Add version checks in try-runtime tests
* Fix a compilation warning`
Co-authored-by: Marcin S. <marcin@bytedude.com>
Co-authored-by: s0me0ne-unkn0wn <48632512+s0me0ne-unkn0wn@users.noreply.github.com>
* remove v0 primitives from polkadot-primitives
* first pass: remove v0
* fix fallout in erasure-coding
* remove v1 primitives, consolidate to v2
* the great import update
* update runtime_api_impl_v1 to v2 as well
* guide: add `Version` request for runtime API
* add version query to runtime API
* reintroduce OldV1SessionInfo in a limited way
* Add `without_storage_info`
The MaxEncodedLen trait is now enforced by default in Substrate.
All pallets missing an implementation need to be marked with
`without_storage_info` now.
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Remove `generate_storage_info`
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Add more `without_storage_info`
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* update lockfile for {"substrate"}
Co-authored-by: parity-processbot <>
Closes#4248
Impose additional constraint on configuration consistency:
`validation_upgrade_delay` should not be less than or equal to 1.
See the original issue for more details.
This commit refactors the consistency checks. Instead of each individual
setter performs its checks locally, we delegate those checks to the
already existing function `check_consistency`. This removes duplication
and simplifies the logic.
A motivating example of this one is the next PR in the stack that will
introduce a check for a field, which validity depends on the validity of
other two fields. Without this refactoring we will have to place a check
not only to the field in question, but also to the other two fields so
that if they are changed they do not violate consistency criteria. It's
easy to imagine how this can go unwieldy with the number of checks.
This also adds a test that verifies that the default chain spec host
configuration is consistent.
Refactor the configuration module's initializer_on_new_session in such a
way that it returns the configuration. This would make it inline with
other special initialization routines like `shared`'s or `paras`.
This will be useful in a following PR that will check consistency of the
configuration before setting it.
* 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>
This PR is a part of #3211.
This PR adds three new fields into the `HostConfiguration` structure.
The fields are going to be used in PRs down the stack.
This change requires migration, so this PR performs runtime storage
migration for configuration module from version 1 to version 2.
This PR closes#4010 and subsumes #4177.
* Introduce new config: ump_max_individual_weight
* Implement overweight msg stashing
* Test
* Add migration module.
Also introduces a test for migration
* Integrate ExecuteOverweightOrigin to runtimes
* Fix more stuff
* Add `yeet` into dictionary
* Use suggested `Error` variant names
* typo
* Use 20ms as the maximum individual message weight
* Update the test value
* rustfmt
* Clean up
* Remove deprecated field from host config
* Remove missed _hrmp_open_request_ttl
* Apply typo fix suggestion
Co-authored-by: Alexander Popiak <alexander.popiak@parity.io>
* Rename `migration::migrate_to_latest`
* Restore `_hrmp_open_request_ttl` in `v0::HostConfiguration`
* Apply suggestion for a rustdoc
* Apply the suggestion
* Test v0 config with the raw production data fetched from Kusama
* Update runtime/parachains/src/ump.rs
Co-authored-by: Alexander Popiak <alexander.popiak@parity.io>
* Expose migration functions
* Fix spellcheck
Co-authored-by: Alexander Popiak <alexander.popiak@parity.io>
Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
Co-authored-by: Keith Yeung <kungfukeith11@gmail.com>
* Do not expire HRMP open channel requests
* Fix the build and update the docs
* Implement canceling requests and do not remove them automatically
* Fix a borked merge
* Fix fmt
* Please spellchecker
* Apply suggestions from code review
Co-authored-by: Amar Singh <asinghchrony@protonmail.com>
* Use `mutate_exists` for maintaining request counts
* Apply `rustfmt`
* Move newly introduced entrypoint to end to preserve ordering
Co-authored-by: Amar Singh <asinghchrony@protonmail.com>
* Change pallet naming in test-runtime
This is required to make the `well_know_keys::ACTIVE_CONFIG` match the
`ActiveConfig` key.
* Use correct name
* 🤦
* gotta migrate them all
* migrate rococo construct_runtime
* trigger ci
* fix warnings
* get mocks to work
* add pallet to test runtime
* comments
* calm down mr tabrizi lol
* CI: add spellcheck
* revert me
* CI: explicit command for spellchecker
* spellcheck: edit misspells
* CI: run spellcheck on diff
* spellcheck: edits
* spellcheck: edit misspells
* spellcheck: add rules
* spellcheck: mv configs
* spellcheck: more edits
* spellcheck: chore
* spellcheck: one more thing
* spellcheck: and another one
* spellcheck: seems like it doesn't get to an end
* spellcheck: new words after rebase
* spellcheck: new words appearing out of nowhere
* chore
* review edits
* more review edits
* more edits
* wonky behavior
* wonky behavior 2
* wonky behavior 3
* change git behavior
* spellcheck: another bunch of new edits
* spellcheck: new words are koming out of nowhere
* CI: finding the master
* CI: fetching master implicitly
* CI: undebug
* new errors
* a bunch of new edits
* and some more
* Update node/core/approval-voting/src/approval_db/v1/mod.rs
Co-authored-by: Andronik Ordian <write@reusable.software>
* Update xcm/xcm-executor/src/assets.rs
Co-authored-by: Andronik Ordian <write@reusable.software>
* Apply suggestions from code review
Co-authored-by: Andronik Ordian <write@reusable.software>
* Suggestions from the code review
* CI: scan only changed files
Co-authored-by: Andronik Ordian <write@reusable.software>
* guide: max_validators
* guide: new approach
* restrict validators based on configurable max
* add some tests
* fix wasm build (Vec)
* clean up warnings
* add logging
* set validator indices in tests as well
* fix common tests
* Update runtime/parachains/src/util.rs
Co-authored-by: Andronik Ordian <write@reusable.software>
Co-authored-by: Andronik Ordian <write@reusable.software>
* initial implementation of lifecycles and upgrades
* clean up a bit
* fix doc comment
* more rigid lifecycle checks
* include paras which are transitioning, and lifecycle query
* format guide
* update api
* update guide
* explicit outgoing state, fix genesis
* handle outgoing with transitioning paras
* do not include transitioning paras in identifier
* Update roadmap/implementers-guide/src/runtime/paras.md
* Update roadmap/implementers-guide/src/runtime/paras.md
* Update roadmap/implementers-guide/src/runtime/paras.md
* Apply suggestions from code review
* Use matches macro
* Correct terms
* Apply suggestions from code review
* actions queue
* Revert "actions queue"
This reverts commit b2e9011ec8937d6c73e99292416c9692aeb30f73.
* collapse onboarding state
* starting actions queue
* consolidate actions queue
* schedule para initialize result
* more actions queue for upgrade/downgrade
* clean up with fully implemented actions queue
* fix tests
* fix scheduler tests
* fix hrmp tests
* fix test
* doc fixes
* fix hrmp test w/ valid para
* Update paras.md
* fix paras registrar
* Update propose_parachain.rs
* fix merge
* Introduce "shared" module
* fix rococo build
* fix up and use shared
* guide updates
* add shared config to common tests
* add shared to test-runtime
* remove println
* fix note
Co-authored-by: Gavin Wood <gavin@parity.io>
s0me0ne-unkn0wn