[pull] master from paritytech:master #17

return the repo/ref as .sha creates detached branch and doesn't let to push back the changes

Install with `--locked` to try to fix the CI. Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Close #5677 I made a nit when I moved this code: https://github.com/paritytech/polkadot-sdk/blob/v1.14.0-rc1/substrate/client/service/src/lib.rs#L379-#L385 in #4792 Thus: - (ip.is_loopback(), RpcMethods::Auto) -> allow unsafe - (!ip.is_loopback(), RpcMethods::Auto) -> deny unsafe --------- Co-authored-by: ggwpez <ggwpez@users.noreply.github.com>

Trivial and self explanatory changes. Wrapping err such as these makes debugging harder as well as does not really give any meaningful reason why this happened. The increment of consumer can genuinely fail if there are no providers (account does not exist) or it reaches max consumers. In both cases, its better to propagate the actual System err.

### Description: * Adds `DeprecationStatusIR` enum to sp_metadata_ir. Deprecation info for simple items. * Adds `DeprecationInfoIR` enum to sp_metadata_ir. It is a deprecation info for an enums/errors/calls. Contains `DeprecationStatusIR`. Denotes full/partial deprecation of the type or its variants/calls * Adds `deprecation_info` field to - `RuntimeApiMetadataIR` - `RuntimeApiMethodMetadataIR` - `StorageEntryMetadataIR` - `PalletConstantMetadataIR` - `PalletCallMetadataIR` - `PalletMetadataIR` - `PalletEventMetadataIR` - `PalletErrorMetadataIR` ### Testing done: - Unit tests to check whether or not correct `note`/`since` texts are getting propagated to the metadata structs. - UI test to check for error message in case of incorrect attribute usage. There's also some test updates to make sure that deprecation attributes are getting propagated to the relevant structs. see: #4098, Solution: A ### Examples of produced deprecation info metadata They can be found in: - Tests for `frame-support` - hackmd link https://hackmd.io/@Zett98/Bys0YgbcR --------- Co-authored-by: GitHub Action <action@github.com> Co-authored-by: command-bot <> Co-authored-by: Bastian Köcher <git@kchr.de>

This is part of the work to further optimize the approval subsystems, if you want to understand the full context start with reading #4849 (comment), # Description This PR contain changes to make possible the run of single approval-voting instance on a worker thread, so that it can be instantiated by the approval-voting-parallel subsystem. This does not contain any functional changes it just decouples the subsystem from the subsystem Context and introduces more specific trait dependencies for each function instead of all of them requiring a context. This change can be merged independent of the followup PRs. --------- Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io> Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com>

Fixes: paritytech/ci_cd#1034

