Refactor Nomination Pool to support multiple staking strategies #3905

…egation-integration

…let-delegated-staking

…egation-integration

…let-delegated-staking

…egation-integration

…ck this

…egation-integration

…let-delegated-staking

Closes: #3906

Co-authored-by: Bastian Köcher <git@kchr.de>

@kianenigma

Part of #3326 cc @kianenigma @ggwpez @liamaharon polkadot address: 12poSUQPtcF1HUPQGY3zZu2P8emuW9YnsPduA4XG3oCEfJVp --------- Signed-off-by: Matteo Muraca <mmuraca247@gmail.com> Co-authored-by: Liam Aharon <liam.aharon@hotmail.com> Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

The metric records the current protocol_version of the validator that just connected with the peer_map.len(), which contains all peers that connected, that has the effect the metric will be wrong since it won't tell us how many peers we have connected per version because it will always record the total number of peers Fix this by counting by version inside peer_map, additionally because that might be a bit heavier than len(), publish it only on-active leaves. --------- Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>

This PR introduces a refactor of the parachain runtime configuration by consolidating all pallet configurations into a new module named `configs`. This change aims to improve the readability and maintainability of the runtime configuration by centralizing all configuration parameters. ## Changes - **Creation of `configs.rs`**: A new file `configs.rs` has been added under `templates/parachain/runtime/src/`, containing all the runtime configurations previously scattered across `lib.rs`. - **Refactoring of `lib.rs`**: The `lib.rs` file has been significantly slimmed down by removing the inline pallet configurations and importing them from `configs.rs` instead. - **Optimization of Import Statements**: Reorganized import statements to clarify the runtime's dependency structure. ### Benefits - **Improved Readability**: With configurations being centralized, developers can now easily locate and review runtime parameters without navigating through the `lib.rs` file. This refactor does not introduce any changes to the runtime logic but improves the project structure for better development experience. --------- Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

fixes #3886 --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>

) Related Issue #3398 This PR makes permissionless withdrawing the default option, giving any network participant access to claim pool rewards on member's behalf. Of course, members can still opt out of this by setting a `Permissioned` claim permission. Permissionless claiming has been a part of the nomination pool pallet for around 9 months now, with very limited uptake (~4% of total pool members). 1.6% of pool members are using `PermissionlessAll`, strongly suggesting it is not wanted - it is too ambiguous and doesn't provide guidance to claimers. Stakers expect rewards to be claimed on their behalf by default - I have expanded upon this in detail within the [accompanying issue's discussion](#3398). Other protocols have this behaviour, whereby staking rewards are received without the staker having to take any action. From this perspective, permissionless claiming is not intuitive for pool members. As evidence of this, over 150,000 DOT is currently unclaimed on Polkadot, and is growing at a non-linear rate.

Test started failing after 66051ad which enabled approval coalescing, that was expected to happen because the test required an polkadot_parachain_approval_checking_finality_lag of 0, which can't happen with max_approval_coalesce_count greater than 1 because we always delay the approval for no_show_duration_ticks/2 in case we can coalesce it with other approvals. So relax a bit the restrictions, since we don't actually care that the lags are 0, but the fact the finalities are progressing and are not stuck. Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>

Runtime release 1.2 includes bumping of the ParachainHost APIs up to v10, so let's move all the released APIs out of vstaging folder, this PR does not include any logic changes only renaming of the modules and some moving around. Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>

Fix links Related CI failure: https://github.com/paritytech/polkadot-sdk/actions/runs/8455425042/job/23162858534?pr=3859

fix #3921 --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>

Rejoice! Rejoice! The story is nearly over. This PR removes stale migrations, auxiliary structures, and package dependencies, thus making Rococo and Westend totally free from any `im-online`-related stuff. `im-online` still stays a part of the Substrate node and its runtime: https://github.com/paritytech/polkadot-sdk/blob/0d9324847391e902bb42f84f0e76096b1f764efe/substrate/bin/node/runtime/src/lib.rs#L2276-L2277 I'm not sure if it makes sense to remove it from there considering that we're not removing `im-online` from FRAME. Please share your opinion.

derive-syn-parse v0.2.0 came out recently which (finally) adds support for syn 2x. Upgrading to this will remove many of the places where syn 1x was still compiling alongside syn 2x in the polkadot-sdk workspace. This also upgrades `docify` to 0.2.8 which is the version that upgrades derive-syn-pasre to 0.2.0. Additionally, this consolidates the `docify` versions in the repo to all use the latest, and in one case upgrades to the 0.2x syntax where 0.1.x was still being used. --------- Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>

