- Mar 13, 2023
-
-
Vivek Pandya authored
* 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 <>
-
- Feb 27, 2023
-
-
Anton Vilhelm Ásgeirsson authored
* Add tests for ParachainsCache * Use BTreeSet for ParachainsCache internals * Use `into_iter()` instead of cloneing storage vals
-
- Jan 17, 2023
-
-
Gavin Wood authored
* cargo fmt * Create benchmarks for XCM instructions introduced in v3 (#4564) * Create benchmarks for BurnAsset and ExpectAsset * Add benchmarks for ExpectOrigin and ExpectError * Add benchmarks for QueryPallet and ExpectPallet * Add benchmarks for ReportTransactStatus and ClearTransactStatus * cargo fmt * Use AllPalletsWithSystem in mocks * Update XCM generic benchmarks for westend * Remove default impls for some XCM weight functions * Fix compilation error * Add weight_args helper attribute * Remove manually written XcmWeightInfo * Parse trailing comma * Revert "Add weight_args helper attribute" This reverts commit 3b7c47a6182e1b9227036c38b406d494c3fcf6fd. * Fixes * Fixes * XCM v3: Introduce querier field into `QueryReponse` (#4732) * Introduce querier field into QueryReponse * Convert &Option<MultiLocation> to Option<&MultiLocation> &Option<T> is almost always never quite useful, most of the time it still gets converted to an Option<&T> via `as_ref`, so we should simply make functions that accept Option<&T> instead. * Fix tests * cargo fmt * Fix benchmarks * Appease spellchecker * Fix test * Fix tests * Fix test * Fix mock * Fixes * Fix tests * Add test for response queriers * Update xcm/pallet-xcm/src/lib.rs * Test for non-existence of querier Co-authored-by:
Keith Yeung <[email protected]> * Fixes * Fixes * Add `starts_with` function to `MultiLocation` and `Junctions` (#4835) * add matches_prefix function to MultiLocation and Junctions * rename matches_prefix to starts_with * remove unnecessary main in doc comment Co-authored-by:
Bastian Köcher <[email protected]> * Make use of starts_with in match_and_split Co-authored-by:
Bastian Köcher <[email protected]> Co-authored-by:
Parity Bot <[email protected]> * Fixes * Fixes * Fixes * Fixes * Formatting * Fixes * Formatting * Fixes * Fixes * Formatting * Formatting * Remove horrible names * Bump * Remove InvertLocation trait (#5092) * Remove InvertLocation trait * Remove unneeded functions * Formatting * Fixes * Remove XCMv1 (#5094) * Remove XCMv1 * Remove XCMv1 * Formatting * Fixes * Fixes * Formatting * derive serialize/deserialize for xcm primitives (#5036) * derive serialize/deserialize for xcm primitives * derive serialize/deserialize for xcm primitives * update v3 * update v2 Co-authored-by:
Gav Wood <[email protected]> * Update lock * Fixes * Add benchmarks for the ExchangeAsset instruction * `AliasOrigin` instruction stub (#5122) * AliasOrigin instruction stub * Fixes * Fixes * Update substrate * Fixes * Ensure same array length before using copy_from_slice * Fixes * Add benchmarks for the UniversalOrigin instruction * Remove unused import * Remove unused import * Add benchmarks for SetFeesMode instruction * Add benchmarks for asset (un)locking instructions * Leave AliasOrigin unbenchmarked * Fixes after merge * cargo fmt * Fixes * Fixes * Set TrustedReserves to None on both Kusama and Westend * Remove extraneous reserve_asset_deposited benchmark * Fix universal_origin benchmark * cargo run --quiet --profile=production --features=runtime-benchmarks -- benchmark pallet --chain=westend-dev --steps=50 --repeat=20 --pallet=pallet_xcm_benchmarks::generic --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --template=./xcm/pallet-xcm-benchmarks/template.hbs --output=./runtime/westend/src/weights/xcm/pallet_xcm_benchmarks_generic.rs * Don't rely on skipped benchmark functions * Fixes * cargo run --quiet --profile=production --features=runtime-benchmarks -- benchmark pallet --chain=kusama-dev --steps=50 --repeat=20 --pallet=pallet_xcm_benchmarks::generic --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --template=./xcm/pallet-xcm-benchmarks/template.hbs --output=./runtime/kusama/src/weights/xcm/pallet_xcm_benchmarks_generic.rs * Fix unused variables * Fixes * Spelling * Fixes * Fix codec index of VersionedXcm * Allows to customize how calls are dispatched from XCM (#5657) * CallDispatcher trait * fmt * unused import * fix test-runtime * remove JustDispatch type * fix typo in test-runtime * missing CallDispatcher * more missing CallDispatcher * Update comment `NoteAssetLocked` -> `NoteUnlockable` * Fixes * Fixes * Adjust MultiAssets weights based on new wild card variants * Fixes * Fixes * Fixes * Fixes * Fixes * Some late fixes for XCMv3 (#5237) * Maximise chances that trapped assets can be reclaimed * Do origin check as part of ExportMessage for security * Formatting * Fixes * Cleanup export XCM APIs * Formatting * Update xcm/src/v3/junctions.rs * UnpaidExecution instruction and associated barrier. * Tighten barriers (ClearOrigin/QueryResponse) * Allow only 1 ClearOrigin instruction in AllowTopLevelPaidExecutionFrom * Bi-directional teleport accounting * Revert other fix * Build fixes] * Tests build * Benchmark fixes Co-authored-by:
asynchronous rob <[email protected]> * Add more weight tests * cargo fmt * Create thread_local in XCM executor to limit recursion depth (#6304) * Create thread_local in XCM executor to limit recursion depth * Add unit test for recursion limit * Fix statefulness in tests * Remove panic * Use defer and environmental macro * Fix the implementation * Use nicer interface * Change ThisNetwork to AnyNetwork * Move recursion check up to top level * cargo fmt * Update comment Co-authored-by:
Branislav Kontur <[email protected]> * Fixes * Fixes * Remove topic register and instead use the topic field in XcmContext * Derive some common traits for DispatchBlobError * Fixes * cargo fmt * Fixes * Fixes * Fix comments * Fixes * Introduce WithOriginFilter and apply it as the CallDispatcher for runtimes * Fixes * Appease clippy and fixes * Fixes * Fix more clippy issues * Fixes * ".git/.scripts/bench-bot.sh" runtime polkadot-dev pallet_xcm * ".git/.scripts/bench-bot.sh" runtime westend-dev pallet_xcm * ".git/.scripts/bench-bot.sh" runtime westend-dev pallet_xcm * Add benchmark function for ExportMessage * Fix comment * Add upper limit to DownwardMessageQueues size * Add max size check for queue in can_queue_downward_message * Fixes * Make Transact runtime call configurable * Return Weight::MAX when there is no successful send XCM origin * Update substrate * Fixes * Fixes * Remove ExportMessage benchmark * Remove assertion on Transact instruction benchmark * Make reachable destination configurable in XCM pallet benchmarks * Fixes * Fixes * Remove cfg attribute in fuzzer * Fixes * Remove cfg attribute for XCM pallet in test runtime * Fixes * Use ReachableDest where possible * Fixes * Add benchmark for UnpaidExecution * Update substrate * Ensure benchmark functions pass filters * Add runtime-benchmarks feature to fuzzer * Ensure FixedRateOfFungible accounts for proof size weights * cargo fmt * Whitelist remark_with_event when runtime-benchmarks feature is enabled * Use remark_with_event for Transact benchmarks * Fix Cargo.lock * Allow up to 3 DescendOrigin instructions before UnpaidExecution * cargo fmt * Edit code comment * Check check_origin for unpaid execution privilege * Fixes * Small nits for xcm-v3 (#6408) * Add possibility to skip benchmark for export_message * ".git/.scripts/bench-bot.sh" xcm westend-dev pallet_xcm_benchmarks::generic * Revert * ".git/.scripts/bench-bot.sh" xcm westend-dev pallet_xcm_benchmarks::generic * Add HaulBlobError to `fn haul_blob` * ".git/.scripts/bench-bot.sh" xcm westend-dev pallet_xcm_benchmarks::generic Co-authored-by: command-bot <> * Revert changes to UnpaidExecution * Change AllowUnpaidExecutionFrom to be explicit * Fix log text * cargo fmt * Add benchmarks for XCM pallet version migration (#6448) * Add benchmarks for XCM pallet version migration * cargo fmt * Fixes * Fixes * Fixes * ".git/.scripts/bench-bot.sh" runtime westend-dev pallet_xcm * ".git/.scripts/bench-bot.sh" runtime kusama-dev pallet_xcm * ".git/.scripts/bench-bot.sh" runtime rococo-dev pallet_xcm * ".git/.scripts/bench-bot.sh" runtime polkadot-dev pallet_xcm * Fix benchmarks * Fix benchmarks * ".git/.scripts/bench-bot.sh" runtime westend-dev pallet_xcm * ".git/.scripts/bench-bot.sh" runtime kusama-dev pallet_xcm * ".git/.scripts/bench-bot.sh" runtime rococo-dev pallet_xcm * ".git/.scripts/bench-bot.sh" runtime polkadot-dev pallet_xcm Co-authored-by: command-bot <> * Merge remote-tracking branch 'origin/master' into gav-xcm-v3 * Fixes * Fix comments (#6470) * Specify Ethereum networks by their chain id (#6286) Co-authored-by:
Squirrel <[email protected]> * Use for Kusama * Use WithComputedOrigin for Polkadot, Rococo and Westend * Update lock * Fix warning * Update xcm/pallet-xcm/src/tests.rs Co-authored-by:
Oliver Tale-Yazdi <[email protected]> * Update xcm/pallet-xcm/src/migration.rs Co-authored-by:
Alexander Popiak <[email protected]> Co-authored-by:
stanly-johnson <[email protected]> Co-authored-by:
nanocryk <[email protected]> Co-authored-by:
Vincent Geddes <[email protected]> Co-authored-by:
Shawn Tabrizi <[email protected]>
-
- Jan 12, 2023
-
-
Marcin S. authored* pre-checking: Reject failed PVFs * paras: immediately reject any PVF that cannot reach a supermajority * Make the `quorum` reject condition a bit more clear semantically * Add comment * Update implementer's guide * Update a link Not related to the rest of the PR, but I randomly noticed and fixed this. * Update runtime/parachains/src/paras/tests.rs Co-authored-by:
s0me0ne-unkn0wn <[email protected]> * Remove unneeded loop * Log PVF retries using `info!` * Change retry logs to `warn!` and add preparation failure log * Log PVF execution failure * Clarify why we reject failed PVFs * Fix PVF reject runtime benchmarks Co-authored-by:
-
- Jan 11, 2023
-
-
s0me0ne-unkn0wn authored
* Re-export current primitives in crate root * Add missing exports * restart CI
-
- Dec 19, 2022
-
-
Oliver Tale-Yazdi authored* cargo update -p sp-io Signed-off-by:
-
- Nov 30, 2022
-
-
ordian authored
* guide: remove refences to outdated secondary checkers * Update roadmap/implementers-guide/src/glossary.md * guide: remove refences to Fisherman * revert changes to roadmap/parachains.md
-
- Nov 01, 2022
-
-
alexgparity authored
* Replace parachain/parathread boolean by enum * Address PR comments * Update dependencies * ParaType -> ParaKind * Swap enum field order to avoid migration * Rename paratype field to parakind * Manual en-/decocing of Parakind * Manual TypeInfo for ParaKind * rename field back to parachain * minor * Update runtime/parachains/src/paras/mod.rs Co-authored-by:
Andrei Sandu <[email protected]> * Manual serde Serialize and Deserialize for ParaKind * cargo fmt * Update runtime/parachains/src/paras/mod.rs Co-authored-by:
Andronik <[email protected]> * Add test for serde_json encoding/decoding * Move serde_json dep to dev-deps Co-authored-by:
-
- Oct 11, 2022
-
-
Shawn Tabrizi authored
* remove para lock check for now * fmt * manual para lock * expose schedule_code_upgrade and set_current_head * extrinsics and benchmarks * use zero * add weights * fix variable name * add and fix comments * fix weights * add back default lock Co-authored-by: parity-processbot <>
-
- Sep 26, 2022
-
-
Chris Sosnin authored
* Unblock offboarding for upgrading paras * ".git/.scripts/fmt.sh" 1 Co-authored-by: command-bot <>
-
- Sep 12, 2022
-
-
Sergej Sakac authored
* Companion for #11981 * more renaming * fmt * fixes * add generic type * Companion for #11831 * fix * revert changes * Delete rename-outer-enum.diff * revert * Update run_benches_for_runtime.sh * rename type Call & type Event * passing tests * fmt * small fixes * commit * fix * fmt * commit * error fixes * fix * small fix in test * Update lib.rs * Update lib.rs * Update lib.rs * Update lib.rs * Update lib.rs * Update lib.rs * Update lib.rs * remove RuntimeCall from pallet_grandpa * last fix * commit * rename * merge fix * update lockfile for {"substrate"} * cargo +nightly fmt * fix Co-authored-by: parity-processbot <> Co-authored-by:
-
- Sep 08, 2022
-
-
Keith Yeung authored
* Companion for paritytech/substrate#12183 * Fixes * Fixes * Fixes * cargo fmt * Fixes * Fixes * Fixes * cargo fmt * Update runtime/parachains/src/paras_inherent/mod.rs Co-authored-by:
-
- Sep 01, 2022
-
-
Shawn Tabrizi authored
* updates * remove new * fix up some stuff * fix cargo files * fix * fix template * update lockfile for {"substrate"} * Update block_weights.rs * remove unused * remove unused Co-authored-by: parity-processbot <>
-
- Aug 31, 2022
-
-
Shawn Tabrizi authored
* fix to latest substrate pr * update weights * cargo build -p polkadot-runtime-parachains * fix xcm-builder * fix import * fix a bunch * fix a bunch of weight stuff * kusama compile * unused * builds * maybe fix * cargo test -p polkadot-runtime-parachains * xcm simulator example * fix tests * xcm sim fuzz * fix runtime tests * remove unused * fix integration tests * scalar div * update lockfile for {"substrate"} Co-authored-by: parity-processbot <>
-
- Apr 04, 2022
-
-
Qinxuan Chen authored
* Comanion for substrate#11136 Signed-off-by:
koushiro <[email protected]> * revert changes in bridge Signed-off-by:
-
- Mar 24, 2022
-
-
Sergei Shulepov authored
* paras: `include_pvf_check_statement` rt bench Resolves #4933 This PR adds a benchmark for the `include_pvf_check_statement` dispatchable. This is a necessary step to make it work without modifications. That enables us to proceed with testing on Versi. This introduces 5 new benchmarks. Those measure performance of the `include_pvf_check_statement` under 2 different conditions: 1. regular vote submission. That's the common case. 2. submission of the last vote. That happens only once and leads to a heavy finalization stage. There are 2 different types of finalization (one for onboarding, one for upgrading) and there are two outcomes: accepted and rejected. Those 4 are similar but I decided to cover them all and assign the maximum of all 4. This is to avoid a situation when one of those paths becomes more heavier than others and opens up an attack venue. The regular vote submission weight is drastically different from the submission last vote weight. That's why in case during runtime finalization was not executed the weight consumed value will be lowered down to the regular vote submission. The finalization weight is proportional to the number of "causes", i.e. the events that caused the PVF pre-checking vote in the first place, and here we assume that the maximum number of causes is 100. Theoretically, there is nothing that prevents an adversary to register/upgrade to more than 100 parachains. In that case, the consumed weight will be lower than the actual time consumed by the finalization process. That can enable a DoS vector. However, practically, it is not very possible. Right now it is very expensive to call `schedule_para_initialize` because it requires a very large lock up of funds. Moreover, finalizing a vote with 100 causes leads to around 31ms time spent. Finalizing more will require more time. However, finalizing with 200 causes will cause ≈62ms delay. This is not that bad since even though we had a full block and the adversary tried to finalize 200 causes it won't be able to even exceed the operational extrinsic boundary of 250ms and even if so it won't make big difference. That said, this should be addressed later on, esp. when we enable parathreads, which will make creating causes easier. One of potential solutions will be shifting the logic of finalization into `on_initialize`/`on_finalize`. Another is to create a maximum number of causes and then reject upgrades or onboardings if that was reached. * cargo run --quiet --profile=production --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 --profile=production --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 --profile=production --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 --profile=production --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 * Fix import error Co-authored-by:
Robert Klotzner <[email protected]> Co-authored-by:
Lldenaurois <[email protected]>
-
- Mar 09, 2022
-
-
asynchronous rob authored
* 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
-
- Feb 25, 2022
-
-
wigy authored
* Updating dependencies * Adapting code to scale v3 * Upgrade bitvec to 1.0.0 * Fix bitvec arithmetics * Update Cargo.lock * Update sp-io * Fixing the build * Yanked scale-info 2.0.0 Co-authored-by:
-
- Feb 22, 2022
-
-
Sergei Shulepov authored
This commit adds a new primitive called `ParachainsCache` to manipulate the `Parachains` storage entry in a more convenient way. Then, on top of that, this commit changes the logic of `initialize_para_now` so that it is identical to what is used for initialization of onboarding.
-
- Feb 16, 2022
-
-
lumir-mrkva authored
the comments we're flipped between accepted and rejected events causing confusion, but usage of events is correct
-
- 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:
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:
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:
-
- 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 07, 2022
-
-
Sergey Pepyakin authored
Looks like it is an artifact of prior code and now it is redundant.
-
- Jan 03, 2022
-
-
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
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
-
-
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 21, 2021
-
-
Sergey Pepyakin authored
Basically updates the docs for the paras module.
-
- 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:
-
- 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:
-
- Dec 08, 2021
-
-
Sergey Pepyakin authored
This PR is a part of https://github.com/paritytech/polkadot/issues/3211. This PR prepares ground for the following runtime changes required for PVF pre-checking. Specifically, we do several changes here: 1. We remove `validation_code_at` and `validation_code_hash_at`. Those functions are not used. They were added in the early days with intent to use it later but turned out that we do not need them. 2. We replace `validation_code_hash_at` with just `current_code_hash` for the case of inclusion and candidate checking. 3. We also replace `last_code_upgrade` with a direct query into `FutureCodeHash` and `UpgradeRestrictionSignal`. Those in conjunction should replace the logic that was used for allowing/disallowing upgrades. This requires special attention of the reviewers. 4. Then we remove the machinery required to support those queries. Specifically the code related to `UseCodeAt`. We do not need it since we do not answer the historical queries. However, we still leave all the data on-chain. At some point we may clean it up, but that would be needed to be done with a dedicated migration which can be done as follow-up. 5. Some now irrelevant tests were removed and/or adapted.
-