…s. (#5509) Proxies are possible in the runtimes for Kusama and Polkadot but this functionality was not previously available on testnets. Closes #5453. Proxies can now be used on `coretime-rococo`, `coretime-westend`, `people-rococo` and `people-westend` in the same way as they can be on Kusama and Polkadot chains. The exact same proxies are configured as the production runtimes for the respective system parachains.

…ent weights (#2704) Add emulated test cases for the coretime chain. This tests the calls sent across the `CoretimeInterface` and ensures the weights are sufficient.

fix #5683

…#5675) This adds an API method `balance_of`, corresponding to the [BALANCE](https://www.evm.codes/#31?fork=cancun) EVM opcode. In `Ext`, `balance` and `balance_of` are internally routed through the same new `account_balance` method: `balance` is technically the same as `balance_of` with the caller address. This avoids duplicating all the tests and avoids a small inefficiency (in theory, `balance` directly call `balance_of` however this introduces a round trip of converting the target address to a H160 and back). --------- Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com> Signed-off-by: xermicus <cyrill@parity.io> Co-authored-by: command-bot <>

This was necessary when we needed to compact encode a `Option<T::Balance>` which is no longer necessary. The storage deposit limit is now non optional. This is just a left over. Also got rid of the `T::Hash: IsType<H256>`. We use `keccak256` instead of the generic hash function everywhere now.

PR adds `cargo-check-each-crate-macos` job in GitHub actions. It'll work some time in both CI systems until it's moved entirely to GHA. cc paritytech/ci_cd#1021

The salt argument should be optional to allow create1 equivalent calls. --------- Signed-off-by: xermicus <cyrill@parity.io>

Discovered a bug in the migrations pallet while debugging paritytech/try-runtime-cli#90. It only occurs when a single MBM is configured - hence it did not happen when Ajuna Network tried it... Changes: - Check len of the tuple before accessing its nth_id - Make nth_id return `None` on unary tuples and n>0 --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: ggwpez <ggwpez@users.noreply.github.com>

# Description Adding support for send polkadot native assets(PNA) to Ethereum network through snowbridge. Asset with location in view of AH Including: - Relay token `(1,Here)` - Native asset `(0,[PalletInstance(instance),GenereIndex(index)])` managed by Assets Pallet - Native asset of Parachain `(1,[Parachain(paraId)])` managed by Foreign Assets Pallet The original PR in Snowfork#128 which has been internally reviewed by Snowbridge team. # Notes - This feature depends on the companion solidity change in Snowfork/snowbridge#1155. Currently register PNA is only allowed from [sudo](https://github.com/Snowfork/polkadot-sdk/blob/46cb3528cd8cd1394af2335a6907d7ab8647717a/bridges/snowbridge/pallets/system/src/lib.rs#L621), so it's actually not enabled. Will require another runtime upgrade to make the call permissionless together with upgrading the Gateway contract. - To make things easy multi-hop transfer(i.e. sending PNA from Ethereum through AH to Destination chain) is not support ed in this PR. For this case user can switch to 2-phases transfer instead. --------- Co-authored-by: Clara van Staden <claravanstaden64@gmail.com> Co-authored-by: Alistair Singh <alistair.singh7@gmail.com> Co-authored-by: Vincent Geddes <117534+vgeddes@users.noreply.github.com> Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>

Apparently changing the GH Token made it lose permission... error from here: https://github.com/paritytech/polkadot-sdk/actions/runs/10815755374/job/30005387859 From this list it looks like comment creation should be allowed by adding issues to the list: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token

### Issue It was impossible to benchmark the pallet_treasury when `SpendOrigin = frame_support::traits::NeverEnsureOrigin<u64>;` was specified. ### Done - [x] Use `weight = 0` for all extrinsics that are un-callable with no `SpendOrigin`. - [x] Fix benchmarks for extrinsics requiring a Spend even if `SpendOrigin = frame_support::traits::NeverEnsureOrigin<u64>;` --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Bastian Köcher <info@kchr.de> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Introduces a trait for verifying existence proofs in the runtime. The trait is implemented for the 16 patricia merkle tree and the binary tree. --------- Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com> Co-authored-by: command-bot <>

Setup auto incremented asset id to `50_000_000` for trust backed assets. In order to align with Polkadot/Kusama Asset Hub - polkadot-fellows/runtimes#414 The next closes existing assets IDs in Rococo is `69_696_969`, in Westend is `88_228_866`. ### Migration **Stakeholders**: all clients providing asset creation functionality on Westend/Rococo Asset Hub This change does not break the API but introduces a new constraint. It implements an auto-incremented ID strategy for Trust-Backed Assets (50 pallet instance indexes on both networks), starting at ID 50,000,000. Each new asset must be created with an ID that is one greater than the last asset created. The next ID can be fetched from the `NextAssetId` storage item of the assets pallet. An empty `NextAssetId` storage item indicates no constraint on the next asset ID and can serve as a feature flag for this release.

the range should always contain at least 2 values for the benchmark to work closes #5680

Preflight reusable workflow - aggregated workflow to perform all preliminary jobs It currently includes: - check changed files - `set-image` (and runner) job - useful variables

- This will ensure that a correct product name (Polkadot/Cumulus/Substrate) is referenced in license headers. - Closes paritytech/license-scanner#49

Add new `CI` machinery to smoke test the `parachain-template-node` using zombienet-sdk. Thx! --------- Co-authored-by: Przemek Rzad <przemek@parity.io> Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com> Co-authored-by: rzadp <roopert7@gmail.com> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

# Description Follow-up to #5469 and mostly covering #5333. The primary change here is that syncing strategy is no longer created inside of syncing engine, instead syncing strategy is an argument of syncing engine, more specifically it is an argument to `build_network` that most downstream users will use. This also extracts addition of request-response protocols outside of network construction, making sure they are physically not present when they don't need to be (imagine syncing strategy that uses none of Substrate's protocols in its implementation for example). This technically allows to completely replace syncing strategy with whatever strategy chain might need. There will be at least one follow-up PR that will simplify `SyncingStrategy` trait and other public interfaces to remove mentions of block/state/warp sync requests, replacing them with generic APIs, such that strategies where warp sync is not applicable don't have to provide dummy method implementations, etc. ## Integration Downstream projects will have to write a bit of boilerplate calling `build_polkadot_syncing_strategy` function to create previously default syncing strategy. ## Review Notes Please review PR through individual commits rather than the final diff, it will be easier that way. The changes are mostly just moving code around one step at a time. # Checklist * [x] My PR includes a detailed description as outlined in the "Description" and its two subsections above. * [x] My PR follows the [labeling requirements]( https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/CONTRIBUTING.md#Process ) of this project (at minimum one label for `T` required) * External contributors: ask maintainers to put the right label on your PR. * [x] I have made corresponding changes to the documentation (if applicable)

When `SpendOrigin` doesn't return any `succesful_origin`, it doesn't mean that `RejectOrigin` will do the same. Thus, this pr fixes a potential wrong benchmarked weight for when `SpendOrigin` is set to e.g. `NeverOrigin`.

@kianenigma

As raised by @kianenigma in sam0x17/macro_magic#15, this PR adds the support for generics while using `derive_impl`. This can then be used in conjunction with `FliteFrameSystem` being defined [here](https://github.com/kianenigma/flite) as ```diff +#[derive_impl(FliteFrameSystem<Configuration>)] impl frame_system::Config for Runtime { type Block = Block; // .. Rest can be removed } ``` --------- Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

@s0me0ne-unkn0wn

Related to #4882 cc: @s0me0ne-unkn0wn ```sh RUST_LOG=info,zombie=debug cargo test -p polkadot-zombienet-sdk-tests smoke::coretime_revenue::coretime_revenue_test --features zombie-metadata -- --exact ``` --- _Update_: This pr is now ready for review. `warp-sync` failing test are not related. --------- Co-authored-by: Dmitry Sinyavin <dmitry.sinyavin@parity.io> Co-authored-by: s0me0ne-unkn0wn <48632512+s0me0ne-unkn0wn@users.noreply.github.com>

… buffer length (#5743) Instead of error out if the provided output buffer is smaller than what we want to write, we can just write what fits into the output buffer instead. We already write back the actual bytes written to the in-out pointer, so contracts can check it anyways. This in turn introduces the benefit of allowing contracts to implicitly request only a portion of the returned data from calls and incantations. Which is especially beneficial for YUL as the `call` family opcodes have a return data size argument and this change removes the need to work around it in contract code. --------- Signed-off-by: xermicus <cyrill@parity.io>

PR removes cargo check job that runs on osx runner from gitlab and moves `cargo-check-each-crate-macos` job to be required cc paritytech/ci_cd#1037

## Issue #4858 ## Description This PR removes `libp2p::request_response::OutboundFailure` from `substrate/client/network/sync/src/engine.rs`. This way, the dependency with the library `libp2p` is removed from `sc-network-sync`. --------- Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: command-bot <> Co-authored-by: Dmitry Markin <dmitry@markin.tech> Co-authored-by: Alexandru Vasile <60601340+lexnv@users.noreply.github.com>

Fix tests: - minimal_template_block_production_test - parachain_template_block_production_test

This will make sure that when uploading new code that the declared static memory fits within a defined limit. We apply different limits to code and data. Reason is that code will consume much more memory per byte once decoded during lazy execution. This PR: 1) Remove the MaxCodeLen from the `Config` to we maintain tight control over it. 2) Defines a single `STATIC_MEMORY_BYTES` knob that limits the maximum decoded size. 3) Enforces them only on upload but not on execution so we can raise them later. 4) Adapt the worst case calculation in `integrity_check`. 5) Bumps the max stack depth from 5 to 10 as this will still fit within our memory envelope. 6) The memory limit per contract is now a cool 1MB that can be spent on data or code. 7) Bump PolkaVM for good measure 8) The blob is limited to 256kb which is just a sanity check to not even try parsing very big inputs. --------- Co-authored-by: Cyrill Leutwiler <cyrill@parity.io>