…es (#3927) Fix "double-weights" for extrinsics, use only the ones benchmarked in the runtime. Deprecate extrinsics that don't specify WeightLimit, remove their usage across the repo. --------- Signed-off-by: Adrian Catangiu <adrian@parity.io> Co-authored-by: command-bot <>

When using `schedule_code_upgrade` to change the code of a parachain in the relay chain runtime, we had already fixed to not set the `GoAhead` signal. This was done to not brick any parachain after the upgrade, because they were seeing the signal without having any upgrade prepared. The remaining problem is that the parachain code is only upgraded after a parachain header was enacted, aka the parachain made some progress. However, this is quite complicated if the parachain is bricked (which is the most common scenario why to manually schedule a code upgrade). Thus, this pull request replaces `SetGoAhead` with `UpgradeStrategy` to signal to the logic kind of strategy want to use. The strategies are either `SetGoAheadSignal` or `ApplyAtExpectedBlock`. `SetGoAheadSignal` sets the go ahead signal as before and awaits a parachain block. `ApplyAtExpectedBlock` schedules the upgrade and applies it directly at the `expected_block` without waiting for the parachain to make any kind of progress.

This version includes: - Internal metrics of zombienet (used to benchmark with v2).

Pulling the latest changes from `parity-bridges-common`

This outputs: ``` 2024-04-02 14:36:02.135 ERROR tokio-runtime-worker beefy: 🥩 for session starting at block 21990151 no BEEFY authority key found in store, you must generate valid session keys (https://wiki.polkadot.network/docs/maintain-guides-how-to-validate-polkadot#generating-the-session-keys) ``` error log entry, once every session, for nodes running with `Role::Authority` that have no public BEEFY key in their keystore --------- Co-authored-by: Bastian Köcher <git@kchr.de>

… context and limit connections (#3481) This PR ensures that the chainHead RPC class can be called only from within the same connection context. The chainHead methods are now registered as raw methods. - paritytech/jsonrpsee#1297 The concept of raw methods is introduced in jsonrpsee, which is an async method that exposes the connection ID: The raw method doesn't have the concept of a blocking method. Previously blocking methods are now spawning a blocking task to handle their blocking (ie DB) access. We spawn the same number of tasks as before, however we do that explicitly. Another approach would be implementing a RPC middleware that captures and decodes the method parameters: - #3343 However, that approach is prone to errors since the methods are hardcoded by name. Performace is affected by the double deserialization that needs to happen to extract the subscription ID we'd like to limit. Once from the middleware, and once from the methods itself. This PR paves the way to implement the chainHead connection limiter: - #1505 Registering tokens (subscription ID / operation ID) on the `RpcConnections` could be extended to return an error when the maximum number of operations is reached. While at it, have added an integration-test to ensure that chainHead methods can be called from within the same connection context. Before this is merged, a new JsonRPC release should be made to expose the `raw-methods`: - [x] Use jsonrpsee from crates io (blocked by: paritytech/jsonrpsee#1297) Closes: #3207 cc @paritytech/subxt-team --------- Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io> Co-authored-by: Niklas Adolfsson <niklasadolfsson1@gmail.com>

Working towards migrating the `parity-bridges-common` repo inside `polkadot-sdk`. This PR upgrades some dependencies in order to align them with the versions used in `parity-bridges-common` Related to paritytech/parity-bridges-common#2538

@liamaharon

… of `VersionedMigration` (#3835) closes #1324 #### Problem Currently, it is possible to accidentally use inner unversioned migration instead of `VersionedMigration` since both implement `OnRuntimeUpgrade`. #### Solution With this change, we make it clear that value of `Inner` is not intended to be used directly. It is achieved by bounding `Inner` to new trait `UncheckedOnRuntimeUpgrade`, which has the same interface (except `unchecked_` prefix) as `OnRuntimeUpgrade`. #### `try-runtime` functions Since developers can implement `try-runtime` for `Inner` value in `VersionedMigration` and have custom logic for it, I added the same `try-runtime` functions to `UncheckedOnRuntimeUpgrade`. I looked for a ways to not duplicate functions, but couldn't find anything that doesn't significantly change the codebase. So I would appreciate If you have any suggestions to improve this cc @liamaharon @xlc polkadot address: 16FqwPZ8GRC5U5D4Fu7W33nA55ZXzXGWHwmbnE1eT6pxuqcT --------- Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>

@yrong

This PR includes the following 2 improvements: ## Ethereum Client Author: @yrong ### Original Upstream PRs - Snowfork#123 - Snowfork#125 ### Description The Ethereum client syncs beacon headers as they are finalized, and imports every execution header. When a message is received, it is verified against the import execution header. This is unnecessary, since the execution header can be sent with the message as proof. The recent Deneb Ethereum upgrade made it easier to locate the relevant beacon header from an execution header, and so this improvement was made possible. This resolves a concern @svyatonik had in our initial Rococo PR: #2522 (comment) ## Inbound Queue Author: @yrong ### Original Upstream PR - Snowfork#118 ### Description When the AH sovereign account (who pays relayer rewards) is depleted, the inbound message will not fail. The relayer just will not receive rewards. Both these changes were done by @yrong, many thanks. ❤️ --------- Co-authored-by: claravanstaden <Cats 4 life!> Co-authored-by: Ron <yrong1997@gmail.com> Co-authored-by: Vincent Geddes <vincent@snowfork.com> Co-authored-by: Svyatoslav Nikolsky <svyatonik@gmail.com>

Added `TryFrom<&'a RuntimeString> for &'a str`

Adds implementation for `SortedMembers::add` for _pallet-membership_ benchmarks. --------- Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: command-bot <>

Fixes #3884 (comment) After moving regression tests to benchmarks (#3741) we don't need to filter tests anymore. --------- Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io> Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com> Co-authored-by: Alin Dima <alin@parity.io> Co-authored-by: Andrei Sandu <andrei-mihail@parity.io> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Javier Viola <363911+pepoviola@users.noreply.github.com> Co-authored-by: Serban Iorga <serban@parity.io> Co-authored-by: Adrian Catangiu <adrian@parity.io> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: Alexandru Vasile <60601340+lexnv@users.noreply.github.com> Co-authored-by: Niklas Adolfsson <niklasadolfsson1@gmail.com> Co-authored-by: Dastan <88332432+dastansam@users.noreply.github.com> Co-authored-by: Liam Aharon <liam.aharon@hotmail.com> Co-authored-by: Clara van Staden <claravanstaden64@gmail.com> Co-authored-by: Ron <yrong1997@gmail.com> Co-authored-by: Vincent Geddes <vincent@snowfork.com> Co-authored-by: Svyatoslav Nikolsky <svyatonik@gmail.com> Co-authored-by: Bastian Köcher <info@kchr.de>

…hains (#3879) fixes #3775 Additionally moves the claim queue fetch utilities into `subsystem-util`. TODO: - [x] fix tests - [x] add elastic scaling tests --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>

Closes: #3909

… and `TrailingSetTopicAsId` (#3955) Closes: #1756

#3562) This PR ensure that the distance between any leaf and the finalized block is within a reasonable distance. For a new subscription, the chainHead has to provide all blocks between the leaves of the chain and the finalized block. When the distance between a leaf and the finalized block is large: - The tree route is costly to compute - We could deliver an unbounded number of blocks (potentially millions) (For more details see #3445 (comment)) The configuration of the ChainHead is extended with: - suspend on lagging distance: When the distance between any leaf and the finalized block is greater than this number, the subscriptions are suspended for a given duration. - All active subscriptions are terminated with the `Stop` event, all blocks are unpinned and data discarded. - For incoming subscriptions, until the suspended period expires the subscriptions will immediately receive the `Stop` event. - Defaults to 128 blocks - suspended duration: The amount of time for which subscriptions are suspended - Defaults to 30 seconds cc @paritytech/subxt-team --------- Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io> Co-authored-by: Sebastian Kunert <skunert49@gmail.com>

Enables pov-reclaim on the rococo/westend parachains, part of #3622

Remove `fetch_next_scheduled_on_core` in favor of new wrapper and methods for accessing it. --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>

Step in #3155 Needed for paritytech/eng-automation#6 This PR renames `frame` crate to `polkadot-sdk-frame` as `frame` is not available on crates.io --------- Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

Use of `- >` instead of `- |` workarounds GitLab quirk when it crops collapsed multiline `script:` section commands in its CI job logs. This PR also fixes `- |` based `script:` steps to behave properly after `- >` conversion. Resolves paritytech/ci_cd#972.

CI will be enforcing this with next parity-publish release

Closes #2977 The issue appears to stem from the `aquamarine` crate failing to render diagrams in re-exported crates. e.g. as raised [here](#2977), diagrams would render at `frame_support::traits::Hooks` but not the re-exported doc `frame::traits::Hooks`, even if I added `aquamarine` as a `frame` crate dependency. To resolve this, I followed advice in mersinvald/aquamarine#20 to instead render mermaid diagrams directly using JS by adding an `after-content.js`. --- Also fixes compile warnings, enables `--all-features` and disallows future warnings in CI. --------- Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Bastian Köcher <git@kchr.de>

## Basic example showcasing a migration using the MBM framework This PR has been built on top of #1781 and adds two new example crates to the `examples` pallet ### Changes Made: Added the `pallet-example-mbm` crate: This crate provides a minimal example of a pallet that uses MBM. It showcases a storage migration where values are migrated from a `u32` to a `u64`. --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>

…st `T` (#3708) The XCM builder pattern lets you build xcms like so: ```rust let xcm = Xcm::builder() .withdraw_asset((Parent, 100u128).into()) .buy_execution((Parent, 1u128).into()) .deposit_asset(All.into(), AccountId32 { id: [0u8; 32], network: None }.into()) .build(); ``` All the `.into()` become quite annoying to have to write. I accepted `impl Into<T>` instead of `T` in the generated methods from the macro. Now the previous example can be simplified as follows: ```rust let xcm = Xcm::builder() .withdraw_asset((Parent, 100u128)) .buy_execution((Parent, 1u128)) .deposit_asset(All, [0u8; 32]) .build(); ``` --------- Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: command-bot <> Co-authored-by: Adrian Catangiu <adrian@parity.io>

Part of #226 Related #1833 - Deprecate `CurrencyAdapter` and introduce `FungibleAdapter` - Deprecate `ToStakingPot` and replace usage with `ResolveTo` - Required creating a new `StakingPotAccountId` struct that implements `TypedGet` for the staking pot account ID - Update parachain common utils `DealWithFees`, `ToAuthor` and `AssetsToBlockAuthor` implementations to use `fungible` - Update runtime XCM Weight Traders to use `ResolveTo` instead of `ToStakingPot` - Update runtime Transaction Payment pallets to use `FungibleAdapter` instead of `CurrencyAdapter` - [x] Blocked by #1296, needs the `Unbalanced::decrease_balance` fix

…#3961) ## Running `./polkadot-parachain --chain coretime-kusama` works now: **Parachain genesis state and header** match expected ones from https://gist.github.com/bkontur/f74fc00fd726d09bc7f0f3a9f51ec113?permalink_comment_id=5009857#gistcomment-5009857 ``` 2024-04-03 12:03:58 [Parachain] 🔨 Initializing Genesis block/state (state: 0xc418…889c, header-hash: 0x638c…d050) ... 2024-04-03 12:04:04 [Parachain] 💤 Idle (0 peers), best: #0 (0x638c…d050), finalized #0 (0x638c…d050) ``` **Relaychain genesis state and header** match expected ones: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/explorer/query/0 ``` 2024-04-03 12:03:59 [Relaychain] 🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe) ``` **Full logs:** ``` bparity@bkontur-ThinkPad-P14s-Gen-2i:~/parity/polkadot-sdk$ ./target/debug/polkadot-parachain --chain coretime-kusama 2024-04-03 12:03:52 Polkadot parachain 2024-04-03 12:03:52 ✌️ version 4.0.0-665e3654cec 2024-04-03 12:03:52 ❤️ by Parity Technologies <admin@parity.io>, 2017-2024 2024-04-03 12:03:52 📋 Chain specification: Kusama Coretime 2024-04-03 12:03:52 🏷 Node name: subsequent-quicksand-2382 2024-04-03 12:03:52 👤 Role: FULL 2024-04-03 12:03:52 💾 Database: RocksDb at /home/bparity/.local/share/polkadot-parachain/chains/coretime-kusama/db/full 2024-04-03 12:03:54 Parachain id: Id(1005) 2024-04-03 12:03:54 Parachain Account: 5Ec4AhPakEiNWFbAd26nRrREnaGQZo3uukPDC5xLr6314Dwg 2024-04-03 12:03:54 Is collating: no 2024-04-03 12:03:58 [Parachain] 🔨 Initializing Genesis block/state (state: 0xc418…889c, header-hash: 0x638c…d050) 2024-04-03 12:03:59 [Relaychain] 🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe) 2024-04-03 12:03:59 [Relaychain] 👴 Loading GRANDPA authority set from genesis on what appears to be first startup. 2024-04-03 12:03:59 [Relaychain] 👶 Creating empty BABE epoch changes on what appears to be first startup. 2024-04-03 12:03:59 [Relaychain] 🏷 Local node identity is: 12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd 2024-04-03 12:03:59 [Relaychain] 💻 Operating system: linux 2024-04-03 12:03:59 [Relaychain] 💻 CPU architecture: x86_64 2024-04-03 12:03:59 [Relaychain] 💻 Target environment: gnu 2024-04-03 12:03:59 [Relaychain] 💻 CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz 2024-04-03 12:03:59 [Relaychain] 💻 CPU cores: 4 2024-04-03 12:03:59 [Relaychain] 💻 Memory: 31797MB 2024-04-03 12:03:59 [Relaychain] 💻 Kernel: 5.15.0-101-generic 2024-04-03 12:03:59 [Relaychain] 💻 Linux distribution: Ubuntu 20.04.6 LTS 2024-04-03 12:03:59 [Relaychain] 💻 Virtual machine: no 2024-04-03 12:03:59 [Relaychain] 📦 Highest known block at #0 2024-04-03 12:03:59 [Relaychain] 〽️ Prometheus exporter started at 127.0.0.1:9616 2024-04-03 12:03:59 [Relaychain] Running JSON-RPC server: addr=127.0.0.1:9945, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"] 2024-04-03 12:03:59 [Relaychain] 🏁 CPU score: 1.40 GiBs 2024-04-03 12:03:59 [Relaychain] 🏁 Memory score: 15.42 GiBs 2024-04-03 12:03:59 [Relaychain] 🏁 Disk score (seq. writes): 1.39 GiBs 2024-04-03 12:03:59 [Relaychain] 🏁 Disk score (rand. writes): 690.56 MiBs 2024-04-03 12:03:59 [Parachain] Using default protocol ID "sup" because none is configured in the chain specs 2024-04-03 12:03:59 [Parachain] 🏷 Local node identity is: 12D3KooWAAvNqXn8WPmvnEj36j7HsdbtpRpmWDPT9xtp4CuphvxW 2024-04-03 12:03:59 [Parachain] 💻 Operating system: linux 2024-04-03 12:03:59 [Parachain] 💻 CPU architecture: x86_64 2024-04-03 12:03:59 [Parachain] 💻 Target environment: gnu 2024-04-03 12:03:59 [Parachain] 💻 CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz 2024-04-03 12:03:59 [Parachain] 💻 CPU cores: 4 2024-04-03 12:03:59 [Parachain] 💻 Memory: 31797MB 2024-04-03 12:03:59 [Parachain] 💻 Kernel: 5.15.0-101-generic 2024-04-03 12:03:59 [Parachain] 💻 Linux distribution: Ubuntu 20.04.6 LTS 2024-04-03 12:03:59 [Parachain] 💻 Virtual machine: no 2024-04-03 12:03:59 [Parachain] 📦 Highest known block at #0 2024-04-03 12:03:59 [Parachain] 〽️ Prometheus exporter started at 127.0.0.1:9615 2024-04-03 12:03:59 [Parachain] Running JSON-RPC server: addr=127.0.0.1:9944, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"] 2024-04-03 12:03:59 [Parachain] 🏁 CPU score: 1.40 GiBs 2024-04-03 12:03:59 [Parachain] 🏁 Memory score: 15.42 GiBs 2024-04-03 12:03:59 [Parachain] 🏁 Disk score (seq. writes): 1.39 GiBs 2024-04-03 12:03:59 [Parachain] 🏁 Disk score (rand. writes): 690.56 MiBs 2024-04-03 12:03:59 [Parachain] discovered: 12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd /ip4/192.168.1.100/tcp/30334/ws 2024-04-03 12:03:59 [Relaychain] discovered: 12D3KooWAAvNqXn8WPmvnEj36j7HsdbtpRpmWDPT9xtp4CuphvxW /ip4/192.168.1.100/tcp/30333/ws 2024-04-03 12:03:59 [Relaychain] discovered: 12D3KooWAAvNqXn8WPmvnEj36j7HsdbtpRpmWDPT9xtp4CuphvxW /ip4/172.18.0.1/tcp/30333/ws 2024-04-03 12:03:59 [Parachain] discovered: 12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd /ip4/172.17.0.1/tcp/30334/ws 2024-04-03 12:03:59 [Relaychain] discovered: 12D3KooWAAvNqXn8WPmvnEj36j7HsdbtpRpmWDPT9xtp4CuphvxW /ip4/172.17.0.1/tcp/30333/ws 2024-04-03 12:03:59 [Parachain] discovered: 12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd /ip4/172.18.0.1/tcp/30334/ws 2024-04-03 12:04:00 [Relaychain] 🔍 Discovered new external address for our node: /ip4/178.41.176.246/tcp/30334/ws/p2p/12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd 2024-04-03 12:04:00 [Relaychain] Sending fatal alert BadCertificate 2024-04-03 12:04:00 [Relaychain] Sending fatal alert BadCertificate 2024-04-03 12:04:04 [Relaychain] ⚙️ Syncing, target=#22575321 (7 peers), best: #738 (0x1803…bbef), finalized #512 (0xb9b6…7014), ⬇ 328.5kiB/s ⬆ 102.9kiB/s 2024-04-03 12:04:04 [Parachain] 💤 Idle (0 peers), best: #0 (0x638c…d050), finalized #0 (0x638c…d050), ⬇ 0 ⬆ 0 2024-04-03 12:04:09 [Relaychain] ⚙️ Syncing 169.5 bps, target=#22575322 (8 peers), best: #1586 (0x405b…a8aa), finalized #1536 (0x55d1…fb04), ⬇ 232.3kiB/s ⬆ 55.9kiB/s 2024-04-03 12:04:09 [Parachain] 💤 Idle (0 peers), best: #0 (0x638c…d050), finalized #0 (0x638c…d050), ⬇ 0 ⬆ 0 2024-04-03 12:04:14 [Relaychain] ⚙️ Syncing 168.0 bps, target=#22575323 (8 peers), best: #2426 (0x155f…d083), finalized #2048 (0xede6…f879), ⬇ 235.8kiB/s ⬆ 67.2kiB/s 2024-04-03 12:04:14 [Parachain] 💤 Idle (0 peers), best: #0 (0x638c…d050), finalized #0 (0x638c…d050), ⬇ 0 ⬆ 0 2024-04-03 12:04:19 [Relaychain] ⚙️ Syncing 170.0 bps, target=#22575324 (8 peers), best: #3276 (0x94d8…097e), finalized #3072 (0x0e4c…f587), ⬇ 129.0kiB/s ⬆ 34.0kiB/s ... ``` ## Running `./polkadot-parachain --chain people-kusama` works now: **Parachain genesis state and header** match expected ones from https://gist.github.com/bkontur/f74fc00fd726d09bc7f0f3a9f51ec113?permalink_comment_id=5011798#gistcomment-5011798 ``` 2024-04-04 10:26:24 [Parachain] 🔨 Initializing Genesis block/state (state: 0x023a…2733, header-hash: 0x07b8…2645) ... 2024-04-04 10:26:30 [Parachain] 💤 Idle (0 peers), best: #0 (0x07b8…2645), finalized #0 (0x07b8…2645), ⬇ 0 ⬆ 0 ``` **Relaychain genesis state and header** match expected ones: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/explorer/query/0 ``` 2024-04-04 10:26:25 [Relaychain] 🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe) ``` **Full logs:** ``` bparity@bkontur-ThinkPad-P14s-Gen-2i:~/parity/aaa/polkadot-sdk$ ./target/debug/polkadot-parachain --chain people-kusama 2024-04-04 10:26:18 Polkadot parachain 2024-04-04 10:26:18 ✌️ version 4.0.0-39274bb75fc 2024-04-04 10:26:18 ❤️ by Parity Technologies <admin@parity.io>, 2017-2024 2024-04-04 10:26:18 📋 Chain specification: Kusama People 2024-04-04 10:26:18 🏷 Node name: knotty-flight-5398 2024-04-04 10:26:18 👤 Role: FULL 2024-04-04 10:26:18 💾 Database: RocksDb at /home/bparity/.local/share/polkadot-parachain/chains/people-kusama/db/full 2024-04-04 10:26:21 Parachain id: Id(1004) 2024-04-04 10:26:21 Parachain Account: 5Ec4AhPaYcfBz8fMoPd4EfnAgwbzRS7np3APZUnnFo12qEYk 2024-04-04 10:26:21 Is collating: no 2024-04-04 10:26:24 [Parachain] 🔨 Initializing Genesis block/state (state: 0x023a…2733, header-hash: 0x07b8…2645) 2024-04-04 10:26:25 [Relaychain] 🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe) 2024-04-04 10:26:25 [Relaychain] 👴 Loading GRANDPA authority set from genesis on what appears to be first startup. 2024-04-04 10:26:25 [Relaychain] 👶 Creating empty BABE epoch changes on what appears to be first startup. 2024-04-04 10:26:25 [Relaychain] 🏷 Local node identity is: 12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB 2024-04-04 10:26:25 [Relaychain] 💻 Operating system: linux 2024-04-04 10:26:25 [Relaychain] 💻 CPU architecture: x86_64 2024-04-04 10:26:25 [Relaychain] 💻 Target environment: gnu 2024-04-04 10:26:25 [Relaychain] 💻 CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz 2024-04-04 10:26:25 [Relaychain] 💻 CPU cores: 4 2024-04-04 10:26:25 [Relaychain] 💻 Memory: 31797MB 2024-04-04 10:26:25 [Relaychain] 💻 Kernel: 5.15.0-101-generic 2024-04-04 10:26:25 [Relaychain] 💻 Linux distribution: Ubuntu 20.04.6 LTS 2024-04-04 10:26:25 [Relaychain] 💻 Virtual machine: no 2024-04-04 10:26:25 [Relaychain] 📦 Highest known block at #0 2024-04-04 10:26:25 [Relaychain] 〽️ Prometheus exporter started at 127.0.0.1:9616 2024-04-04 10:26:25 [Relaychain] Running JSON-RPC server: addr=127.0.0.1:9945, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"] 2024-04-04 10:26:25 [Relaychain] 🏁 CPU score: 1.18 GiBs 2024-04-04 10:26:25 [Relaychain] 🏁 Memory score: 15.61 GiBs 2024-04-04 10:26:25 [Relaychain] 🏁 Disk score (seq. writes): 1.49 GiBs 2024-04-04 10:26:25 [Relaychain] 🏁 Disk score (rand. writes): 650.01 MiBs 2024-04-04 10:26:25 [Parachain] Using default protocol ID "sup" because none is configured in the chain specs 2024-04-04 10:26:25 [Parachain] 🏷 Local node identity is: 12D3KooWS2WPQgtiZZYT6bLGjwGcJU7QVd5EeQvb4jHN3NVSWDdj 2024-04-04 10:26:25 [Parachain] 💻 Operating system: linux 2024-04-04 10:26:25 [Parachain] 💻 CPU architecture: x86_64 2024-04-04 10:26:25 [Parachain] 💻 Target environment: gnu 2024-04-04 10:26:25 [Parachain] 💻 CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz 2024-04-04 10:26:25 [Parachain] 💻 CPU cores: 4 2024-04-04 10:26:25 [Parachain] 💻 Memory: 31797MB 2024-04-04 10:26:25 [Parachain] 💻 Kernel: 5.15.0-101-generic 2024-04-04 10:26:25 [Parachain] 💻 Linux distribution: Ubuntu 20.04.6 LTS 2024-04-04 10:26:25 [Parachain] 💻 Virtual machine: no 2024-04-04 10:26:25 [Parachain] 📦 Highest known block at #0 2024-04-04 10:26:25 [Parachain] 〽️ Prometheus exporter started at 127.0.0.1:9615 2024-04-04 10:26:25 [Parachain] Running JSON-RPC server: addr=127.0.0.1:9944, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"] 2024-04-04 10:26:25 [Parachain] 🏁 CPU score: 1.18 GiBs 2024-04-04 10:26:25 [Parachain] 🏁 Memory score: 15.61 GiBs 2024-04-04 10:26:25 [Parachain] 🏁 Disk score (seq. writes): 1.49 GiBs 2024-04-04 10:26:25 [Parachain] 🏁 Disk score (rand. writes): 650.01 MiBs 2024-04-04 10:26:25 [Parachain] discovered: 12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB /ip4/172.17.0.1/tcp/30334/ws 2024-04-04 10:26:25 [Relaychain] discovered: 12D3KooWS2WPQgtiZZYT6bLGjwGcJU7QVd5EeQvb4jHN3NVSWDdj /ip4/172.18.0.1/tcp/30333/ws 2024-04-04 10:26:25 [Relaychain] discovered: 12D3KooWS2WPQgtiZZYT6bLGjwGcJU7QVd5EeQvb4jHN3NVSWDdj /ip4/192.168.1.100/tcp/30333/ws 2024-04-04 10:26:25 [Parachain] discovered: 12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB /ip4/172.18.0.1/tcp/30334/ws 2024-04-04 10:26:25 [Relaychain] discovered: 12D3KooWS2WPQgtiZZYT6bLGjwGcJU7QVd5EeQvb4jHN3NVSWDdj /ip4/172.17.0.1/tcp/30333/ws 2024-04-04 10:26:25 [Parachain] discovered: 12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB /ip4/192.168.1.100/tcp/30334/ws 2024-04-04 10:26:26 [Relaychain] 🔍 Discovered new external address for our node: /ip4/178.41.176.246/tcp/30334/ws/p2p/12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB 2024-04-04 10:26:27 [Relaychain] Sending fatal alert BadCertificate 2024-04-04 10:26:27 [Relaychain] Sending fatal alert BadCertificate 2024-04-04 10:26:30 [Relaychain] ⚙️ Syncing, target=#22588722 (8 peers), best: #638 (0xa9cd…7c30), finalized #512 (0xb9b6…7014), ⬇ 345.6kiB/s ⬆ 108.7kiB/s 2024-04-04 10:26:30 [Parachain] 💤 Idle (0 peers), best: #0 (0x07b8…2645), finalized #0 (0x07b8…2645), ⬇ 0 ⬆ 0 2024-04-04 10:26:35 [Relaychain] ⚙️ Syncing 174.4 bps, target=#22588722 (9 peers), best: #1510 (0xec0b…72f0), finalized #1024 (0x3f17…fd7f), ⬇ 203.1kiB/s ⬆ 45.0kiB/s 2024-04-04 10:26:35 [Parachain] 💤 Idle (0 peers), best: #0 (0x07b8…2645), finalized #0 (0x07b8…2645), ⬇ 0 ⬆ 0 2024-04-04 10:26:40 [Relaychain] ⚙️ Syncing 168.9 bps, target=#22588723 (9 peers), best: #2355 (0xa68b…3a64), finalized #2048 (0xede6…f879), ⬇ 201.6kiB/s ⬆ 47.4kiB/s 2024-04-04 10:26:40 [Parachain] 💤 Idle (0 peers), best: #0 (0x07b8…2645), finalized #0 (0x07b8…2645), ⬇ 0 ⬆ 0 ``` ## TODO - [x] double check `cumulus/polkadot-parachain/chain-specs/coretime-kusama.json` (safeXcmVersion=3) see [comment](#3961 (comment)) - [x] check if ~~`start_generic_aura_node`~~ or `start_generic_aura_lookahead_node` - [x] generate chain-spec for `people-kusama` --------- Co-authored-by: Dónal Murray <donal.murray@parity.io>

…#3974) This function is currently only exposed to runtime-benchmarks, where it should be available in all tests. Also made it available in `std` because this is how `set_block_number` works in FRAME System, however, not sure if it is needed in the latest std/no_std paradigm. --------- Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

The runtime now can provide a number of predefined presets of `RuntimeGenesisConfig` struct. This presets are intended to be used in different deployments, e.g.: `local`, `staging`, etc, and should be included into the corresponding chain-specs. Having `GenesisConfig` presets in runtime allows to fully decouple node from runtime types (the problem is described in #1984). **Summary of changes:** - The `GenesisBuilder` API was adjusted to enable this functionality (and provide better naming - #150): ```rust fn preset_names() -> Vec<PresetId>; fn get_preset(id: Option<PresetId>) -> Option<serde_json::Value>; //`None` means default fn build_state(value: serde_json::Value); pub struct PresetId(Vec<u8>); ``` - **Breaking change**: Old `create_default_config` method was removed, `build_config` was renamed to `build_state`. As a consequence a node won't be able to interact with genesis config for older runtimes. The cleanup was made for sake of API simplicity. Also IMO maintaining compatibility with old API is not so crucial. - Reference implementation was provided for `substrate-test-runtime` and `rococo` runtimes. For rococo new [`genesis_configs_presets`](https://github.com/paritytech/polkadot-sdk/blob/3b41d66b97c5ff0ec4a1989da5ffd8b9f3f588e3/polkadot/runtime/rococo/src/genesis_config_presets.rs#L530) module was added and is used in `GenesisBuilder` [_presets-related_](https://github.com/paritytech/polkadot-sdk/blob/3b41d66b97c5ff0ec4a1989da5ffd8b9f3f588e3/polkadot/runtime/rococo/src/lib.rs#L2462-L2485) methods. - The `chain-spec-builder` util was also improved and allows to ([_doc_](https://github.com/paritytech/polkadot-sdk/blob/3b41d66b97c5ff0ec4a1989da5ffd8b9f3f588e3/substrate/bin/utils/chain-spec-builder/src/lib.rs#L19)): - list presets provided by given runtime (`list-presets`), - display preset or default config provided by the runtime (`display-preset`), - build chain-spec using named preset (`create ... named-preset`), - The `ChainSpecBuilder` is extended with [`with_genesis_config_preset_name`](https://github.com/paritytech/polkadot-sdk/blob/3b41d66b97c5ff0ec4a1989da5ffd8b9f3f588e3/substrate/client/chain-spec/src/chain_spec.rs#L447) method which allows to build chain-spec using named preset provided by the runtime. Sample usage on the node side [here](https://github.com/paritytech/polkadot-sdk/blob/2caffaae803e08a3d5b46c860e8016da023ff4ce/polkadot/node/service/src/chain_spec.rs#L404). Implementation of #1984. fixes: #150 part of: #25 --------- Co-authored-by: Sebastian Kunert <skunert49@gmail.com> Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

## Verify Coretime Westend: ``` polkadot-parachain --chain=coretime-westend --tmp --relay-chain-rpc-url wss://rpc.ibp.network/westend --reserved-only --reserved-nodes /dns/boot-node.helikon.io/tcp/9420/p2p/12D3KooWFBPartM873MNm1AmVK3etUz34cAE9A9rwPztPno2epQ3 polkadot-parachain --chain=coretime-westend --tmp --relay-chain-rpc-url wss://rpc.ibp.network/westend --reserved-only --reserved-nodes /dns/boot-node.helikon.io/tcp/9422/wss/p2p/12D3KooWFBPartM873MNm1AmVK3etUz34cAE9A9rwPztPno2epQ3 ``` People Westend: ``` polkadot-parachain --chain=/path/to/people-westend.json --tmp --relay-chain-rpc-url wss://rpc.ibp.network/westend --reserved-only --reserved-nodes /dns/boot-node.helikon.io/tcp/9520/p2p/12D3KooWHhZk21Wzvsd3Un1Cp63diXqr6idbG1MEiUWaitUZuX4c polkadot-parachain --chain=/path/to/people-westend.json --tmp --relay-chain-rpc-url wss://rpc.ibp.network/westend --reserved-only --reserved-nodes /dns/boot-node.helikon.io/tcp/9522/wss/p2p/12D3KooWHhZk21Wzvsd3Un1Cp63diXqr6idbG1MEiUWaitUZuX4c ``` Thanks.

On top of #3879 I've also moved the previous test where we ensure multiple cores per para doesn't break non elastic parachains. --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> Co-authored-by: Javier Viola <363911+pepoviola@users.noreply.github.com>

Reverts #3816

Properly account for #3302, cc #3984.

Closes #3986 --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

This PR adds a check that `max_timeslices > 0` and errors if not. It also adds a test for this behaviour and cleans up some misleading docs.

This PR introduces a dedicated module for benchmarks within the parachain runtime. By segregating benchmarks into their own module, we achieve a cleaner project structure and improved readability, facilitating easier maintenance and updates. ### Key Changes: - **New Benchmarks Module**: A new file `benchmarks.rs` is added, encapsulating the benchmarking code for various pallets. - **Refactoring `lib.rs`**: The main runtime library file (`lib.rs`) has been updated to reflect the extraction of benchmark definitions. By moving these definitions to `benchmarks.rs`, we reduce clutter in `lib.rs`, streamlining the runtime's core logic and configuration. ### Benefits of This Refactoring: - **Focused Benchmarking**: Developers can now easily locate and modify benchmarks without navigating through the core runtime logic, enabling targeted performance improvements. - **Cleaner Codebase**: Segregating benchmarks from the main runtime logic helps maintain a clean, well-organized codebase, simplifying navigation and maintenance. - **Scalability**: As the parachain evolves, adding or updating benchmarks becomes more straightforward, supporting scalability and adaptability of the runtime. ### Summary of Changes: - Created `benchmarks.rs` to house the benchmarking suite. - Streamlined `lib.rs` by removing the inlined benchmark definitions and linking to the new benchmarks module. --------- Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>

Signed-off-by: divdeploy <chenguangxue@outlook.com>

Bumps [h2](https://github.com/hyperium/h2) from 0.3.24 to 0.3.26. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/hyperium/h2/releases">h2's releases</a>.</em></p> <blockquote> <h2>v0.3.26</h2> <h2>What's Changed</h2> <ul> <li>Limit number of CONTINUATION frames for misbehaving connections.</li> </ul> <p>See <a href="https://seanmonstar.com/blog/hyper-http2-continuation-flood/">https://seanmonstar.com/blog/hyper-http2-continuation-flood/</a> for more info.</p> <h2>v0.3.25</h2> <h2>What's Changed</h2> <ul> <li>perf: optimize header list size calculations by <a href="https://github.com/Noah-Kennedy"><code>@Noah-Kennedy</code></a> in <a href="https://redirect.github.com/hyperium/h2/pull/750">hyperium/h2#750</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/hyperium/h2/compare/v0.3.24...v0.3.25">https://github.com/hyperium/h2/compare/v0.3.24...v0.3.25</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/hyperium/h2/blob/v0.3.26/CHANGELOG.md">h2's changelog</a>.</em></p> <blockquote> <h1>0.3.26 (April 3, 2024)</h1> <ul> <li>Limit number of CONTINUATION frames for misbehaving connections.</li> </ul> <h1>0.3.25 (March 15, 2024)</h1> <ul> <li>Improve performance decoding many headers.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/hyperium/h2/commit/357127e279c06935830fe2140378312eac801494"><code>357127e</code></a> v0.3.26</li> <li><a href="https://github.com/hyperium/h2/commit/1a357aaefc7243fdfa9442f45d90be17794a4004"><code>1a357aa</code></a> fix: limit number of CONTINUATION frames allowed</li> <li><a href="https://github.com/hyperium/h2/commit/5b6c9e0da092728d702dff3607626aafb7809d77"><code>5b6c9e0</code></a> refactor: cleanup new unused warnings (<a href="https://redirect.github.com/hyperium/h2/issues/757">#757</a>)</li> <li><a href="https://github.com/hyperium/h2/commit/3a798327211345b9b2bf797e2e4f3aca4e0ddfee"><code>3a79832</code></a> v0.3.25</li> <li><a href="https://github.com/hyperium/h2/commit/94e80b1c72bec282bb5d13596803e6fb341fec4c"><code>94e80b1</code></a> perf: optimize header list size calculations (<a href="https://redirect.github.com/hyperium/h2/issues/750">#750</a>)</li> <li>See full diff in <a href="https://github.com/hyperium/h2/compare/v0.3.24...v0.3.26">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=h2&package-manager=cargo&previous-version=0.3.24&new-version=0.3.26)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/paritytech/polkadot-sdk/network/alerts). </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Defines a runtime api for `pallet-broker` for getting the current price of a core if there is an ongoing sale. Closes: #3413 --------- Co-authored-by: Bastian Köcher <git@kchr.de>

…metadata (#3976) Decrements `total_deposit` when collection metadata is cleared in `pallet-nfts` and `pallet-uniques`.

1. Add `#[doc(no_inline)]` to frame umbrella crate re-exports that eventually resolve to `frame_support_procedural` so docs don't look like the screenshot below and instead link to the proper `frame-support` docs. <img width="1512" alt="Screenshot 2024-04-05 at 20 05 01" src="https://github.com/paritytech/polkadot-sdk/assets/16665596/a41daa4c-ebca-44a4-9fea-f9f336314e13"> 2. Remove `"Rust-Analyzer Users: "` prefix from `frame_support_procedural` doc comments, since these doc comments are visible in the web documentation and possible to stumble upon especially when navigating from the frame umbrella crate. Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

I don't think there are any more releases to the 0.2.x versions, so best we're on the 0.3.x release. No change on the benchmarks, fast local time is still just as fast as before: new version bench: ``` fast_local_time time: [30.551 ns 30.595 ns 30.668 ns] ``` old version bench: ``` fast_local_time time: [30.598 ns 30.646 ns 30.723 ns] ``` --------- Co-authored-by: Bastian Köcher <git@kchr.de>

Signed-off-by: hongkuang <liurenhong@outlook.com>

With Coretime enabled we can no longer assume there is a static 1:1 mapping between core index and para id. This mapping should be obtained from the scheduler/claimqueue on block by block basis. This PR modifies `para_id()` (from `CoreState`) to return the scheduled `ParaId` for occupied cores and removes its usages in the code. Closes #3948 --------- Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com>

The stream was just used to communicate from the validator the peer reports back to the gossip engine. Internally the gossip engine just forwards these reports to the networking engine. So, we can just do this directly. The reporting stream was also pumped [in the worker behind the engine](https://github.com/paritytech/polkadot-sdk/blob/9d6261892814fa27c97881c0321c008d7340b54b/substrate/client/consensus/beefy/src/worker.rs#L939). This means if there was a lot of data incoming over the engine, the reporting stream was almost never processed and thus, it could have started to grow and we have seen issues around this. Partly Closes: #3945

…t more robust (#4016) Improves `adder-collator` to also compute the parachain velocity. The velocity is defined as number of parachain blocks progressing per relay chain block. In this test we're asserting that the elastic parachain always progresses by 3 blocks per RCB, while the non-elastic parachain progresses normally - 1 block per RCB. --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> Co-authored-by: ordian <write@reusable.software>

… import message (#4021) Sometimes you need to debug some issues just by the logs and reconstruct what happened. In these scenarios it would be nice to know if a block was imported as best block, and what it parent was. So here I propose to change the output of the informant to this: ``` 2024-04-05 20:38:22.004 INFO ⋮substrate: [Parachain] ✨ Imported #18 (0xe7b3…4555 -> 0xbd6f…ced7) 2024-04-05 20:38:24.005 INFO ⋮substrate: [Parachain] ✨ Imported #19 (0xbd6f…ced7 -> 0x4dd0…d81f) 2024-04-05 20:38:24.011 INFO ⋮substrate: [jobless-children-5352] 🌟 Imported #42 (0xed2e…27fc -> 0x718f…f30e) 2024-04-05 20:38:26.005 INFO ⋮substrate: [Parachain] ✨ Imported #20 (0x4dd0…d81f -> 0x6e85…e2b8) 2024-04-05 20:38:28.004 INFO ⋮substrate: [Parachain] 🌟 Imported #21 (0x6e85…e2b8 -> 0xad53…2a97) 2024-04-05 20:38:30.004 INFO ⋮substrate: [Parachain] 🌟 Imported #22 (0xad53…2a97 -> 0xa874…890f) ``` --------- Co-authored-by: Bastian Köcher <git@kchr.de>

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 <oliver.tale-yazdi@parity.io>

This MR contains two major changes and some maintenance cleanup. ## 1. Free Standing Pallet Benchmark Runner Closes #3045, depends on your runtime exposing the `GenesisBuilderApi` (like #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 #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 #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 <oliver.tale-yazdi@parity.io> Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>

[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](libp2p/rust-yamux#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 <alexandru.vasile@parity.io> Co-authored-by: Dmitry Markin <dmitry@markin.tech> Co-authored-by: Alexandru Vasile <60601340+lexnv@users.noreply.github.com> Co-authored-by: Alexandru Vasile <alexandru.vasile@parity.io>

…eric hash parameters (#3953) Closes #3737 --------- Co-authored-by: command-bot <> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Bastian Köcher <git@kchr.de>

…egation-integration

…let-delegated-staking

…egation-integration

…let-delegated-staking

…egation-integration

…let-delegated-staking

…egation-integration

Co-authored-by: Gonçalo Pestana <g6pestana@gmail.com>

Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: georgepisaltu <52418509+georgepisaltu@users.noreply.github.com>

…let-delegated-staking

…egation-integration

…let-delegated-staking

…egation-integration

…let-delegated-staking

…egation-integration

…let-delegated-staking

…egation-integration

…=westend --target_dir=polkadot --pallet=pallet_nomination_pools

…m/paritytech/polkadot-sdk into HEAD

…=dev --target_dir=substrate --pallet=pallet_nomination_pools

…egation-integration

…agent.

…egation-integration

Co-authored-by: jimwfs <169986508+jimwfs@users.noreply.github.com>

…4512) Replace usage of deprecated `substrate_rpc_client::ChildStateApi::storage_keys` with `substrate_rpc_client::ChildStateApi::storage_keys_paged`. Required for successful scraping of Aleph Zero state.

@muraca

) As per #3326, removes pallet::getter macro usage from pallet-fast-unstake. The syntax `StorageItem::<T, I>::get()` should be used instead. cc @muraca --------- Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>

Implements #4429 Collators only need to maintain the implicit view for the paraid they are collating on. In this case, bypass prospective-parachains entirely. It's still useful to use the GetMinimumRelayParents message from prospective-parachains for validators, because the data is already present there. This enables us to entirely remove the subsystem from collators, which consumed resources needlessly Aims to resolve #4167 TODO: - [x] fix unit tests

…on test

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor Nomination Pool to support multiple staking strategies #3905

Refactor Nomination Pool to support multiple staking strategies #3905

Commits on Apr 3, 2024

Commits on Apr 4, 2024

Commits on Apr 5, 2024

Commits on Apr 9, 2024

Commits on Apr 10, 2024

Commits on Apr 11, 2024

Commits on Apr 12, 2024

Commits on Apr 16, 2024

Commits on Apr 17, 2024

Commits on Apr 18, 2024

Commits on Apr 19, 2024

Commits on Apr 20, 2024

Commits on Apr 22, 2024

Commits on Apr 24, 2024

Commits on Apr 25, 2024

Commits on Apr 26, 2024

Commits on May 2, 2024

Commits on May 7, 2024

Commits on May 13, 2024

Commits on May 15, 2024

Commits on May 16, 2024

Commits on May 17, 2024

Commits on May 21, 2024

Commits on May 22, 2024