- Apr 22, 2024
-
-
Adrian Catangiu authored
Weights::v3 also accounts for PoV weight so we no longer need the SafeCallFilter. All calls are allowed as long as they "fit in the block".
-
Bastian Köcher authored
Basically combines all the recommended calls into one `build_using_defaults()` call or `init_with_defaults()` when there are some custom changes required.
-
Svyatoslav Nikolsky authored
-
- Apr 20, 2024
-
-
Ankan authored
This is the first PR in preparation for https://github.com/paritytech/polkadot-sdk/issues/454. ## Follow ups: - https://github.com/paritytech/polkadot-sdk/pull/3904. - https://github.com/paritytech/polkadot-sdk/pull/3905. Overall changes are documented here (lot more visual
😍 ): https://hackmd.io/@ak0n/454-np-governance [Maybe followup](https://github.com/paritytech/polkadot-sdk/issues/4217) with migration of storage item `VirtualStakers` as a bool or enum in `Ledger`. ## Context We want to achieve a way for a user (`Delegator`) to delegate their funds to another account (`Agent`). Delegate implies the funds are locked in delegator account itself. Agent can act on behalf of delegator to stake directly on Staking pallet. The delegation feature is added to Staking via another pallet `delegated-staking` worked on [here](https://github.com/paritytech/polkadot-sdk/pull/3904). ## Introduces: ### StakingUnchecked Trait As the name implies, this trait allows unchecked (non-locked) mutation of staking ledger. These apis are only meant to be used by other pallets in the runtime and should not be exposed directly to user code path. Also related: https://github.com/paritytech/polkadot-sdk/issues/3888. ### Virtual Bond Allows other pallets to stake via staking pallet while managing the locks on these accounts themselves. Introduces another storage `VirtualStakers` that whitelist these accounts. We also restrict virtual stakers to set reward account as themselves. Since the account has no locks, we cannot support compounding of rewards. Conservatively, we require them to set a separate account different from the staker. Since these are code managed, it should be easy for another pallet to redistribute reward and rebond them. ### Slashes Since there is no actual lock maintained by staking-pallet for virtual stakers, this pallet does not apply any slashes. It is then important for pallets managing virtual stakers to listen to slashing events and apply necessary slashes.
-
- Apr 19, 2024
-
-
Alexandru Vasile authored
This PR stabilizes the txBroadcast API to version 1. Needs from spec: - https://github.com/paritytech/json-rpc-interface-spec/pull/153 - https://github.com/paritytech/json-rpc-interface-spec/pull/154 cc @paritytech/subxt-team --------- Signed-off-by: Alexandru Vasile <[email protected]>
-
Alexandru Vasile authored
This PR stabilizes the txBroadcast API to version 1. Ideally needs: - https://github.com/paritytech/polkadot-sdk/pull/4050 - https://github.com/paritytech/polkadot-sdk/pull/3772 cc @paritytech/subxt-team --------- Signed-off-by: Alexandru Vasile <[email protected]>
-
- Apr 18, 2024
-
-
Alexandru Vasile authored
This PR stabilizes the chainHead API to version 1. Needs: - https://github.com/paritytech/polkadot-sdk/pull/3667 cc @paritytech/subxt-team --------- Signed-off-by: Alexandru Vasile <[email protected]>
-
- Apr 17, 2024
-
-
Muharem Ismailov authored
Introduce `touch` call designed to address operational prerequisites before providing liquidity to a pool. This function ensures that essential requirements, such as the presence of the pool's accounts, are fulfilled. It is particularly beneficial in scenarios where a pool creator removes the pool's accounts without providing liquidity. --------- Co-authored-by: command-bot <>
-
Oliver Tale-Yazdi authored
Preparation for https://github.com/paritytech/polkadot-sdk/pull/3935 Changes: - Add some `default-features = false` for the case that a crate and that dependency both support nostd builds. - Shuffle files around of some benchmarking-only crates. These conditionally disabled the `cfg_attr` for nostd and pulled in libstd. Example [here](https://github.com/ggwpez/zepter/pull/95 ). The actual logic is moved into a `inner.rs` to preserve nostd capability of the crate in case the benchmarking feature is disabled. - Add some `use sp_std::vec` where needed. - Remove some `optional = true` in cases where it was not optional. - Removed one superfluous `cfg_attr(not(feature = "std"), no_std..`. All in all this should be logical no-op. --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]>
-
Muharem Ismailov authored
Introduce `PalletId` as an additional seed parameter for pool's account id derivation. The PR also introduces the `pallet_asset_conversion_ops` pallet with a call to migrate a given pool to thew new account. Additionally `fungibles::lifetime::ResetTeam` and `fungible::lifetime::Refund` traits, to facilitate the migration of pools. --------- Co-authored-by: command-bot <>
-
Sergej Sakac authored
This PR introduces changes enabling the transfer of coretime regions via XCM. TL;DR: There are two primary issues that are resolved in this PR: 1. The `mint` and `burn` functions were not implemented for coretime regions. These operations are essential for moving assets to and from the XCM holding register. 2. The transfer of non-fungible assets through XCM was previously disallowed. This was due to incorrectly benchmarking non-fungible asset transfers via XCM, which led to assigning it a weight of `Weight::Max`, effectively preventing its execution. ### `mint_into` and `burn` implementation This PR addresses the issue with cross-chain transferring regions back to the Coretime chain. Remote reserve transfers are performed by withdrawing and depositing the asset to and from the holding registry. This requires the asset to support burning and minting functionality. This PR adds burning and minting; however, they work a bit differently than usual so that the associated region record is not lost when burning. Instead of removing all the data, burning will set the owner of the region to `None`, and when minting it back, it will set it to an actual value. So, when cross-chain transferring, withdrawing into the registry will remove the region from its original owner, and when depositing it from the registry, it will set its owner to another account This was originally implemented in this PR: #3455, however we decided to move all of it to this single PR (https://github.com/paritytech/polkadot-sdk/pull/3455#discussion_r1547324892) ### Fixes made in this PR - Update the `XcmReserveTransferFilter` on coretime chain since it is meant as a reserve chain for coretime regions. - Update the XCM benchmark to use `AssetTransactor` instead of assuming `pallet-balances` for fungible transfers. - Update the XCM benchmark to properly measure weight consumption for nonfungible reserve asset transfers. ATM reserve transfers via the extrinsic do not work since the weight for it is set to `Weight::max()`. Closes: https://github.com/paritytech/polkadot-sdk/issues/865 --------- Co-authored-by: Branislav Kontur <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: Dónal Murray <[email protected]>
-
- Apr 16, 2024
-
-
Muharem Ismailov authored
Introduce types to define 1:1 balance conversion for different relative asset ids/locations of native asset. Examples: native asset on Asset Hub presented as `VersionedLocatableAsset` type in the context of Relay Chain is ``` { `location`: (0, Parachain(1000)), `asset_id`: (1, Here), } ``` and it's balance should be converted 1:1 by implementations of `ConversionToAssetBalance` trait. --------- Co-authored-by: Branislav Kontur <[email protected]>
-
Oliver Tale-Yazdi authored
Updating the prdoc doc file to be a bit more useful for new contributors and adding a SemVer section. --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]>
-
Oliver Tale-Yazdi authored
Changes: - Saturate in the input validation of he drop history function or pallet-broker. --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]>
-
- Apr 15, 2024
-
-
thiolliere authored
`LiveAsset` is an error to be returned when an asset is not supposed to be live. And `AssetNotLive` is an error to be returned when an asset is supposed to be live, I don't think frozen qualifies as live.
-
Bastian Köcher authored
Part of: https://github.com/paritytech/polkadot-sdk/issues/4107
-
Alexandru Gheorghe authored
As discovered during investigation of https://github.com/paritytech/polkadot-sdk/issues/3314 and https://github.com/paritytech/polkadot-sdk/issues/3673 there are active validators which accidentally might change their network key during restart, that's not a safe operation when you are in the active set because of distributed nature of DHT, so the old records would still exist in the network until they expire 36h, so unless they have a good reason validators should avoid changing their key when they restart their nodes. There is an effort in parallel to improve this situation https://github.com/paritytech/polkadot-sdk/pull/3786 , but those changes are way more intrusive and will need more rigorous testing, additionally they will reduce the time to less than 36h, but the propagation won't be instant anyway, so not changing your network during restart should be the safest way to run your node, unless you have a really good reason to change it. ## Proposal 1. Do not auto-generate the network if the network file does not exist in the provided path. Nodes where the key file does not exist will get the following error: ``` Error: 0: Starting an authorithy without network key in /home/alexggh/.local/share/polkadot/chains/ksmcc3/network/secret_ed25519. This is not a safe operation because the old identity still lives in the dht for 36 hours. Because of it your node might suffer from not being properly connected to other nodes for validation purposes. If it is the first time running your node you could use one of the following methods. 1. Pass --unsafe-force-node-key-generation and make sure you remove it for subsequent node restarts 2. Separetly generate the key with: polkadot key generate-node-key --file <YOUR_PATH_TO_NODE_KEY> ``` 2. Add an explicit parameters for nodes that do want to change their network despite the warnings or if they run the node for the first time. `--unsafe-force-node-key-generation` 3. For `polkadot key generate-node-key` add two new mutually exclusive parameters `base_path` and `default_base_path` to help with the key generation in the same path the polkadot main command would expect it. 4. Modify the installation scripts to auto-generate a key in default path if one was not present already there, this should help with making the executable work out of the box after an instalation. ## Notes Nodes that do not have already the key persisted will fail to start after this change, however I do consider that better than the current situation where they start but they silently hide that they might not be properly connected to their peers. ## TODO - [x] Make sure only nodes that are authorities on producation chains will be affected by this restrictions. - [x] Proper PRDOC, to make sure node operators are aware this is coming. --------- Signed-off-by: Alexandru Gheorghe <[email protected]> Co-authored-by: Dmitry Markin <[email protected]> Co-authored-by: s0me0ne-unkn0wn <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
-
- Apr 13, 2024
-
-
Oliver Tale-Yazdi authored
Changes: - Add pallet-parameters to Rococo to configure the NIS and preimage pallet. - Fix names of expanded dynamic params. Apparently, `to_class_case` removes suffix `s`, and `Nis` becomes `Ni`
😑 . Now using `to_pascal_case`. --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Alessandro Siniscalchi <[email protected]> Co-authored-by: Kian Paimani <[email protected]> Co-authored-by: command-bot <>
-
- Apr 12, 2024
-
-
Branislav Kontur authored
This PR mainly removes `xcm::v3` stuff from `assets-common` to make it more generic and facilitate the transition to newer XCM versions. Some of the implementations here used hard-coded `xcm::v3::Location`, but now it's up to the runtime to configure according to its needs. Additional/consequent changes: - `penpal` runtime uses now `xcm::latest::Location` for `pallet_assets` as `AssetId`, because we don't care about migrations here - it pretty much simplify xcm-emulator integration tests, where we don't need now a lots of boilerplate conversions: ``` v3::Location::try_from(...).expect("conversion works")` ``` - xcm-emulator tests - split macro `impl_assets_helpers_for_parachain` to the `impl_assets_helpers_for_parachain` and `impl_foreign_assets_helpers_for_parachain` (avoids using hard-coded `xcm::v3::Location`)
-
Squirrel authored
1. The `CustomFmtContext::ContextWithFormatFields` enum arm isn't actually used and thus we don't need the enum anymore. 2. We don't do anything with most of the normalized metadata that's created by calling `event.normalized_metadata();` - the `target` we can get from `event.metadata.target()` and level we can get from `event.metadata.level()` - let's just call them direct to simplify things. (`event.metadata()` is just a field call under the hood) Changelog: No functional changes, might run a tad faster with lots of logging turned on. --------- Co-authored-by: Bastian Köcher <[email protected]>
-
Adrian Catangiu authored
# Description Add `transfer_assets_using()` for transferring assets from local chain to destination chain using explicit XCM transfer types such as: - `TransferType::LocalReserve`: transfer assets to sovereign account of destination chain and forward a notification XCM to `dest` to mint and deposit reserve-based assets to `beneficiary`. - `TransferType::DestinationReserve`: burn local assets and forward a notification to `dest` chain to withdraw the reserve assets from this chain's sovereign account and deposit them to `beneficiary`. - `TransferType::RemoteReserve(reserve)`: burn local assets, forward XCM to `reserve` chain to move reserves from this chain's SA to `dest` chain's SA, and forward another XCM to `dest` to mint and deposit reserve-based assets to `beneficiary`. Typically the remote `reserve` is Asset Hub. - `TransferType::Teleport`: burn local assets and forward XCM to `dest` chain to mint/teleport assets and deposit them to `beneficiary`. By default, an asset's reserve is its origin chain. But sometimes we may want to explicitly use another chain as reserve (as long as allowed by runtime `IsReserve` filter). This is very helpful for transferring assets with multiple configured reserves (such as Asset Hub ForeignAssets), when the transfer strictly depends on the used reserve. E.g. For transferring Foreign Assets over a bridge, Asset Hub must be used as the reserve location. # Example usage scenarios ## Transfer bridged ethereum ERC20-tokenX between ecosystem parachains. ERC20-tokenX is registered on AssetHub as a ForeignAsset by the Polkadot<>Ethereum bridge (Snowbridge). Its asset_id is something like `(parents:2, (GlobalConsensus(Ethereum), Address(tokenX_contract)))`. Its _original_ reserve is Ethereum (only we can't use Ethereum as a reserve in local transfers); but, since tokenX is also registered on AssetHub as a ForeignAsset, we can use AssetHub as a reserve. With this PR we can transfer tokenX from ParaA to ParaB while using AssetHub as a reserve. ## Transfer AssetHub ForeignAssets between parachains AssetA created on ParaA but also registered as foreign asset on Asset Hub. Can use AssetHub as a reserve. And all of the above can be done while still controlling transfer type for `fees` so mixing assets in same transfer is supported. # Tests Added integration tests for showcasing: - transferring local (not bridged) assets from parachain over bridge using local Asset Hub reserve, - transferring foreign assets from parachain to Asset Hub, - transferring foreign assets from Asset Hub to parachain, - transferring foreign assets from parachain to parachain using local Asset Hub reserve. --------- Co-authored-by: Branislav Kontur <[email protected]> Co-authored-by: command-bot <>
-
Andrei Sandu authored
Fixes https://github.com/paritytech/polkadot-sdk/issues/3576 Required by elastic scaling collators. Deprecates old API: `candidate_pending_availability`. TODO: - [x] PRDoc --------- Signed-off-by: Andrei Sandu <[email protected]>
-
Xiliang Chen authored
Implements https://github.com/polkadot-fellows/RFCs/issues/82 Allow any parachain to have bidirectional channel with any system parachains Looking for initial feedbacks before continue finish it TODOs: - [x] docs - [x] benchmarks - [x] tests --------- Co-authored-by: joe petrowski <[email protected]> Co-authored-by: Adrian Catangiu <[email protected]>
-
- Apr 11, 2024
-
-
Liam Aharon authored
Completes the removal of `try-runtime-cli` logic from `polkadot-sdk`.
-
s0me0ne-unkn0wn authored
This is phase 2 of async backing enablement for the system parachains on the production networks. ~~It should be merged after polkadot-fellows/runtimes#228 is enacted. After it is released,~~ all the system parachain collators should be upgraded, and then we can proceed with phase 3, which will enable async backing in the runtimes. UPDATE: Indeed, we don't need to wait for the runtime upgrade enactions. The lookahead collator handles the transition by itself, so we can upgrade ASAP. ## Scope of changes Here, we eliminate the dichotomy of having "generic Aura collators" for the production system parachains and "lookahead Aura collators" for the testnet system parachains. Now, all the collators are started as lookahead ones, preserving the logic of transferring from the shell node to Aura-enabled collators for the asset hubs. So, indeed, it simplifies the parachain service logic, which cannot but rejoice.
-
Andrei Sandu authored
fixes https://github.com/paritytech/polkadot-sdk/issues/4067 Also add an early bail out for look ahead collator such that we don't waste time if a CollatorFn is not set. TODO: - [x] add test. - [x] Polkadot System Parachain burn-in. --------- Signed-off-by: Andrei Sandu <[email protected]>
-
- Apr 10, 2024
-
-
Milos Kriz authored
Dear team, dear @NachoPal @joepetrowski @bkchr @ggwpez , This is a retry of #3957, after merging master as advised!, Many thanks! **_Milos_** --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Oliver Tale-Yazdi <[email protected]>
-
PG Herveou authored
Reuse wasmi Module when validating. Prepare the code for 0.32 and the addition of Module::new_unchecked
-
PG Herveou authored
[Weights compare](https://weights.tasty.limo/compare?unit=weight&ignore_errors=true&threshold=10&method=asymptotic&repo=polkadot-sdk&old=master&new=pg%2Fbench_tweaks&path_pattern=substrate%2Fframe%2F**%2Fsrc%2Fweights.rs%2Cpolkadot%2Fruntime%2F*%2Fsrc%2Fweights%2F**%2F*.rs%2Cpolkadot%2Fbridges%2Fmodules%2F*%2Fsrc%2Fweights.rs%2Ccumulus%2F**%2Fweights%2F*.rs%2Ccumulus%2F**%2Fweights%2Fxcm%2F*.rs%2Ccumulus%2F**%2Fsrc%2Fweights.rs) Note: Raw weights change does not mean much here, as this PR reduce the scope of what is benchmarked, they are therefore decreased by a good margin. One should instead print the Schedule using cargo test --features runtime-benchmarks bench_print_schedule -- --nocapture or following the instructions from the [README](https://github.com/paritytech/polkadot-sdk/tree/pg/bench_tweaks/substrate/frame/contracts#schedule) for looking at the Schedule of a specific runtime --------- Co-authored-by: command-bot <>
-
Matteo Muraca authored
Part of #3326 @Kianenigma @ggwpez polkadot address: 12poSUQPtcF1HUPQGY3zZu2P8emuW9YnsPduA4XG3oCEfJVp --------- Signed-off-by: Matteo Muraca <[email protected]> Co-authored-by: ordian <[email protected]>
-
PG Herveou authored
Current benchmarking macro returns a closure with the captured benchmarked code. This can cause issues when the benchmarked code has complex lifetime requirements. This PR updates the existing macro by injecting the recording parameter and invoking the start / stop method around the benchmarked block instead of returning a closure One other added benefit is that you can write this kind of code now as well: ```rust let v; #[block] { v = func.call(); } dbg!(v); // or assert something on v ``` [Weights compare link](https://weights.tasty.limo/compare?unit=weight&ignore_errors=true&threshold=10&method=asymptotic&repo=polkadot-sdk&old=pg/fix-weights&new=pg/bench_update&path_pattern=substrate/frame/**/src/weights.rs,polkadot/runtime/*/src/weights/**/*.rs,polkadot/bridges/modules/*/src/weights.rs,cumulus/**/weights/*.rs,cumulus/**/weights/xcm/*.rs,cumulus/**/src/weights.rs ) --------- Co-authored-by: command-bot <> Co-authored-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Alexander Theißen <[email protected]>
-
Egor_P authored
This PR backports `spec_version`, `node_version` bumps and reordering of the prdocs from the 1.10.0 release branch
-
- Apr 09, 2024
-
-
Dmitry Markin authored
This PR brings the fix https://github.com/paritytech/substrate/pull/13396 to polkadot-sdk. In the past, due to insufficient inbound slot count on polkadot & kusama, this fix led to low peer count. The situation has improved since then after changing the default ratio between `--in-peers` & `--out-peers`. Nevertheless, it's expected that the reported total peer count with this fix is going to be lower than without it. This should be seen as the correct number of working connections reported, as opposed to also reporting already closed connections, and not as lower count of working connections with peers. This PR also removes the peer eviction mechanism, as closed substream detection is a more granular way of detecting peers that stopped syncing with us. The burn-in has been already performed as part of testing these changes in https://github.com/paritytech/polkadot-sdk/pull/3426 . --------- Co-authored-by: Aaro Altonen <[email protected]>
-
Adrian Catangiu authored
We are exploring [allowing this for Kusama](https://github.com/polkadot-fellows/runtimes/pull/261) as well, disallowing on test chains seems unnecessarily limiting.
-
Ankan authored
closes https://github.com/paritytech/polkadot-sdk/issues/3894 Allows Nomination Pool configuration to be set by a custom origin instead of root. In runtimes, we would set this to be `StakingAdmin`, same as for pallet-staking. --------- Co-authored-by: Liam Aharon <[email protected]>
-
Bastian Köcher authored
Also while doing this, move slot duration fetching into the AURA code.
-
- Apr 08, 2024
-
-
Léa Narzis authored
Closes https://github.com/paritytech/polkadot-sdk/issues/3737 --------- Co-authored-by: command-bot <> Co-authored-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
-
Aaro Altonen authored
[litep2p](https://github.com/altonen/litep2p) is a libp2p-compatible P2P networking library. It supports all of the features of `rust-libp2p` that are currently being utilized by Polkadot SDK. Compared to `rust-libp2p`, `litep2p` has a quite different architecture which is why the new `litep2p` network backend is only able to use a little of the existing code in `sc-network`. The design has been mainly influenced by how we'd wish to structure our networking-related code in Polkadot SDK: independent higher-levels protocols directly communicating with the network over links that support bidirectional backpressure. A good example would be `NotificationHandle`/`RequestResponseHandle` abstractions which allow, e.g., `SyncingEngine` to directly communicate with peers to announce/request blocks. I've tried running `polkadot --network-backend litep2p` with a few different peer configurations and there is a noticeable reduction in networking CPU usage. For high load (`--out-peers 200`), networking CPU usage goes down from ~110% to ~30% (80 pp) and for normal load (`--out-peers 40`), the usage goes down from ~55% to ~18% (37 pp). These should not be taken as final numbers because: a) there are still some low-hanging optimization fruits, such as enabling [receive window auto-tuning](https://github.com/libp2p/rust-yamux/pull/176 ), integrating `Peerset` more closely with `litep2p` or improving memory usage of the WebSocket transport b) fixing bugs/instabilities that incorrectly cause `litep2p` to do less work will increase the networking CPU usage c) verification in a more diverse set of tests/conditions is needed Nevertheless, these numbers should give an early estimate for CPU usage of the new networking backend. This PR consists of three separate changes: * introduce a generic `PeerId` (wrapper around `Multihash`) so that we don't have use `NetworkService::PeerId` in every part of the code that uses a `PeerId` * introduce `NetworkBackend` trait, implement it for the libp2p network stack and make Polkadot SDK generic over `NetworkBackend` * implement `NetworkBackend` for litep2p The new library should be considered experimental which is why `rust-libp2p` will remain as the default option for the time being. This PR currently depends on the master branch of `litep2p` but I'll cut a new release for the library once all review comments have been addresses. --------- Signed-off-by: Alexandru Vasile <[email protected]> Co-authored-by: Dmitry Markin <[email protected]> Co-authored-by: Alexandru Vasile <[email protected]> Co-authored-by: Alexandru Vasile <[email protected]>
-
Oliver Tale-Yazdi authored
This MR contains two major changes and some maintenance cleanup. ## 1. Free Standing Pallet Benchmark Runner Closes https://github.com/paritytech/polkadot-sdk/issues/3045, depends on your runtime exposing the `GenesisBuilderApi` (like https://github.com/paritytech/polkadot-sdk/pull/1492). Introduces a new binary crate: `frame-omni-bencher`. It allows to directly benchmark a WASM blob - without needing a node or chain spec. This makes it much easier to generate pallet weights and should allow us to remove bloaty code from the node. It should work for all FRAME runtimes that dont use 3rd party host calls or non `BlakeTwo256` block hashing (basically all polkadot parachains should work). It is 100% backwards compatible with the old CLI args, when the `v1` compatibility command is used. This is done to allow for forwards compatible addition of new commands. ### Example (full example in the Rust docs) Installing the CLI: ```sh cargo install --locked --path substrate/utils/frame/omni-bencher frame-omni-bencher --help ``` Building the Westend runtime: ```sh cargo build -p westend-runtime --release --features runtime-benchmarks ``` Benchmarking the runtime: ```sh frame-omni-bencher v1 benchmark pallet --runtime target/release/wbuild/westend-runtime/westend_runtime.compact.compressed.wasm --all ``` ## 2. Building the Benchmark Genesis State in the Runtime Closes https://github.com/paritytech/polkadot-sdk/issues/2664 This adds `--runtime` and `--genesis-builder=none|runtime|spec` arguments to the `benchmark pallet` command to make it possible to generate the genesis storage by the runtime. This can be used with both the node and the freestanding benchmark runners. It utilizes the new `GenesisBuilder` RA and depends on having https://github.com/paritytech/polkadot-sdk/pull/3412 deployed. ## 3. Simpler args for `PalletCmd::run` You can do three things here to integrate the changes into your node: - nothing: old code keeps working as before but emits a deprecated warning - delete: remove the pallet benchmarking code from your node and use the omni-bencher instead - patch: apply the patch below and keep using as currently. This emits a deprecated warning at runtime, since it uses the old way to generate a genesis state, but is the smallest change. ```patch runner.sync_run(|config| cmd - .run::<HashingFor<Block>, ReclaimHostFunctions>(config) + .run_with_spec::<HashingFor<Block>, ReclaimHostFunctions>(Some(config.chain_spec)) ) ``` ## 4. Maintenance Change - `pallet-nis` get a `BenchmarkSetup` config item to prepare its counterparty asset. - Add percent progress print when running benchmarks. - Dont immediately exit on benchmark error but try to run as many as possible and print errors last. --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Liam Aharon <[email protected]>
-
Egor_P authored
This PR introduces the github flow which will create a release draft automatically when the rc tag is pushed. The flow contains the following steps: - Gets the info about rust version used to build the node - Builds the runtimes using `srtool` - Extracts the info about each runtime - Aggregates the changelog from the prdocs - Creates the release draft containing all the info related to the release (changelog, runtimes, rust versions) - Attaches the runtimes to the draft - Posts the message to the RelEng internal channel to inform that the build is done. Related to the #3295 --------- Co-authored-by: Oliver Tale-Yazdi <[email protected]>
-