Bumps [soketto](https://github.com/paritytech/soketto) from 0.7.1 to 0.8.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/paritytech/soketto/releases">soketto's releases</a>.</em></p> <blockquote> <h2>v0.8.0</h2> <h2>0.8.0</h2> <ul> <li>[changed] move to rust 2021 <a href="https://redirect.github.com/paritytech/soketto/pull/56">#56</a></li> <li>[changed] Replace sha-1 v0.9 with sha1 v0.10 <a href="https://redirect.github.com/paritytech/soketto/pull/62">#62</a></li> <li>[changed] Update hyper requirement from v0.14 to v1.0 <a href="https://redirect.github.com/paritytech/soketto/pull/99">#99</a></li> <li>[changed] Update base64 requirement from 0.13 to 0.22 <a href="https://redirect.github.com/paritytech/soketto/pull/97">#97</a></li> <li>[changed] Bump MSRV to 1.71.1.</li> <li>[fixed] doc typo on Client resource field <a href="https://redirect.github.com/paritytech/soketto/pull/97">#79</a></li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/paritytech/soketto/blob/master/CHANGELOG.md">soketto's changelog</a>.</em></p> <blockquote> <h2>0.8.0</h2> <ul> <li>[changed] move to rust 2021 <a href="https://redirect.github.com/paritytech/soketto/pull/56">#56</a></li> <li>[changed] Replace sha-1 v0.9 with sha1 v0.10 <a href="https://redirect.github.com/paritytech/soketto/pull/62">#62</a></li> <li>[changed] Update hyper requirement from v0.14 to v1.0 <a href="https://redirect.github.com/paritytech/soketto/pull/99">#99</a></li> <li>[changed] Update base64 requirement from 0.13 to 0.22 <a href="https://redirect.github.com/paritytech/soketto/pull/97">#97</a></li> <li>[changed] Bump MSRV to 1.71.1.</li> <li>[fixed] doc typo on Client resource field <a href="https://redirect.github.com/paritytech/soketto/pull/97">#79</a></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/paritytech/soketto/commit/7fee76678b7d08b21f5081de0f9041c7c9c1afdd"><code>7fee766</code></a> Merge pull request <a href="https://redirect.github.com/paritytech/soketto/issues/100">#100</a> from paritytech/chore-release-soketto-0.8</li> <li><a href="https://github.com/paritytech/soketto/commit/f392c852b2ad7d6146accb5b75989dd60cbeaed1"><code>f392c85</code></a> chore: release v0.8.0</li> <li><a href="https://github.com/paritytech/soketto/commit/6f31ad11e742a3e83ec9b9b75644b2e0242f5da7"><code>6f31ad1</code></a> Merge pull request <a href="https://redirect.github.com/paritytech/soketto/issues/88">#88</a> from paritytech/dependabot/github_actions/actions/chec...</li> <li><a href="https://github.com/paritytech/soketto/commit/322240516dc844abd5deb9d740df3b16614c08b9"><code>3222405</code></a> Merge pull request <a href="https://redirect.github.com/paritytech/soketto/issues/99">#99</a> from paritytech/chore-update-hyper</li> <li><a href="https://github.com/paritytech/soketto/commit/afe56f5d26687b60b038522e7f10277adfd73c14"><code>afe56f5</code></a> Merge pull request <a href="https://redirect.github.com/paritytech/soketto/issues/97">#97</a> from paritytech/dependabot/cargo/base64-0.22</li> <li><a href="https://github.com/paritytech/soketto/commit/420216aad917301e3513905ad55f60ffc068a4e0"><code>420216a</code></a> chore(deps): update hyper v1.0</li> <li><a href="https://github.com/paritytech/soketto/commit/050d44ba45cd800877729b649a898ac483fbff97"><code>050d44b</code></a> Update base64 requirement from 0.21 to 0.22</li> <li><a href="https://github.com/paritytech/soketto/commit/3d65c54d37162a57c8401f6428b3f9213bed8fd7"><code>3d65c54</code></a> Merge pull request <a href="https://redirect.github.com/paritytech/soketto/issues/95">#95</a> from paritytech/dependabot/cargo/env_logger-0.11.1</li> <li><a href="https://github.com/paritytech/soketto/commit/153cd94dfcdcded2e0f6857ef8623d14ca4cc91a"><code>153cd94</code></a> Update env_logger requirement from 0.10.0 to 0.11.1</li> <li><a href="https://github.com/paritytech/soketto/commit/26a2fc647258345da8cdefe3f8d9f0a01553eb46"><code>26a2fc6</code></a> Merge pull request <a href="https://redirect.github.com/paritytech/soketto/issues/87">#87</a> from kayabaNerve/master</li> <li>Additional commits viewable in <a href="https://github.com/paritytech/soketto/compare/v0.7.1...v0.8.0">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=soketto&package-manager=cargo&previous-version=0.7.1&new-version=0.8.0)](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) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Bastian Köcher <git@kchr.de>

When running XCM emulated tests and seeing the logs with `RUST_LOG=xcm` or `RUST_LOG=xcm=trace`, it's sometimes a bit hard to figure out the chain where the logs are coming from. I added a log whenever `execute_with` is called, to know the chain which makes the following logs. Looks like so: <img width="1499" alt="Screenshot 2024-09-13 at 20 14 13" src="https://github.com/user-attachments/assets/a31d7aa4-11d1-4d3e-9a65-86f38347c880"> There are already log targets for when UMP, DMP and HRMP messages are being processed. To see them, you have to use the log targets `ump`, `dmp`, and `hrmp` respectively. So `RUST_LOG=xcm,ump,dmp,hrmp` would let you see every log. I prefixed the targets with `xcm::` so you can get all the relevant logs just by filtering by `xcm`. You can always use the whole target to see just the messages being processed. These logs showed the message as an array of bytes, I made them show a hexadecimal string instead since that's easier to copy in case you want to decode it or use it in another tool. They look like this now: <img width="1499" alt="Screenshot 2024-09-13 at 20 17 15" src="https://github.com/user-attachments/assets/5abf4a97-1ea7-4832-b3b0-d54c54905d1a"> The HRMP and UMP ones are very similar.

Co-authored-by: command-bot <>

# Description Adjust the PoV response size to the default values used in the substrate. Fixes #5503 ## Integration The changes shouldn't impact downstream projects since we are only increasing the limit. ## Review Notes You can't see it from the changes, but it affects all protocols that use the `POV_RESPONSE_SIZE` constant. - Protocol::ChunkFetchingV1 - Protocol::ChunkFetchingV2 - Protocol::CollationFetchingV1 - Protocol::CollationFetchingV2 - Protocol::PoVFetchingV1 - Protocol::AvailableDataFetchingV1 ## Increasing timeouts https://github.com/paritytech/polkadot-sdk/blob/fae15379cba0c876aa16c77e11809c83d1db8f5c/polkadot/node/network/protocol/src/request_response/mod.rs#L126-L129 I assume the current PoV request timeout is set to 1.2s to handle 5 consecutive requests during a 6s block. This setting does not relate to the PoV response size. I see no reason to change the current timeouts after adjusting the response size. However, we should consider networking speed limitations if we want to increase the maximum PoV size to 10 MB. With the number of parallel requests set to 10, validators will need the following networking speeds: - 5 MB PoV: at least 42 MB/s, ideally 50 MB/s. - 10 MB PoV: at least 84 MB/s, ideally 100 MB/s. The current required speed of 50 MB/s aligns with the 62.5 MB/s specified [in the reference hardware requirements](https://wiki.polkadot.network/docs/maintain-guides-how-to-validate-polkadot#reference-hardware). Increasing the PoV size to 10 MB may require a higher networking speed. --------- Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com>

) # Description When we start a node with connections to external RPC servers (as a minimal node), we lack metrics around how many individual calls we're doing to the remote RPC servers and their duration. This PR adds metrics that measure durations of each RPC call made by the minimal nodes, and implicitly how many calls there are. Closes #5409 Closes #5689 ## Integration Node operators should be able to track minimal node metrics and decide appropriate actions according to how the metrics are interpreted/felt. The added metrics can be observed by curl'ing the prometheus metrics endpoint for the ~relaychain~ parachain (it was changed based on the review). The metrics are represented by ~`polkadot_parachain_relay_chain_rpc_interface`~ `relay_chain_rpc_interface` namespace (I realized lining up `parachain_relay_chain` in the same metric might be confusing :). Excerpt from the curl: ``` relay_chain_rpc_interface_bucket{method="chain_getBlockHash",chain="rococo_local_testnet",le="0.001"} 15 relay_chain_rpc_interface_bucket{method="chain_getBlockHash",chain="rococo_local_testnet",le="0.004"} 23 relay_chain_rpc_interface_bucket{method="chain_getBlockHash",chain="rococo_local_testnet",le="0.016"} 23 relay_chain_rpc_interface_bucket{method="chain_getBlockHash",chain="rococo_local_testnet",le="0.064"} 23 relay_chain_rpc_interface_bucket{method="chain_getBlockHash",chain="rococo_local_testnet",le="0.256"} 24 relay_chain_rpc_interface_bucket{method="chain_getBlockHash",chain="rococo_local_testnet",le="1.024"} 24 relay_chain_rpc_interface_bucket{method="chain_getBlockHash",chain="rococo_local_testnet",le="4.096"} 24 relay_chain_rpc_interface_bucket{method="chain_getBlockHash",chain="rococo_local_testnet",le="16.384"} 24 relay_chain_rpc_interface_bucket{method="chain_getBlockHash",chain="rococo_local_testnet",le="65.536"} 24 relay_chain_rpc_interface_bucket{method="chain_getBlockHash",chain="rococo_local_testnet",le="+Inf"} 24 relay_chain_rpc_interface_sum{method="chain_getBlockHash",chain="rococo_local_testnet"} 0.11719075 relay_chain_rpc_interface_count{method="chain_getBlockHash",chain="rococo_local_testnet"} 24 ``` ## Review Notes The way we measure durations/hits is based on `HistogramVec` struct which allows us to collect timings for each RPC client method called from the minimal node., It can be extended to measure the RPCs against other dimensions too (status codes, response sizes, etc). The timing measuring is done at the level of the `relay-chain-rpc-interface`, in the `RelayChainRpcClient` struct's method 'request_tracing'. A single entry point for all RPC requests done through the relay-chain-rpc-interface. The requests durations will fall under exponential buckets described by start `0.001`, factor `4` and count `9`. --------- Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>

