- Jan 30, 2022
-
-
ordian authored
-
- Jan 28, 2022
-
-
Bernhard Schuster authored
* fixup * fmt * fix tests
-
Lldenaurois authored* Move PersistedValidationData check into * Address feedback * Remove incorrect comment * Update runtime/parachains/src/inclusion/mod.rs * fmt * Add logging Co-authored-by:
Robert Habermeier <[email protected]> Co-authored-by:
Andronik <[email protected]>
-
- Jan 27, 2022
-
-
Robert Klotzner authored
* Fix incomplete sorting. * fmt. * Better test. * Update runtime/parachains/src/disputes.rs Co-authored-by:
Bastian Köcher <[email protected]> * chore fmt * simplify the sorting for two items * add test for assure duplicates are detected * fixup tests Co-authored-by:
Bernhard Schuster <[email protected]>
-
- Jan 21, 2022
-
-
Kian Paimani authored
* wip template for hrmp benchmarks * add all of the benchmarks, first draft * File was not saved :/ * cargo +nightly fmt * Use configs * add configs * Fix rococo * Final touches * revert fmt changes, one last time * Fix wrappings * Fix a bunch of tests * cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=kusama-dev --steps=50 --repeat=20 --pallet=runtime_parachains::hrmp --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/kusama/src/weights/runtime_parachains_hrmp.rs * add to westend * actually use everything * cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=westend-dev --steps=50 --repeat=20 --pallet=runtime_parachains::hrmp --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/westend/src/weights/runtime_parachains_hrmp.rs * Update runtime/parachains/src/hrmp.rs Co-authored-by:
Keith Yeung <[email protected]> * use real weight in wnd * reorg * minor cleanup * weigh some of the internal stuff as well * cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=kusama-dev --steps=50 --repeat=20 --pallet=runtime_parachains::hrmp --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/kusama/src/weights/runtime_parachains_hrmp.rs * cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=westend-dev --steps=50 --repeat=20 --pallet=runtime_parachains::hrmp --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/westend/src/weights/runtime_parachains_hrmp.rs * add files * Master.into() * add validation * fmt * fmt * final fixes * all runtimes build * undo formatting * Update runtime/parachains/src/hrmp.rs Co-authored-by:
Zeke Mostov <[email protected]> * non-controversial changes * do it the parachain-way: use const instead of type configs for simplicity. * borrow assert_storage_consistency_exhaustive * move assert_storage_consistency_exhaustive to Pallet, so it can be reused for benchmarks as well. * fix typo Co-authored-by:
Parity Bot <[email protected]> Co-authored-by:
Sergey Shulepov <[email protected]> Co-authored-by:
-
- Jan 20, 2022
-
-
Oliver Tale-Yazdi authored* 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 <[email protected]> * Remove `generate_storage_info` Signed-off-by:
-
Bernhard Schuster authored
* fix miscalculation of remaining weight * rename a var * move out enforcing filtering by dropping inherents * prepare for dispute statement validity check being split off * refactor * refactor, only check disputes we actually want to include * more refactor and documentation * refactor and minimize inherent checks * chore: warnings * fix a few tests * fix dedup regression * fix * more asserts in tests * remove some asserts * chore: fmt * skip signatures checks, some more * undo unwatend changes * Update runtime/parachains/src/paras_inherent/mod.rs Co-authored-by:
sandreim <[email protected]> * cleanups, checking CheckedDisputeStatments makes no sense * integrity, if called create_inherent_inner, it shall do the checks, and not rely on enter_inner * review comments * use from impl rather than into * remove outdated comment * adjust tests accordingly * assure no weight is lost * address review comments * remove unused import * split error into two and document * use assurance, O(n) * Revert "adjust tests accordingly" This reverts commit 3cc9a3c449f82db38cea22c48f4a21876603374b. * fix comment * fix sorting * comment Co-authored-by:
-
- Jan 17, 2022
-
-
Sergey Pepyakin authored
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.
-
- Jan 13, 2022
-
-
Sergey Pepyakin authored
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.
-
- Jan 12, 2022
-
-
Xiliang Chen authored
* fix tests * update lockfile for substrate Co-authored-by: parity-processbot <>
-
- Jan 07, 2022
-
-
Sergey Pepyakin authored
Looks like it is an artifact of prior code and now it is redundant.
-
- Jan 05, 2022
-
-
Sergey Pepyakin authored
-
sandreim authored
* initial changes Signed-off-by:
Andrei Sandu <[email protected]> * fmt Signed-off-by:
-
- Jan 03, 2022
-
-
Keith Yeung authored
* Set CurrentCodeHash before running some dispatchable benchmarks * Use insert instead of put * Actually hash the ValidationCode * 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 Co-authored-by: -
Sergey Pepyakin authored
This is only a module structure change: the tests module was promoted to have its own file.
-
- Jan 01, 2022
-
-
Sergey Pepyakin authored
As was brought up in [here][og], we have some copy&paste comments. I fixed them and also took liberty of fixing some other places. Specifically, those that say "module" instead of contemporary "pallet". [og]: https://github.com/paritytech/polkadot/pull/4603#discussion_r776971291
-
- Dec 31, 2021
-
-
Sergey Pepyakin authored
Closes #3971 Read the linked issue. Apart from that, this addresses the concern raised in this [comment] by just adding a test. I couldn't find a clean way to reconcile a block number delay with a PVF voting TTL, so I just resorted to rely on the test. Should be fine for now. [comment]: https://github.com/paritytech/polkadot/pull/4457#discussion_r770517562
-
- Dec 30, 2021
-
-
Sergey Pepyakin authored
This just renames a member of `HostConfiguration` from validation_upgrade_frequency to -//-_cooldown. As was already pointed out in #4460 the existing name is a misnomer, the member actually represents a minimum time period between upgrades, which is neatly expressed by a word cooldown. I've been planning this rename already for some time and the term is already used in paras module: https://github.com/paritytech/polkadot/blob/1394b70d/runtime/parachains/src/paras.rs#L1568-L1574
-
- Dec 29, 2021
-
-
Sergey Pepyakin authored
* paras: add governance control dispatchables Adds a couple of functions for governance control for the paras module in the anticipation of PVF pre-checking enabling. Specifically, this commit adds a function for pre-registering a PVF that governance trusts enough. This function will come in handy in case there is a parachain that does not follow the GoAhead signal. That is, does not include https://github.com/paritytech/cumulus/pull/517. This may be not an exhaustive list of the functions that may come in handy. Any suggestions to add more are welcome. * 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=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=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 Co-authored-by:
-
- Dec 28, 2021
-
-
Sergey Pepyakin authored
This is the first step to close https://github.com/paritytech/polkadot/issues/4524
-
Sergey Pepyakin authored
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.
-
Sergey Pepyakin authored
Setting zero as weight may be a source of problems. The problem is, a rogue validator can shove a lot of duplicated votes and thus fill a block with work that may well exceed the weight limit.
-
Sergey Pepyakin authored
As was suggested by Alexander Popiak [here][comment], this commit checks the consistency of the configuration. [comment]: https://github.com/paritytech/polkadot/pull/4420#discussion_r764796519
-
- Dec 27, 2021
-
-
Sergey Pepyakin authored
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.
-
ordian authored
-
ordian authored
* session_info: v2 + migration * use primitives::v2 * use polkadot_primitives::v2 * impl primitives::v2 * fix approval-voting tests * fix other tests * hook storage migration up * backwards compat (1) * backwards compat (2) * fmt * fix tests * FMT * do not reexport v1 in v2 * fmt * set storage version to 1 Co-authored-by:Javier Viola <[email protected]>
-
- Dec 24, 2021
-
-
cheme authored
* merge master (do not compile) * fix * lock * update lock * Update to refactoring. * runtime version * fmt * remove trie patch * remove patch * No layout alias for bridge proof. * update depupdate depss * No switch until migration. * master lock * test * test * Revert "test" This reverts commit 57325ef73332bf4b054aa4a667bb716fcf8a0d89. * Revert "test" This reverts commit ce74d0e2062806f72c0e9e9ca07b14165f43521e. * rename feature * state version as parameter, use the feature only on runtimes. * update * update to state version in runtime * state version from storage * update lockfile for substrate Co-authored-by: parity-processbot <>
-
- Dec 23, 2021
-
-
Robert Klotzner authored
* First step in implementing https://github.com/paritytech/polkadot/issues/4386 This PR: - Reduces MAX_UNSHARED_UPLOAD_TIME to 150ms - Increases timeout on collation fetching to 1200ms - Reduces limit on needed backing votes in the runtime This PR does not yet reduce the number of needed backing votes on the node as this can only be meaningfully enacted once the changed limit in the runtime is live. * Fix tests. * Guide updates. * Review remarks. * Bump minimum required backing votes to 2 in runtime. * Make sure node side code won't make runtime vomit. * cargo +nightly fmt
-
- Dec 22, 2021
-
-
Sergey Pepyakin authored
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.
-
- Dec 21, 2021
-
-
Sergey Pepyakin authored
Basically updates the docs for the paras module.
-
Sergey Pepyakin authored
* parachains: Fix configuration module Closes #4529 Closes #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:
-
- Dec 16, 2021
-
-
Sergey Pepyakin authored
-
Sergey Pepyakin authored
Simply extract hardcoded log target into a const.
-
Sergey Pepyakin authored
* 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: -
sandreim authored
* Add runtime metrics provider Signed-off-by:
-
- Dec 14, 2021
-
-
Gavin Wood authored
* Some work * Fixes * Tests builds * Fixes * Fixes * Fixes * Fixes * Fixes * Formatting * Formatting * Fix * Fixes * Fixes * Fixes * Fixes * Update Cargo.lock * Bump * Fixes
-
- Dec 10, 2021
-
-
Bernhard Schuster authored
-
Bernhard Schuster authored
* remove Default from CandidateHash * Apply suggestions from code review Co-authored-by:
emostov <[email protected]> Co-authored-by:
Gavin Wood <[email protected]>
-
- Dec 09, 2021
-
-
Gavin Wood authored
* MaxConsumers * Fixes * fixes * one more fix * Bump Substrate Co-authored-by:Shawn Tabrizi <[email protected]>
-
- Dec 08, 2021
-
-
Sergey Pepyakin authored
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.
-
