This adds more logging to `CheckWeight` to get a better understanding
why a transaction exhausts resources.

Just keeping wasm-opt up to date.

I don't see anything in the [binaryen
changelog](https://github.com/WebAssembly/binaryen/blob/main/CHANGELOG.md)
that should affect substrate.

This release includes dwarf passes that were accidentally omitted from
previous versions of the wasm-opt crate. I suspect this will not affect
substrate as their omission hasn't been noticed until recently.

Implements the `OnUnbalanced` trait to resolve received credits to the
specified account. Credits that fail to resolve are dropped.

### Motivation 
Throughout the codebase, several types implement the trait with the same
behavior. While some currently utilize older currency trait, a migration
to the new fungible/s is anticipated for all. Examples:
[1](https://github.com/paritytech/polkadot-sdk/blob/1b34571c/cumulus/parachains/common/src/impls.rs#L37),
[2](https://github.com/paritytech/polkadot-sdk/blob/1b34571c/polkadot/runtime/common/src/impls.rs#L36),
[3](https://github.com/paritytech/polkadot-sdk/blob/1b34571c/substrate/bin/node/runtime/src/impls.rs#L40),
[4](https://github.com/paritytech/polkadot-sdk/blob/1b34571c/substrate/bin/node/runtime/src/lib.rs#L1969),
[5](https://github.com/paritytech/polkadot-sdk/blob/1b34571c/substrate/frame/broker/src/mock.rs#L198),
[6](https://github.com/paritytech/polkadot-sdk/blob/1b34571c/substrate/frame/society/src/lib.rs#L2031),
[7](https://github.com/paritytech/polkadot-sdk/blob/1b34571c/substrate/frame/treasury/src/lib.rs#L1118)

Even if the host configuration is returning `0` for the `lookahead`, we
should schedule at least one job on a core if the core exists.

Fixes #768.

Reverts https://github.com/paritytech/polkadot-sdk/pull/1476

The `lock_pallet` / `unlock_pallet` additions in
https://github.com/paritytech/polkadot-sdk/pull/1814 will result in less
downtime for users than using runtime upgrades.

This PR does not introduce any functional changes to the existing code,
it merely addresses several minor refactors:
- Moving bridging pallets to separate files.
- Improving the readability and naming of weight files for bridging
pallets and bridging pallet instances.

The reason for this refactor is to facilitate easier plugin integration
for the upcoming bridge between Rococo and Westend.

---------

Co-authored-by: command-bot <>

## Problem

This PR addresses the issue with testnet AssetHub builds, which was
discovered during the execution of `bot bench`.

https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4038738
```
     Compiling asset-hub-rococo-runtime-wasm v1.0.0 (/builds/parity/mirrors/polkadot-sdk/target/production/wbuild/asset-hub-rococo-runtime)
  warning: Linking globals named 'Core_version': symbol multiply defined!
  error: failed to load bitcode of module "rococo_runtime-8799ee884447805a.rococo_runtime.0bc572b8-cgu.0.rcgu.o": 
  warning: `asset-hub-rococo-runtime-wasm` (lib) generated 1 warning
  error: could not compile `asset-hub-rococo-runtime-wasm` (lib) due to previous error; 1 warning emitted
```

https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4038739
```
Compiling asset-hub-westend-runtime-wasm v1.0.0 (/builds/parity/mirrors/polkadot-sdk/target/production/wbuild/asset-hub-westend-runtime)
  warning: Linking globals named 'Core_version': symbol multiply defined!
  error: failed to load bitcode of module "westend_runtime-86d7844430f97d5c.westend_runtime.b7678d03-cgu.0.rcgu.o": 
  warning: `asset-hub-westend-runtime-wasm` (lib) generated 1 warning
  error: could not compile `asset-hub-westend-runtime-wasm` (lib) due to previous error; 1 warning emitted
```

## Solution

- Removed dependencies on `rococo-runtime` and `westend-runtime`
introduced by [this
PR](https://github.com/paritytech/polkadot-sdk/pull/1234/files#diff-a86375df98e04ca3cce1ea35c40257a222e2d5087f5f528ff33307678b78dc2dR534-R550).
- Replaced `<rococo_runtime::Treasury as PalletInfoAccess>::index()`
with `rococo_runtime_constants::TREASURY_PALLET_ID`.
- Added `check_treasury_pallet_id` to the relay runtimes to ensure that
the constant is aligned with the pallet id.
- Added "Rococo Treasury" to the waived locations (that will not be
charged fees in the executor) for `BridgeHubRococo` (to be aligned with
AssetHubs).

## References

[Full element discussion
here](https://matrix.to/#/!JUeaZUiYbdrvzvtwSL:parity.io/$2PnjYMsWRjR7M3oOfGuRI0XkjdoqJLtRcAPVcDLuLVg?via=parity.io&via=web3.foundation).

---------

Co-authored-by: command-bot <>

The migration was missing to migrate `AvailabilityCores`. If this isn't
migrated, all parachains in the availability phase would stall until the
next session is started. This pull request fixes this by migrating this
data. Besides that it is doing some cosmetics.

✄
-----------------------------------------------------------------------------

Thank you for your Pull Request! 🙏 Please make sure it follows the
contribution guidelines outlined in
[this
document](https://github.com/paritytech/polkadot-sdk/blob/master/docs/CONTRIBUTING.md)
and fill
out the sections below. Once you're ready to submit your PR for review,
please
delete this section and leave only the text under the "Description"
heading.

# Description

*Please include a summary of the changes and the related issue. Please
also include relevant motivation and context,
including:*

- What does this PR do?

make 'substrate-wasm-builder' manually set 'CARGO_TARGET_DIR' to
'$project_dir/target' while building instead of unset
'CARGO_TARGET_DIR';

- Why are these changes needed?

If you using this in the `build.rs` with following content in your
`~/.cargo/config.toml':

    [build]
    target-dir = "target"

the build process will stuck because of dead lock -- two `cargo build`
on same target directory in the same time.
There is already an attempt to avoid such dead lock by unset the
`CARGO_TARGET_DIR`, but for users with config above in his build
enviroment (like me), this workaround won't work.

- How were these changes implemented and what do they affect?

Instead of unset 'CARGO_TARGET_DIR', we set 'CARGO_TARGET_DIR' to
'$project/target/', which is already assumed to be true by rest of the
code.

*Use [Github semantic

linking](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)
to address any open issues this PR relates to or closes.*

Fixes # (issue number, *if applicable*)

Closes # (issue number, *if applicable*)

# Checklist

- [x] My PR includes a detailed description as outlined in the
"Description" section above
- [ ] My PR follows the [labeling requirements](CONTRIBUTING.md#Process)
of this project (at minimum one label for `T`
  required)
- [ ] I have made corresponding changes to the documentation (if
applicable)
- [ ] I have added tests that prove my fix is effective or that my
feature works (if applicable)

You can remove the "Checklist" section once all have been checked. Thank
you for your contribution!

✄
-----------------------------------------------------------------------------

I have built my project with this fix, there's still some warnings with
`build.target-dir` set but the building process won't hang.
I haven't found related issue in this repo. But I did find one issue
[here](https://github.com/substrate-developer-hub/substrate-node-template/issues/116).

Changes the maximum instances count for `wasmtime` to `64`. It also
allows to only pass in maximum `32` for `--max-runtime-instances` as
`256` was way too big. With `64` instances in total and `32` that can be
configured in maximum, there should be enough space to accommodate for
extra instances that are may required to be allocated adhoc.

---------

Co-authored-by: Koute <[email protected]>

Bumps [aes-gcm](https://github.com/RustCrypto/AEADs) from 0.10.2 to
0.10.3.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/RustCrypto/AEADs/commit/7e82b01cd4901f6a35b5153536f11b87f5e4e622"><code>7e82b01</code></a>
aes-gcm v0.10.3 (<a
href="https://redirect.github.com/RustCrypto/AEADs/issues/552">#552</a>)</li>
<li><a
href="https://github.com/RustCrypto/AEADs/commit/b587b27270cc300d39c496a1ab06be80d72ac107"><code>b587b27</code></a>
aes-gcm: avoid exposing plaintext on tag verification failure (<a
href="https://redirect.github.com/RustCrypto/AEADs/issues/551">#551</a>)</li>
<li><a
href="https://github.com/RustCrypto/AEADs/commit/2209bcaa9edc65e9a60498e7ece5b50e66f32ebf"><code>2209bca</code></a>
build(deps): bump actions/checkout from 3 to 4 (<a
href="https://redirect.github.com/RustCrypto/AEADs/issues/548">#548</a>)</li>
<li><a
href="https://github.com/RustCrypto/AEADs/commit/035ec25362886735a0f44098f85ba0501a9b4038"><code>035ec25</code></a>
build(deps): bump ascon from 0.3.1 to 0.4.0 (<a
href="https://redirect.github.com/RustCrypto/AEADs/issues/545">#545</a>)</li>
<li><a
href="https://github.com/RustCrypto/AEADs/commit/e94ba5ab9fb2c7f3a18c92fb9dc8df14ac36f06b"><code>e94ba5a</code></a>
xsalsa20poly1305: remove source code (<a
href="https://redirect.github.com/RustCrypto/AEADs/issues/543">#543</a>)</li>
<li><a
href="https://github.com/RustCrypto/AEADs/commit/31240c1285144aeabef3e80eb9a1b4137dc2b43f"><code>31240c1</code></a>
Update Cargo.lock</li>
<li><a
href="https://github.com/RustCrypto/AEADs/commit/40240c4a852df21048830de4eed4782c0fbddaef"><code>40240c4</code></a>
Update Cargo.lock</li>
<li><a
href="https://github.com/RustCrypto/AEADs/commit/be4ea6fd3bcc1c8a5a23974a43e0fc35104d8cba"><code>be4ea6f</code></a>
Update Cargo.lock</li>
<li><a
href="https://github.com/RustCrypto/AEADs/commit/2aef39e90d39c247cc89ccc31628468c9a9f60de"><code>2aef39e</code></a>
Update Clippy version (<a
href="https://redirect.github.com/RustCrypto/AEADs/issues/534">#534</a>)</li>
<li><a
href="https://github.com/RustCrypto/AEADs/commit/50710da0cbd47a4614b6d37119877f206c207e95"><code>50710da</code></a>
Update Cargo.lock</li>
<li>Additional commits viewable in <a
href="https://github.com/RustCrypto/AEADs/compare/aes-gcm-v0.10.2...aes-gcm-v0.10.3">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=aes-gcm&package-manager=cargo&previous-version=0.10.2&new-version=0.10.3)](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] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

in-progress PR adding new tests and solving bugs

---------

Co-authored-by: Bradley Olson <[email protected]>
Co-authored-by: eskimor <[email protected]>
Co-authored-by: eskimor <[email protected]>
Co-authored-by: Andrei Sandu <[email protected]>

This PR addresses several minor issues:
- Fixes the symlink for `asset-hub-rococo.json` chainspec.
- Corrects the `asset-hub-rococo-genesis` invulnerables setup.
- Relocates common bash functions for bridge testing to a separate file
`bridges_common.sh`.

This reverts https://github.com/paritytech/polkadot-sdk/pull/1812 until
we know why it causes syncing issues reported in
https://github.com/subspace/subspace/issues/2122.

The `xcm` crate was renamed to `staging-xcm` to be able to publish it to
crates.io as someone as squatted `xcm`. The problem with this rename is
that the `TypeInfo` includes the crate name which ultimately lands in
the metadata. The metadata is consumed by downstream users like
`polkadot-js` or people building on top of `polkadot-js`. These people
are using the entire `path` to find the type in the type registry. Thus,
their code would break as the type path would now be [`staging_xcm`,
`VersionedXcm`] instead of [`xcm`, `VersionedXcm`]. This pull request
fixes this by renaming the path segment `staging_xcm` to `xcm`.

This requires: https://github.com/paritytech/scale-info/pull/197

---------

Co-authored-by: Francisco Aguirre <[email protected]>

Removed some debug logs

Use a more secure seed for hashsets of cache.

Until now prometheus metrics were not exposed by the minimal relay chain
node.
Also slight cleanups.

The validators are checking if async backing is enabled by checking the
version of the runtime api. If the runtime api is upgraded by a runtime
upgrade, the validators start to also enable the async backing logic.
However, just because async backing is enabled, it doesn't mean that all
collators and parachain runtimes have upgraded. This pull request fixes
an issue about advertising collations to the relay chain when it has
async backing enabled, but the collator is still using the old
networking protocol. The implementation is actually backwards compatible
as we can not expect that everyone directly upgrades. However, the
collation advertisement logic was requiring V2 networking messages after
async backing was enabled, which was wrong. This is now fixed by this
pull request.

Closes: https://github.com/paritytech/polkadot-sdk/issues/1923

---------

Co-authored-by: eskimor <[email protected]>

This PR prevents failures until #1946 is merged.

Just adding a prdoc for
https://github.com/paritytech/polkadot-sdk/pull/1913

---------

Co-authored-by: Adrian Catangiu <[email protected]>

Includes:
-  PoC for new `spot instance` infra for jobs.
- Fixes in test-runner/cli

Changes:
- Use a sensible limit for the overweight-cutoff of a single messages
instead of the full configured `ServiceWeight`.
- Add/Update tests

---------

Signed-off-by: Oliver Tale-Yazdi <[email protected]>

When launching our [small
network](https://github.com/paritytech/polkadot-sdk/blob/master/cumulus/zombienet/examples/small_network.toml)
for testing the node was crashing here shortly after launch:

https://github.com/paritytech/polkadot-sdk/blob/5cdd819e/polkadot/node/collation-generation/src/lib.rs#L140

After changes in #1788 for the asset hub collator we are waiting for
blocks of the shell runtime to pass before we initialize aura. However,
this means that we attempted to initialize the collation related relay
chain subsystems twice, leading to the error.

I modified Aura to let it optionally take an already initialized stream
of collation requests.

`cargo install` takes a long time in CI. We want to run it relatively
frequently without chewing through so much compute (see
https://github.com/paritytech/ci_cd/issues/771) so I added automatic
binary releases to the try-runtime-cli repo.

A small added benefit is we can use it in our existing
`on-runtime-upgrade` checks, which should cut their execution time by
about half.

closes: https://github.com/paritytech/devops/issues/2090

## Changes
1. Updated the list of bootnodes.
2. Merged the Connect node and bootnode into a single node.
3. Decreased the number of nodes.
4. Updated the DNS name.

## Description
The initial 8 bootnodes were planned to be replaced by community
bootnodes, the community node was added but we did not bother to reduce
the Parity managed bootnodes. Fixing it now.

Combination of paritytech/polkadot#7005, its addon PR
paritytech/polkadot#7585 and its companion paritytech/cumulus#2433.

This PR introduces a new XcmFeesToAccount struct which implements the
`FeeManager` trait, and assigns this struct as the `FeeManager` in the
XCM config for all runtimes.

The struct simply deposits all fees handled by the XCM executor to a
specified account. In all runtimes, the specified account is configured
as the treasury account.

XCM __delivery__ fees are now being introduced (unless the root origin
is sending a message to a system parachain on behalf of the originating
chain).

# Note for reviewers

Most file changes are tests that had to be modified to account for the
new fees.
Main changes are in:
- cumulus/pallets/xcmp-queue/src/lib.rs <- To make it track the delivery
fees exponential factor
- polkadot/xcm/xcm-builder/src/fee_handling.rs <- Added. Has the
FeeManager implementation
- All runtime xcm_config files <- To add the FeeManager to the XCM
configuration

# Important note

After this change, instructions that create and send a new XCM (Query*,
Report*, ExportMessage, InitiateReserveWithdraw, InitiateTeleport,
DepositReserveAsset, TransferReserveAsset, LockAsset and RequestUnlock)
will require the corresponding origin account in the origin register to
pay for transport delivery fees, and the onward message will fail to be
sent if the origin account does not have the required amount. This
delivery fee is on top of what we already collect as tx fees in
pallet-xcm and XCM BuyExecution fees!

Wallet UIs that want to expose the new delivery fee can do so using the
formula:

```
delivery_fee_factor * (base_fee + encoded_msg_len * per_byte_fee)
```

where the delivery fee factor can be obtained from the corresponding
pallet based on which transport you are using (UMP, HRMP or bridges),
the base fee is a constant, the encoded message length from the message
itself and the per byte fee is the same as the configured per byte fee
for txs (i.e. `TransactionByteFee`).

---------

Co-authored-by: Branislav Kontur <[email protected]>
Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: Giles Cope <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Liam Aharon <[email protected]>
Co-authored-by: Kian Paimani <[email protected]>

Upgraded to version 2.1.0 which has paritytech/review-bot#94, a change
in the logic of the action to overcome some problems with permissions
coming from PRs from forks

For this, we needed to divide the actions into two files:
- A first action that triggers on PRs and reviews and uploads the PR
number.
- A second action which is triggered under the completion of the first
one and runs as the action normally runs (but won't have any problems
regarding permissions because it is triggered from the master branch)

I have added some Traits that are missing and are useful for dealing
with non-fungible tokens on other pallets and their implementations for
NFTs pallet.

- In the Mutate trait, added methods for dealing with the metadata:
`set_metadata`, `set_collection_metadata`, `clear_metadata` and
`clear_collection_metadata`.
The motivation of adding this methods coming from a StackExchange
question asking for it: [Setting metadata of an item of the Nfts pallet
in a custom
pallet](https://substrate.stackexchange.com/questions/9974/setting-metadata-of-an-item-of-the-nfts-pallet-in-a-custom-pallet)

- A Trait for trading non-fungible items. The methods in that Trait are
`buy_item`, `set_price` and `item_price`
An example of where this Trait can be useful is a pallet that deals with
[NFT
Royalties](https://forum.polkadot.network/t/nfts-royalty-pallet/3766)
and needs to perform this actions.

---------

Co-authored-by: Jegor Sidorenko <[email protected]>

Adds descriptions needed for publishing to crates.io.

Follow up of #1892, this PR now switches the env for release related
workflows from `master` to `release`.

Bumps [paritytech/review-bot](https://github.com/paritytech/review-bot) from 2.0.1 to 2.1.0.

Bumps [actions/checkout](https://github.com/actions/checkout) from 4.1.0 to 4.1.1.

Fellowship companion:
https://github.com/polkadot-fellows/runtimes/pull/65

This starts the BEEFY client by default for Polkadot nodes.

Governance/sudo call is later required to enable/start consensus.

Part of https://github.com/paritytech/parity-bridges-common/issues/2420

cumulus: add asset-hub-rococo runtime based on asset-hub-kusama and add asset-bridging support to it (#1215)

This commit adds Rococo Asset Hub dedicated runtime so we can test new
features here, before merging them in Kusama Asset Hub.
Also adds one such feature: asset transfer over bridge (Rococo AssetHub
<> Wococo AssetHub)

- clone `asset-hub-kusama-runtime` -> `asset-hub-rococo-runtime`
- make it use Rococo primitives, names, assets, constants, etc
- add asset-transfer-over-bridge support to Rococo AssetHub <> Wococo
AssetHub

Fixes #1128

---------

Co-authored-by: Branislav Kontur <[email protected]>
Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: Francisco Aguirre <[email protected]>

Remove `publish = false` to publish the crate

Adds descriptions needed for publishing bridges crates to crates.io.

see https://forum.parity.io/t/crates-need-descriptions/2115

Signed-off-by: Adrian Catangiu <[email protected]>

Closes https://github.com/paritytech/polkadot-sdk/issues/1916

Changes:
- Trivially wrap the migration into a version migration to enforce
idempotency.
- Opinionated logging nits

@liamaharon maybe we can add a check to the `try-runtime-cli` that
migrations are idempotent? It should be possible to check that the
storage root is identical after executing a second time (and that it
does not panic like it did here 😆

).

---------

Signed-off-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: Liam Aharon <[email protected]>
Co-authored-by: Francisco Aguirre <[email protected]>