…5736) Bumps the known_good_semver group with 2 updates in the / directory: [clap](https://github.com/clap-rs/clap) and [syn](https://github.com/dtolnay/syn). Updates `clap` from 4.5.11 to 4.5.13 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/clap-rs/clap/releases">clap's releases</a>.</em></p> <blockquote> <h2>v4.5.13</h2> <h2>[4.5.13] - 2024-07-31</h2> <h3>Fixes</h3> <ul> <li><em>(derive)</em> Improve error message when <code>#[flatten]</code>ing an optional <code>#[group(skip)]</code></li> <li><em>(help)</em> Properly wrap long subcommand descriptions in help</li> </ul> <h2>v4.5.12</h2> <h2>[4.5.12] - 2024-07-31</h2> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/clap-rs/clap/blob/master/CHANGELOG.md">clap's changelog</a>.</em></p> <blockquote> <h2>[4.5.13] - 2024-07-31</h2> <h3>Fixes</h3> <ul> <li><em>(derive)</em> Improve error message when <code>#[flatten]</code>ing an optional <code>#[group(skip)]</code></li> <li><em>(help)</em> Properly wrap long subcommand descriptions in help</li> </ul> <h2>[4.5.12] - 2024-07-31</h2> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/clap-rs/clap/commit/d222ae4cb62d08b4d8f635aa80ddb3c880b82e6e"><code>d222ae4</code></a> chore: Release</li> <li><a href="https://github.com/clap-rs/clap/commit/a8abcb40c5f2628bfa671adf61a090a1bbfbcfa2"><code>a8abcb4</code></a> docs: Update changelog</li> <li><a href="https://github.com/clap-rs/clap/commit/2690e1bdb19df3e4dde7a50fc33b14a3bf6f0b8a"><code>2690e1b</code></a> Merge pull request <a href="https://redirect.github.com/clap-rs/clap/issues/5621">#5621</a> from shannmu/dynamic_valuehint</li> <li><a href="https://github.com/clap-rs/clap/commit/7fd7b3e40bd835070253432accf4076bb020beda"><code>7fd7b3e</code></a> feat(clap_complete): Support to complete custom value of argument</li> <li><a href="https://github.com/clap-rs/clap/commit/fc6aaca52b42d0e4ae13805e7480cbb05f63a0ca"><code>fc6aaca</code></a> Merge pull request <a href="https://redirect.github.com/clap-rs/clap/issues/5638">#5638</a> from epage/cargo</li> <li><a href="https://github.com/clap-rs/clap/commit/631e54bc715ed2fa53d8457dc273a25b92d3b354"><code>631e54b</code></a> docs(cookbook): Style cargo plugin</li> <li><a href="https://github.com/clap-rs/clap/commit/6fb49d08bb2acfbc2f2aa5f717ccd4a4018ca872"><code>6fb49d0</code></a> Merge pull request <a href="https://redirect.github.com/clap-rs/clap/issues/5636">#5636</a> from gibfahn/styles_const</li> <li><a href="https://github.com/clap-rs/clap/commit/6f215eee98c4f73099b0ede2ac62ba019ada24ce"><code>6f215ee</code></a> refactor(styles): make styles example use a const</li> <li><a href="https://github.com/clap-rs/clap/commit/bbb2e6fdde1c724e39c2f2616332310252c12ab8"><code>bbb2e6f</code></a> test: Add test case for completing custom value of argument</li> <li><a href="https://github.com/clap-rs/clap/commit/999071c46dca0367d93f66ecd97b2e3507963284"><code>999071c</code></a> fix: Change <code>visible</code> to <code>hidden</code></li> <li>Additional commits viewable in <a href="https://github.com/clap-rs/clap/compare/clap_complete-v4.5.11...clap_complete-v4.5.13">compare view</a></li> </ul> </details> <br /> Updates `syn` from 2.0.65 to 2.0.77 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/dtolnay/syn/releases">syn's releases</a>.</em></p> <blockquote> <h2>2.0.77</h2> <ul> <li>Support parsing <code>Expr::Tuple</code> in non-"full" mode (<a href="https://redirect.github.com/dtolnay/syn/issues/1727">#1727</a>)</li> </ul> <h2>2.0.76</h2> <ul> <li>Enforce that tail call <code>become</code> keyword is followed by an expression (<a href="https://redirect.github.com/dtolnay/syn/issues/1725">#1725</a>)</li> </ul> <h2>2.0.75</h2> <ul> <li>Automatically fill in missing turbofish when printing ExprPath and other paths in expression position (<a href="https://redirect.github.com/dtolnay/syn/issues/1722">#1722</a>)</li> </ul> <h2>2.0.74</h2> <ul> <li>Fix <em>"temporary is dropped and runs the destructor for type `impl Iterator`"</em> regression affecting certain use of <code>Generics</code> iterator methods (<a href="https://redirect.github.com/dtolnay/syn/issues/1719">#1719</a>)</li> </ul> <h2>2.0.73</h2> <ul> <li>Support parsing unnamed C varargs within function pointer types (<a href="https://redirect.github.com/dtolnay/syn/issues/1711">#1711</a>)</li> <li>Improve synthesized error message on unexpected tokens at the end of the expected contents of a delimited group (<a href="https://redirect.github.com/dtolnay/syn/issues/1713">#1713</a>)</li> <li>Support parsing unstable tail call syntax (<a href="https://redirect.github.com/dtolnay/syn/issues/1714">#1714</a>, <a href="https://redirect.github.com/rust-lang/rust/issues/112788">rust-lang/rust#112788</a>)</li> <li>Add <a href="https://docs.rs/syn/2.0.73/syn/enum.Fields.html#method.members"><code>Fields::members</code></a> iterator (<a href="https://redirect.github.com/dtolnay/syn/issues/1716">#1716</a>, thanks <a href="https://github.com/Fancyflame"><code>@Fancyflame</code></a>)</li> </ul> <h2>2.0.72</h2> <ul> <li>Parse <code>use<'a, T></code> precise capturing bounds (<a href="https://redirect.github.com/dtolnay/syn/issues/1707">#1707</a>, thanks <a href="https://github.com/compiler-errors"><code>@compiler-errors</code></a>)</li> </ul> <h2>2.0.71</h2> <ul> <li>Do not require mutable borrow in Punctuated::get() (<a href="https://redirect.github.com/dtolnay/syn/issues/1706">#1706</a>, thanks <a href="https://github.com/lemunozm"><code>@lemunozm</code></a>)</li> </ul> <h2>2.0.70</h2> <ul> <li>Improve parenthesization of closures, jumps, ranges, chained comparisons, and let (<a href="https://redirect.github.com/dtolnay/syn/issues/1694">#1694</a>, <a href="https://redirect.github.com/dtolnay/syn/issues/1695">#1695</a>, <a href="https://redirect.github.com/dtolnay/syn/issues/1698">#1698</a>, <a href="https://redirect.github.com/dtolnay/syn/issues/1699">#1699</a>, <a href="https://redirect.github.com/dtolnay/syn/issues/1700">#1700</a>)</li> </ul> <h2>2.0.69</h2> <ul> <li>Correctly parenthesize labeled loops inside a break value (<a href="https://redirect.github.com/dtolnay/syn/issues/1692">#1692</a>)</li> <li>Add <code>Punctuated::get</code> and <code>get_mut</code> (<a href="https://redirect.github.com/dtolnay/syn/issues/1693">#1693</a>)</li> </ul> <h2>2.0.68</h2> <ul> <li>Improve panic location when <code>parse_quote!</code> parses invalid syntax (<a href="https://redirect.github.com/dtolnay/syn/issues/1690">#1690</a>, thanks <a href="https://github.com/stepancheg"><code>@stepancheg</code></a>)</li> <li>More efficient peek implementation for <code>Group</code> and <code>Lifetime</code> (<a href="https://redirect.github.com/dtolnay/syn/issues/1687">#1687</a>)</li> </ul> <h2>2.0.67</h2> <ul> <li>Produce more accurate error message locations for errors located at the end of a nested group (<a href="https://redirect.github.com/dtolnay/syn/issues/1679">#1679</a>, <a href="https://redirect.github.com/dtolnay/syn/issues/1680">#1680</a>)</li> <li>Support peeking <code>LitCStr</code> in ParseStream::peek (<a href="https://redirect.github.com/dtolnay/syn/issues/1682">#1682</a>)</li> </ul> <h2>2.0.66</h2> <ul> <li>Allow braced structs when parsing ExprLet (<a href="https://redirect.github.com/dtolnay/syn/issues/1671">#1671</a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/dtolnay/syn/commit/6232266b0b522ca144eb2910a51670eb9685bca5"><code>6232266</code></a> Release 2.0.77</li> <li><a href="https://github.com/dtolnay/syn/commit/97acbf0ffae4fa17f971cc15cd0586ea94bc7423"><code>97acbf0</code></a> Merge pull request <a href="https://redirect.github.com/dtolnay/syn/issues/1727">#1727</a> from dtolnay/exprparen</li> <li><a href="https://github.com/dtolnay/syn/commit/a3b5a5c10942c2dfc42f7c7dbd80d2d6672dbcb9"><code>a3b5a5c</code></a> Support parsing Expr::Tuple in derive</li> <li><a href="https://github.com/dtolnay/syn/commit/3c24f576d7e1655da51bac4a6f80ded898fb9840"><code>3c24f57</code></a> Run upload-artifact action regardless of previous step failure</li> <li><a href="https://github.com/dtolnay/syn/commit/78608a3ebe0bab46d0791e91f35b9966a92962df"><code>78608a3</code></a> Upload CI Cargo.lock for reproducing failures</li> <li><a href="https://github.com/dtolnay/syn/commit/ef3e9c6dde79be7590fc90278772663ca31c1a73"><code>ef3e9c6</code></a> Release 2.0.76</li> <li><a href="https://github.com/dtolnay/syn/commit/8f7365ff9685c8ca9527c2de409204179a3efcdf"><code>8f7365f</code></a> Merge pull request <a href="https://redirect.github.com/dtolnay/syn/issues/1725">#1725</a> from dtolnay/tailcall</li> <li><a href="https://github.com/dtolnay/syn/commit/6cddd9ea714fe034466b4f02d3f7abb484c65ea0"><code>6cddd9e</code></a> Make tail call expr mandatory</li> <li><a href="https://github.com/dtolnay/syn/commit/d1746fe29d18ca704ed285844c365a14a77e8757"><code>d1746fe</code></a> Release 2.0.75</li> <li><a href="https://github.com/dtolnay/syn/commit/b6936825a637376dd7584653e13776034759d3fd"><code>b693682</code></a> Merge pull request <a href="https://redirect.github.com/dtolnay/syn/issues/1722">#1722</a> from dtolnay/exprpath</li> <li>Additional commits viewable in <a href="https://github.com/dtolnay/syn/compare/2.0.65...2.0.77">compare view</a></li> </ul> </details> <br /> 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 <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: command-bot <>

# Description Fix #5074 which missed the runtime migration to initialize channels of the bridge. --------- Co-authored-by: Adrian Catangiu <adrian@parity.io>

When using the relay chain though a `Arc<dyn RelayChainInterface>` there is no way to call arbitrary runtime apis. Both implementations of that trait allow this, so it feels natural to expose this functionality in the trait. This PR adds a `call_runtime_api` method to RelayChainInterface trait, and a separate function also named `call_runtime_api` which allows the caller to specify the input and output types, as opposed to having to encode them. This generic function cannot be part of the trait because a `dyn Trait` object cannot have generic methods. --------- Co-authored-by: Bastian Köcher <git@kchr.de>

@lexnv

…uests are sent (#5774) This PR is cherry-picked from #5663 so that I can maintain a smaller polkadot-sdk diff downstream sooner than later. cc @lexnv @dmitry-markin --------- Co-authored-by: Alexandru Vasile <60601340+lexnv@users.noreply.github.com> Co-authored-by: Dmitry Markin <dmitry@markin.tech>

# Description This PR just makes some minor adjustments to the README. The main goal of it is to consistently refer to the Polkadot SDK as such, without a hyphen. I noticed some other minor inconsistencies, so I fixed those while I was at it

It is a first step for switching to the `frame-omni-bencher` for CI. This PR includes several changes related to generating chain specs plus: - [x] pallet `assigned_slots` fix missing `#[serde(skip)]` for phantom - [x] pallet `paras_inherent` benchmark fix - cherry-picked from #5688 - [x] migrates `get_preset` to the relevant runtimes - [x] fixes Rococo genesis presets - does not work https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7317249 - [x] fixes Rococo benchmarks for CI - [x] migrate westend genesis - [x] remove wococo stuff Closes: #5680 ## Follow-ups - Fix for frame-omni-bencher #5655 - Enable new short-benchmarking CI - #5706 - Remove gitlab pipelines for short benchmarking - refactor all Cumulus runtimes to use `get_preset` - #5704 - #5705 - #5700 - [ ] Backport to the stable --------- Co-authored-by: command-bot <> Co-authored-by: ordian <noreply@reusable.software>

Use `sp_core::Bytes` as `payload` to encode the values correctly as `hex` string.

The genesis state is currently partially provided via `OverlayedChanges`, but these changes are reset by the runtime after the first repetition, causing the second repitition to use an invalid genesis state. Changes: - Provide the genesis state as a `Storage` without any `OverlayedChanges` to make it work correctly with repetitions. - Add `--genesis-builder-preset` option to use different genesis preset names. - Improve error messages. --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: ggwpez <ggwpez@users.noreply.github.com> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: Branislav Kontur <bkontur@gmail.com>

…5787) ## Description Details and rationale explained here: #5657 (comment) Fixes: #5657 --------- Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>

Partially implements #5048 - adds a core selection runtime API to cumulus and a generic way of configuring it for a parachain - modifies the slot based collator to utilise the claim queue and the generic core selection What's left to be implemented (in a follow-up PR): - add the UMP signal for core selection into the parachain-system pallet View the RFC for more context: polkadot-fellows/RFCs#103 --------- Co-authored-by: command-bot <>

Bumps [k256](https://github.com/RustCrypto/elliptic-curves) from 0.13.3 to 0.13.4. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/RustCrypto/elliptic-curves/commit/5ac8f5d77f11399ff48d87b0554935f6eddda342"><code>5ac8f5d</code></a> k256 v0.13.4</li> <li><a href="https://github.com/RustCrypto/elliptic-curves/commit/613cbafd63763c579922ad2b79fa041b4a0dde50"><code>613cbaf</code></a> k256: add support for non-32-byte BIP340 signatures (<a href="https://redirect.github.com/RustCrypto/elliptic-curves/issues/1041">#1041</a>)</li> <li><a href="https://github.com/RustCrypto/elliptic-curves/commit/3787e4cd5b4223cae8bed05d087d6ff2f1d9430b"><code>3787e4c</code></a> k256 v0.13.3</li> <li>See full diff in <a href="https://github.com/RustCrypto/elliptic-curves/compare/k256/v0.13.3...k256/v0.13.4">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=k256&package-manager=cargo&previous-version=0.13.3&new-version=0.13.4)](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) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Co-authored-by: command-bot <>

This PR adds the EVM chain ID to Config as well as a corresponding runtime API so contracts can query it. Related issue: paritytech/revive#44 --------- Signed-off-by: xermicus <cyrill@parity.io> Co-authored-by: command-bot <>

# Description Closes #5722 Added an implementation of the `try_append` functionality which is present on the other storage map types but currently missing from StorageNMap. --------- Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>

# Description * This is part of [issue 5242](#5242), specifically getting solochain to use `#[frame::runtime]` * Furthermore, reinforced the convention of `Template` instead of `TemplateModule` ## Integration * Should be integrated into the `solochain` template and documentation ## Review Notes * Refactored `solochain` template from [construct_runtime!](https://paritytech.github.io/polkadot-sdk/master/frame_support/macro.construct_runtime.html) to [#[runtime]](https://paritytech.github.io/polkadot-sdk/master/frame_support/attr.runtime.html). * AFAIU `Template` is our new convention, and preferred over `TemplateModule`. # Out of scope * The [#[runtime]](https://paritytech.github.io/polkadot-sdk/master/frame_support/attr.runtime.html) documentation is still very rudimentary, and should ideally be expanded to explain the macro, both what it does and the input options. * Furthermore, suggest update [#[runtime]](https://paritytech.github.io/polkadot-sdk/master/frame_support/attr.runtime.html) documentation to replace `#[crate::runtime]` with `#[frame_support::runtime]` --------- Co-authored-by: Jan-Jan <111935+Jan-Jan@users.noreply.github.com> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com> Co-authored-by: command-bot <>

…ust (#5563) On messages Ethereum -> Polkadot Asset Hub: whether they are a token transfer or a `Transact` for registering new token, make sure to handle unspent fees, rather than trapping them. This PR deposits them to Snowbridge's sovereign account on Asset Hub. --------- Co-authored-by: command-bot <>

# Description A fix for a border condition introduced with new feature #5201. A malicious relayer could spam the Ethereum client with sync committee updates that have already been imported for the period. This PR adds a storage item to track the last imported sync committee period, so that subsequent irrelevant updates are not free. Original PR: Snowfork#172 ## Integration Downstream projects are not affected. Relayers will not be able to spam the Ethereum client with irrelevant sync committee updates for free. ## Review Notes Adds a storage item to track the last free sync committee update period, so that duplicate imports are not free. --------- Co-authored-by: Adrian Catangiu <adrian@parity.io>

- New and updated vars - New runner vars - Runners rename (see paritytech/ci_cd#1039) --------- Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Fix `parachain-template-test` (bump `zombienet` version). Thx!

This PR primarily fixes the issue with `zombienet-bridges-0001-asset-transfer-works` (see: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7404903). The PR looks large, but most of the changes involve splitting `LaneId` into `LegacyLaneId` and `HashedLaneId`. All pallets now use `LaneId` as a generic parameter. The actual bridging pallets are now backward compatible and work with actual **substrate-relay v1.6.10**, which does not even known anything about permissionless lanes or the new pallet changes. ## Important - [x] added migration for `pallet_bridge_relayers` and `RewardsAccountParams` change order of params, which generates different accounts ## Deployment follow ups - [ ] fix monitoring for `at_{}_relay_{}_reward_for_msgs_from_{}_on_lane_{}` - [ ] check sovereign reward accounts - because of changed `RewardsAccountParams` - [ ] deploy another messages instances for permissionless lanes - on BHs or AHs? - [ ] return back `open_and_close_bridge_works` for another `pallet-bridge-messages` instance --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Adrian Catangiu <adrian@parity.io> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

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

# MBM try-runtime support This MR adds support to the try-runtime trait such that the try-runtime-CLI will be able to support MBM testing [here](paritytech/try-runtime-cli#90). It mainly adds two feature-gated hooks to the `SteppedMigration` hook to facilitate testing. These hooks are named `pre_upgrade` and `post_upgrade` and have the same signature and implications as for single-block migrations. ## Integration To make use of this in your Multi-Block-Migration, just implement the two new hooks and test pre- and post-conditions in them: ```rust #[cfg(feature = "try-runtime")] fn pre_upgrade() -> Result<Vec<u8>, frame_support::sp_runtime::TryRuntimeError> { // ... } #[cfg(feature = "try-runtime")] fn post_upgrade(prev: Vec<u8>) -> Result<(), frame_support::sp_runtime::TryRuntimeError> { // ... } ``` You may return an error or panic in these functions to indicate failure. This will then show up in the try-runtime-CLI and can be used in CI for testing. Changes: - Adds `try-runtime` gated methods `pre_upgrade` and `post_upgrade` on `SteppedMigration` - Adds `try-runtime` gated methods `nth_pre_upgrade` and `nth_post_upgrade` on `SteppedMigrations` - Modifies `pallet_migrations` implementation to run pre_upgrade and post_upgrade steps at the appropriate times, and panic in the event of migration failure. --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Signed-off-by: georgepisaltu <george.pisaltu@parity.io> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: claravanstaden <claravanstaden64@gmail.com> Co-authored-by: ggwpez <ggwpez@users.noreply.github.com> Co-authored-by: georgepisaltu <george.pisaltu@parity.io>

…transfers (#5660) This change adds the required validation for stronger UX guarantees when using `InitiateReserveWithdraw` or `InitiateTeleport` XCM instructions. Execution of the instructions will fail if the local chain is not configured to trust the "destination" or "reserve" chain as a reserve/trusted-teleporter for the provided "assets". With this change, misuse of `InitiateReserveWithdraw`/`InitiateTeleport` fails on origin with no overall side-effects, rather than failing on destination (with side-effects to origin's assets issuance). The commit also makes the same validations for pallet-xcm transfers, and adds regression tests. --------- Signed-off-by: Adrian Catangiu <adrian@parity.io> Co-authored-by: Branislav Kontur <bkontur@gmail.com>

This PR introduces 2 new syscalls: `return_data_size` and `return_data_copy`, resembling the semantics of the EVM `RETURNDATASIZE` and `RETURNDATACOPY` opcodes. The ownership of `ExecReturnValue` (the return data) has moved to the `Frame`. This allows implementing the new contract API functionality in ext with no additional copies. Returned data is passed via contract memory, memory is (will be) metered, hence the amount of returned data can not be statically known, so we should avoid storing copies of the returned data if we can. By moving the ownership of the exectuables return value into the `Frame` struct we achieve this. A zero-copy implementation of those APIs would be technically possible without that internal change by making the callsite in the runtime responsible for moving the returned data into the frame after any call. However, resetting the stored output needs to be handled in ext, since plain transfers will _not_ affect the stored return data (and we don't want to handle this special call case inside the `runtime` API). This has drawbacks: - It can not be tested easily in the mock. - It introduces an inconsistency where resetting the stored output is handled in ext, but the runtime API is responsible to store it back correctly after any calls made. Instead, with ownership of the data in `Frame`, both can be handled in a single place. Handling both in `fn run()` is more natural and leaves less room for runtime API bugs. The returned output is reset each time _before_ running any executable in a nested stack. This change should not incur any overhead to the overall memory usage as _only_ the returned data from the last executed frame will be kept around at any time. --------- Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com> Signed-off-by: xermicus <cyrill@parity.io> Co-authored-by: command-bot <> Co-authored-by: PG Herveou <pgherveou@gmail.com>

A change that I missed to add in #5525 . --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>

Closes #5714

@ordian

This is the implementation of the approach described here: #1617 (comment) & #1617 (comment) & #1617 (comment). ## Description of changes The end goal is to have an architecture where we have single subsystem(`approval-voting-parallel`) and multiple worker types that would full-fill the work that currently is fulfilled by the `approval-distribution` and `approval-voting` subsystems. The main loop of the new subsystem would do just the distribution of work to the workers. The new subsystem will have: - N approval-distribution workers: This would do the work that is currently being done by the approval-distribution subsystem and in addition to that will also perform the crypto-checks that an assignment is valid and that a vote is correctly signed. Work is assigned via the following formula: `worker_index = msg.validator % WORKER_COUNT`, this guarantees that all assignments and approvals from the same validator reach the same worker. - 1 approval-voting worker: This would receive an already valid message and do everything the approval-voting currently does, except the crypto-checking that has been moved already to the approval-distribution worker. On the hot path of processing messages **no** synchronisation and waiting is needed between approval-distribution and approval-voting workers. <img width="1431" alt="Screenshot 2024-06-07 at 11 28 08" src="https://github.com/paritytech/polkadot-sdk/assets/49718502/a196199b-b705-4140-87d4-c6900ba8595e"> ## Guidelines for reading The full implementation is broken in 5 PRs and all of them are self-contained and improve things incrementally even without the parallelisation being implemented/enabled, the reason this approach was taken instead of a big-bang PR, is to make things easier to review and reduced the risk of breaking this critical subsystems. After reading the full description of this PR, the changes should be read in the following order: 1. #4848, some other micro-optimizations for networks with a high number of validators. This change gives us a speed up by itself without any other changes. 2. #4845 , this contains only interface changes to decouple the subsystem from the `Context` and be able to run multiple instances of the subsystem on different threads. **No functional changes** 3. #4928, moving of the crypto checks from approval-voting in approval-distribution, so that the approval-distribution has no reason to wait after approval-voting anymore. This change gives us a speed up by itself without any other changes. 4. #4846, interface changes to make approval-voting runnable on a separate thread. **No functional changes** 5. This PR, where we instantiate an `approval-voting-parallel` subsystem that runs on different workers the logic currently in `approval-distribution` and `approval-voting`. 6. The next step after this changes get merged and deploy would be to bring all the files from approval-distribution, approval-voting, approval-voting-parallel into a single rust crate, to make it easier to maintain and understand the structure. ## Results Running subsystem-benchmarks with 1000 validators 100 fully ocuppied cores and triggering all assignments and approvals for all tranches #### Approval does not lags behind. Master ``` Chain selection approved after 72500 ms hash=0x0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a ``` With this PoC ``` Chain selection approved after 3500 ms hash=0x0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a ``` #### Gathering enough assignments Enough assignments are gathered in less than 500ms, so that gives un a guarantee that un-necessary work does not get triggered, on master on the same benchmark because the subsystems fall behind on work, that number goes above 32 seconds on master. <img width="2240" alt="Screenshot 2024-06-20 at 15 48 22" src="https://github.com/paritytech/polkadot-sdk/assets/49718502/d2f2b29c-5ff6-44b4-a245-5b37ab8e58bc"> #### Cpu usage: Master ``` CPU usage, seconds total per block approval-distribution 96.9436 9.6944 approval-voting 117.4676 11.7468 test-environment 44.0092 4.4009 ``` With this PoC ``` CPU usage, seconds total per block approval-distribution 0.0014 0.0001 --- unused approval-voting 0.0437 0.0044. --- unused approval-voting-parallel 5.9560 0.5956 approval-voting-parallel-0 22.9073 2.2907 approval-voting-parallel-1 23.0417 2.3042 approval-voting-parallel-2 22.0445 2.2045 approval-voting-parallel-3 22.7234 2.2723 approval-voting-parallel-4 21.9788 2.1979 approval-voting-parallel-5 23.0601 2.3060 approval-voting-parallel-6 22.4805 2.2481 approval-voting-parallel-7 21.8330 2.1833 approval-voting-parallel-db 37.1954 3.7195. --- the approval-voting thread. ``` # Enablement strategy Because just some trivial plumbing is needed in approval-distribution and approval-voting to be able to run things in parallel and because this subsystems plays a critical part in the system this PR proposes that we keep both ways of running the approval work, as separated subsystems and just a single subsystem(`approval-voting-parallel`) which has multiple workers for the distribution work and one worker for the approval-voting work and switch between them with a comandline flag. The benefits for this is twofold. 1. With the same polkadot binary we can easily switch just a few validators to use the parallel approach and gradually make this the default way of running, if now issues arise. 2. In the worst case scenario were it becomes the default way of running things, but we discover there are critical issues with it we have the path to quickly disable it by asking validators to adjust their command line flags. # Next steps - [x] Make sure through various testing we are not missing anything - [x] Polish the implementations to make them production ready - [x] Add Unittest Tests for approval-voting-parallel. - [x] Define and implement the strategy for rolling this change, so that the blast radius is minimal(single validator) in case there are problems with the implementation. - [x] Versi long running tests. - [x] Add relevant metrics. @ordian @eskimor @sandreim @AndreiEres, let me know what you think. --------- Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>

Changes in PR: - disabled cargo-hfuzz until [the issue](#5812) is fixed. - enabled condition to skip jobs when no rust files are changed

Bump `zombienet` version to prevent report fails at teardown phase.

cc paritytech/ci_cd#1035 cc paritytech/ci_cd#1023 --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: command-bot <> Co-authored-by: Maksym H <1177472+mordamax@users.noreply.github.com> Co-authored-by: gui <gui.thiolliere@gmail.com> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: ggwpez <ggwpez@users.noreply.github.com>

Jaeger spans were not usable for debugging, see #4995, but we pay a price in CPU cost, subsystem-benchmarks show this brings a reduction of about 10-15% in CPU usage per subsystem, so remove it. --------- Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>

Reported in: #5844 #5848

- install frame-omni-bencher from the path - fix bench_features config

This PR removes a workaround which had a reference comment to a rust compiler issue. The issue has been fixed and we should be able to remove that trait bound.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[pull] master from paritytech:master #17

[pull] master from paritytech:master #17

Commits on Sep 11, 2024

Commits on Sep 12, 2024

Commits on Sep 13, 2024

Commits on Sep 16, 2024

Commits on Sep 17, 2024

Commits on Sep 18, 2024

Commits on Sep 19, 2024

Commits on Sep 20, 2024

Commits on Sep 22, 2024

Commits on Sep 23, 2024

Commits on Sep 24, 2024

Commits on Sep 25, 2024

Commits on Sep 26, 2024

Commits on Sep 27, 2024