## Overview

This PR aligns the `spec_version` formatting to the [recent
changes](https://github.com/polkadot-fellows/runtimes/pull/26/files#diff-efa4caeb17487ecb13d8f5eb7863c3241d84afa2e73fbf25909a2ca89df0f362R142)
made for the Polkadot/Kusama runtimes.

It also backports the latest version `v1.4.0` bumps as `1_004_000`.

## Details

During the switch from `v0.9` to `v1.x`, the format of the
`spec_version` was modified from: `(M)m_ppp` for a runtime considered on
version `M.m.pp`. For instance `0.9.42` had a `spec_version` of `9420`.

With the transition to `v1.x`, the format was changed to a bigger number
(still `u32`) formatted as `MM_mm_ppp` where `1.2.3` would be stored as
`01_02_003`.

This PR aligns the format with that has been introduced in the
fellowship repo: `MMM_mmm_ppp`.

---------

Co-authored-by: Bastian Köcher <[email protected]>

This PR removes some `ChainSpec` types which are not necessary
(left-overs from #1256). Currently `ChainSpec` does not have to be
generic over the specific `RuntimeGenesisConfig`, it is enough to use
single type for all:

https://github.com/paritytech/polkadot-sdk/blob/9f787018/cumulus/polkadot-parachain/src/chain_spec/mod.rs#L53-L54


related to: https://github.com/paritytech/polkadot-sdk/issues/25

---------

Co-authored-by: command-bot <>

Otherwise the user may runs into weird errors if there is already a db.

The last issue blocking the removal of the Polkadot and Kusama system
parachains from the repo in #1737 is the dependency on the runtime code
through the RuntimeApi in `polkadot-parachain`.

This PR introduces two fake runtimes to satisfy the build requirements
and changes the `new_partial` function to make it not be generic over
the runtimes.
The reason for the second runtime is the different Aura keys used in
Polkadot Asset Hub, as the impl for AuraApi depends on this type.
If this changes the `RuntimeApi` generic could be removed completely
from all functions in `services.rs` and and generic type parameters in
`services.rs` and specified as a concrete type to TFullClient`.

---------

Co-authored-by: Bastian Köcher <[email protected]>

After #2001 the `fork_choice` strategy may remain uninitialized in the
block import pipeline which uses relay-chain verifier.
Refer to
https://github.com/paritytech/polkadot-sdk/pull/2430#issuecomment-1823979813
for some further discussion.

DMP queue migration is complete and the pallet should be removed to fix
the check runtime upgrade CI.

<img width="1501" alt="Screenshot 2023-11-24 at 16 05 37"
src="https://github.com/paritytech/polkadot-sdk/assets/16665596/ee1da6bb-2756-4423-8085-1e4c73553ad5">

<img width="1501" alt="Screenshot 2023-11-24 at 16 06 44"
src="https://github.com/paritytech/polkadot-sdk/assets/16665596/03f3e88f-aed8-4eaa-aab6-7998f72258be">

I noticed that this test broke at some point. The parachain nodes should
only acquire their blocks from the relay chain. But they were connecting
to their peers and started fetching blocks from there.

In this test I now take additional measures so we check that each nodes
really uses pov-recovery to get the blocks.

On extrinsics/call, ensure local XCM execution is complete/successful.
Otherwise, fail the extrinsic so that state changes don't get committed
to the db.

Added regression tests that fail without the fix.

fixes #2237

---------

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

Broken after #2446.

This moves the macro related re-exports to `__private` to make it more
obvious for downstream users that they are using an internal api.

---------

Co-authored-by: command-bot <>

Collectives Westend is missing an `on-chain-release-build` feature flag.

This PR removes `#[macro_use]` from the service module in each of the
Substrate nodes in the repo.

* Parachain Template
* Polkadot Parachain
* Minimal Node
* Node Template
* Kitchen Sink Node

IDK why this annotation was present, maybe from when we had the
`new_partial!` macro?

---------

Co-authored-by: Joshy Orndorff <[email protected]>

The out-dated version (bad tag) of [polkadot
image](https://github.com/paritytech/polkadot-sdk/blob/ede4a362

/.gitlab/pipeline/zombienet/cumulus.yml#L31)
([docker
info](https://hub.docker.com/layers/paritypr/polkadot-debug/master/images/sha256:adb1658052cf671b50c90d5cece5c7a131efa1a95978249bd5cb85a5ad654f7a?context=explore))
was used. This PR fixes this.

See also:
https://github.com/paritytech/polkadot-sdk/pull/2411#issuecomment-1822632724

Also adds an abstraction that allows asynchronous backends to be passed to `ChainApiSubsystem`
---------

Co-authored-by: Sebastian Kunert <[email protected]>

Add the possibility to inject additional key-values in the
sproof-builder that generates the relay root that gets stored in
parachain-system.

Rationale: pallets that verify additional storage items (not those
verified by parachain-system) from the relay should be able to proof
against the relay root that gets stored in parachain-system. This PR
allows to create provide additional nibles that can later be used for
verifiability in other pallets

This is follow-up for:
https://github.com/paritytech/polkadot-sdk/pull/2001

Block import queue for `test-parachain` (`cumulus-test-service`) shall
use delayed best block feature.

This should fixed broken zombienet tests.

This updates the tick runtime and polkadot-parachain collator to use
async backing.

This PR adds the `delayed_best_block` flag to `ParachainBlockImport`. If
not set, the `params.fork_choice` is not updated (to
`ForkChoiceStrategy::Custom`) during the block import.

When `delayed_best_block` is set to `false` all parachain blocks on the
[longest
fork](https://github.com/paritytech/polkadot-sdk/blob/552be480

/substrate/client/service/src/client/client.rs#L708-L709)
will be notified as the best block, allowing transaction pool to be
updated with every imported block.

Otherwise imported blocks will not be notified as best blocks
(`fork_choice=ForkChoiceStrategy::Custom(false)`), and transaction pool
would be updated only with best block received from relay-chain.

Improvement for: #1202

---------

Co-authored-by: Bastian Köcher <[email protected]>

Westend Collectives migration CI check can be fixed once we have
https://github.com/paritytech/try-runtime-cli/pull/58, will open another
PR once it is available.

- [x] Remove deprecated `DmpQueue` pallet from Rococo Contracts, the
migration is complete
- [x] Fix Asset Hub Rococo storage versions
- [x] Add migration check CI for Asset Hub Rococo and Westend Bridge Hub

The `--relay-chain-rpc-urls` CLI flag has been available for a while
now. We have collators with this running and parachain teams are also
using it. It should be fine now to remove the experimental status.

This PR fixes two things:
- relax `force_default_xcm_version` for testnet system parachains (e.g.
BridgeHubWestend has now 2 and there is no way to change it to 3, so we
need to call `force_xcm_version(3)` for every parachain that it is
connected to, because we send XCMv3 messages)
- add `Storage` item to `PolkadotXcm` pallet definition (now we cannot
see storage items for `pallet_xcm` in PJS)


## TODO

- [ ] when merged open PR to `polkadot-fellows/runtimes` repo

Fix some incorrect doc-comments

Missed in https://github.com/paritytech/polkadot-sdk/pull/1672

Rococo<>Wococo bridge is replaced by Rococo<Westend bridge, so this PR
removes unneeded code.

- [x] update bridges subtree after
https://github.com/paritytech/parity-bridges-common/pull/2692

---------

Co-authored-by: command-bot <>
Co-authored-by: Svyatoslav Nikolsky <[email protected]>

Refunding surplus happens anyway on xcm_executor::post_process(),
automatically refunding surplus to original_origin at the end of
execution. Since SovereignPaidRemoteExporter doesn't ClearOrigin, it can
simply rely on the automatic mechanism.

Furthermore, RefundSurplus instruction refunds _surplus_. Surplus exists
only as a result of Transact, SetErrorHandler or SetAppendix
instructions, none of which being part of the
SovereignPaidRemoteExporter XCM program. So surplus is always zero here
anyway.

Add collectives and glutton parachain westend runtimes to prepare for
#1737.

The removal of system parachain native runtimes #1737 is blocked until
chainspecs and runtime APIs can be dealt with cleanly (merge of #1256
and follow up PRs).

In the meantime, these additions are ready to be merged to `master`, so
I have separated them out into this PR.

Also marked `bridge-hub-westend` as unimplemented in line with [this
issue](https://github.com/paritytech/parity-bridges-common/issues/2602).

TODO
- [x] add to `command-bot` benchmarks
- [x] add to `command-bot-scripts` benchmarks
- [x] generate weights

---------

Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: Muharem <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: Branislav Kontur <[email protected]>

This PR introduces:
- XCM  host functions `xcm_send`, `xcm_execute`
- An Xcm trait into the config. that proxy these functions to to
`pallet_xcm`, or disable their usage by using `()`.
- A mock_network and xcm_test files to test the newly added xcm-related
functions.

---------

Co-authored-by: Keith Yeung <[email protected]>
Co-authored-by: Sasha Gryaznov <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Alexander Theißen <[email protected]>

Adds a `NodeFeatures` bitfield value to the runtime `HostConfiguration`,
with the purpose of coordinating the enabling of node-side features,
such as: https://github.com/paritytech/polkadot-sdk/issues/628 and
https://github.com/paritytech/polkadot-sdk/issues/598.
These are features that require all validators enable them at the same
time, assuming all/most nodes have upgraded their node versions.

This PR doesn't add any feature yet. These are coming in future PRs.

Also adds a runtime API for querying the state of the client features
and an extrinsic for setting/unsetting a feature by its index in the bitfield.

Note: originally part of:
https://github.com/paritytech/polkadot-sdk/pull/1644, but posted as
standalone to be reused by other PRs until the initial PR is merged

Fixes https://github.com/paritytech/polkadot-sdk/issues/106

Port of cumulus PR https://github.com/paritytech/cumulus/pull/2960

This PR adds the ability to bid for collator slots even after the max
number of collators have already registered. This eliminates the first
come, first served mechanism that was in place before.

Key changes:
- added `update_bond` extrinsic to allow registered candidates to adjust
their bonds in order to dynamically control their bids
- added `take_candidate_slot` extrinsic to try to replace an already
existing candidate by bidding more than them
- candidates are now kept in a sorted list in the pallet storage, where
the top `DesiredCandidates` out of `MaxCandidates` candidates in the
list will be selected by the session pallet as collators
- if the candidacy bond is increased through a `set_candidacy_bond`
call, candidates which don't meet the new bond requirements are kicked


# Checklist

- [ ] My PR includes a detailed description as outlined in the
"Description" section above
- [ ] My PR follows the [labeling
requirements](https://github.com/paritytech/polkadot-sdk/blob/master/docs/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)
- [ ] If this PR alters any external APIs or interfaces used by
Polkadot, the corresponding Polkadot PR is ready as well as the
corresponding Cumulus PR (optional)

---------

Signed-off-by: georgepisaltu <[email protected]>

- switch from Rococo<>Wococo to Rococo<>Westend bridge
- add bidirectional simple tests
- remove Wococo chains from xcm-emulator
- added tests for assets transfers over Rococo<>Westend bridge 

fixes https://github.com/paritytech/parity-bridges-common/issues/2405

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

See issue comments for more details about this storage.

Collators were previously reencoding the available data and checking the
erasure root.
Replace that with just checking the PoV hash, which consumes much less
CPU and takes less time.

We also don't need to check the `PersistedValidationData` hash, as
collators don't use it.

Reason:
https://github.com/paritytech/polkadot-sdk/issues/575#issuecomment-1806572230

After systematic chunks recovery is merged, collators will no longer do
any reed-solomon encoding/decoding, which has proven to be a great CPU
consumer.

Signed-off-by: alindima <[email protected]>

## Motivation

`pallet-xcm` is the main user-facing interface for XCM functionality,
including assets manipulation functions like `teleportAssets()` and
`reserve_transfer_assets()` calls.

While `teleportAsset()` works both ways, `reserve_transfer_assets()`
works only for sending reserve-based assets to a remote destination and
beneficiary when the reserve is the _local chain_.

## Solution

This PR enhances `pallet_xcm::(limited_)reserve_withdraw_assets` to
support transfers when reserves are other chains.
This will allow complete, **bi-directional** reserve-based asset
transfers user stories using `pallet-xcm`.

Enables following scenarios:
- transferring assets with local reserve (was previously supported iff
asset used as fee also had local reserve - now it works in all cases),
- transferring assets with reserve on destination,
- transferring assets with reserve on remote/third-party chain (iff
assets and fees have same remote reserve),
- transferring assets with reserve different than the reserve of the
asset to be used as fees - meaning can be used to transfer random asset
with local/dest reserve while using DOT for fees on all involved chains,
even if DOT local/dest reserve doesn't match asset reserve,
- transferring assets with any type of local/dest reserve while using
fees which can be teleported between involved chains.

All of the above is done by pallet inner logic without the user having
to specify which scenario/reserves/teleports/etc. The correct scenario
and corresponding XCM programs are identified, and respectively, built
automatically based on runtime configuration of trusted teleporters and
trusted reserves.

#### Current limitations:
- while `fees` and "non-fee" `assets` CAN have different reserves (or
fees CAN be teleported), the remaining "non-fee" `assets` CANNOT, among
themselves, have different reserve locations (this is also implicitly
enforced by `MAX_ASSETS_FOR_TRANSFER=2`, but this can be safely
increased in the future).
- `fees` and "non-fee" `assets` CANNOT have **different remote**
reserves (this could also be supported in the future, but adds even more
complexity while possibly not being worth it - we'll see what the future
holds).

Fixes https://github.com/paritytech/polkadot-sdk/issues/1584
Fixes https://github.com/paritytech/polkadot-sdk/issues/2055

---------

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

We are introducing a new set of `XcmController` traits (final name yet
to be determined).
These traits are implemented by `pallet-xcm` and allows other pallets,
such as `pallet_contracts`, to rely on these traits instead of tight
coupling them to `pallet-xcm`.

Using only the existing Xcm traits would mean duplicating the logic from
`pallet-xcm` in these other pallets, which we aim to avoid. Our
objective is to ensure that when these APIs are called from
`pallet-contracts`, they produce the exact same outcomes as if called
directly from `pallet-xcm`.

The other benefits is that we can also expose return values to
`pallet-contracts` instead of just calling `pallet-xcm` dispatchable and
getting a `DispatchResult` back.

See traits integration in this PR
https://github.com/paritytech/polkadot-sdk/pull/1248, where the traits
are used as follow to define and implement `pallet-contracts` Config.
```rs
// Contracts config:
pub trait Config: frame_system::Config {
  // ...

  /// A type that exposes XCM APIs, allowing contracts to interact with other parachains, and
  /// execute XCM programs.
  type Xcm: xcm_executor::traits::Controller<
	  OriginFor<Self>,
	  <Self as frame_system::Config>::RuntimeCall,
	  BlockNumberFor<Self>,
  >;
}

// implementation
impl pallet_contracts::Config for Runtime {
        // ...

	type Xcm = pallet_xcm::Pallet<Self>;
}
```

---------

Co-authored-by: Alexander Theißen <[email protected]>
Co-authored-by: command-bot <>

Missing descriptions (47):  

- [x] `cumulus/client/collator/Cargo.toml`
- [x] `cumulus/client/relay-chain-inprocess-interface/Cargo.toml`
- [x] `cumulus/client/cli/Cargo.toml`
- [x] `cumulus/client/service/Cargo.toml`
- [x] `cumulus/client/relay-chain-rpc-interface/Cargo.toml`
- [x] `cumulus/client/relay-chain-interface/Cargo.toml`
- [x] `cumulus/client/relay-chain-minimal-node/Cargo.toml`
- [x] `cumulus/parachains/pallets/parachain-info/Cargo.toml`
- [x] `cumulus/parachains/pallets/ping/Cargo.toml`
- [x] `cumulus/primitives/utility/Cargo.toml`
- [x] `cumulus/primitives/aura/Cargo.toml`
- [x] `cumulus/primitives/core/Cargo.toml`
- [x] `cumulus/primitives/parachain-inherent/Cargo.toml`
- [x] `cumulus/test/relay-sproof-builder/Cargo.toml`
- [x] `cumulus/pallets/xcmp-queue/Cargo.toml`
- [x] `cumulus/pallets/dmp-queue/Cargo.toml`
- [x] `cumulus/pallets/xcm/Cargo.toml`
- [x] `polkadot/erasure-coding/Cargo.toml`
- [x] `polkadot/statement-table/Cargo.toml`
- [x] `polkadot/primitives/Cargo.toml`
- [x] `polkadot/rpc/Cargo.toml`
- [x] `polkadot/node/service/Cargo.toml`
- [x] `polkadot/node/core/parachains-inherent/Cargo.toml`
- [x] `polkadot/node/core/approval-voting/Cargo.toml`
- [x] `polkadot/node/core/dispute-coordinator/Cargo.toml`
- [x] `polkadot/node/core/av-store/Cargo.toml`
- [x] `polkadot/node/core/chain-api/Cargo.toml`
- [x] `polkadot/node/core/prospective-parachains/Cargo.toml`
- [x] `polkadot/node/core/backing/Cargo.toml`
- [x] `polkadot/node/core/provisioner/Cargo.toml`
- [x] `polkadot/node/core/runtime-api/Cargo.toml`
- [x] `polkadot/node/core/bitfield-signing/Cargo.toml`
- [x] `polkadot/node/network/dispute-distribution/Cargo.toml`
- [x] `polkadot/node/network/bridge/Cargo.toml`
- [x] `polkadot/node/network/collator-protocol/Cargo.toml`
- [x] `polkadot/node/network/approval-distribution/Cargo.toml`
- [x] `polkadot/node/network/availability-distribution/Cargo.toml`
- [x] `polkadot/node/network/bitfield-distribution/Cargo.toml`
- [x] `polkadot/node/network/gossip-support/Cargo.toml`
- [x] `polkadot/node/network/availability-recovery/Cargo.toml`
- [x] `polkadot/node/collation-generation/Cargo.toml`
- [x] `polkadot/node/overseer/Cargo.toml`
- [x] `polkadot/runtime/parachains/Cargo.toml`
- [x] `polkadot/runtime/common/slot_range_helper/Cargo.toml`
- [x] `polkadot/runtime/metrics/Cargo.toml`
- [x] `polkadot/xcm/pallet-xcm-benchmarks/Cargo.toml`
- [x] `polkadot/utils/generate-bags/Cargo.toml`
- [x]  `substrate/bin/minimal/runtime/Cargo.toml`

---------

Signed-off-by: Oliver Tale-Yazdi <[email protected]>
Signed-off-by: alindima <[email protected]>
Co-authored-by: ordian <[email protected]>
Co-authored-by: Tsvetomir Dimitrov <[email protected]>
Co-authored-by: Marcin S <[email protected]>
Co-authored-by: alindima <[email protected]>
Co-authored-by: Sebastian Kunert <[email protected]>
Co-authored-by: Dmitry Markin <[email protected]>
Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: Liam Aharon <[email protected]>

# Description

We would like to add our bootnodes to the following parachains:

Westend: Westmint, Bridgehub

Kusama: Statemine, Bridgehub

Polkadot: Statemint, Bridgehub, Collectives

Thank you.

---------

Co-authored-by: Oliver Tale-Yazdi <[email protected]>

This PR changes the registration order of the `MessageQueue` pallet so
that it is registered last.

This is necessary so that the
[on_initialize](https://github.com/Snowfork/snowbridge/blob/df8d5da8/parachain/pallets/outbound-queue/src/lib.rs#L267)
hooks for Snowbridge can run before `MessageQueue` delivers messages
using its own `on_initialize`.

Generally, I think this is preferable regardless of Snowbridge's
particular requirements. Other pallets may want to do housekeeping
before MessageQueue starts delivering messages.

I'm hoping this PR, if accepted, can be included in the same release as
https://github.com/paritytech/polkadot-sdk/pull/1246. As otherwise,
changing the order of pallet registration is an ABI-breaking change.

This PR contains some fixes and cleanups for parachain nodes:

1. When using async backing, node no longer complains about being unable
to reach the prospective-parachain subsystem.
2. Parachain warp sync now informs users that the finalized para block
has been retrieved.
```
2023-11-08 13:24:42 [Parachain] 🎉 Received finalized parachain header #5747719 (0xa0aa…674b) from the relay chain.
```
3. When a user supplied an invalid `--relay-chain-rpc-url`, we were
crashing with a very verbose message. Removed the `expect` and improved
the error message.
```
2023-11-08 13:57:56 [Parachain] No valid RPC url found. Stopping RPC worker.
2023-11-08 13:57:56 [Parachain] Essential task `relay-chain-rpc-worker` failed. Shutting down service.
Error: Service(Application(WorkerCommunicationError("RPC worker channel closed. This can hint and connectivity issues with the supplied RPC endpoints. Message: oneshot canceled")))
```

Some legacy tests were mistakenly merged in #1256 for `emulated-integration-tests-common` crate.
This PR fixes the function name `build_genesis_storage` (no need to use `legacy` suffix, even though the genesis is built from `RuntimeGenesisConfig`).

Closes:
- #1383 
- Declared chains can be now be imported and reused in a different
crate.
- Chain declaration are now generic over a generic type `N` (the
Network)
- #1389
- Solved #1383, chains and networks declarations can be restructure to
avoid having to compile all chains when running integrations tests where
are not needed.
- Chains are now declared on its own crate (removed from
`integration-tests-common`)
- Networks are now declared on its own crate (removed from
`integration-tests-common`)
    - Integration tests will import only the relevant Network crate
- `integration-tests-common` is renamed to
`emulated-integration-tests-common`

All this is necessary to be able to implement what is described here:
https://github.com/paritytech/roadmap/issues/56#issuecomment-1777010553

---------

Co-authored-by: command-bot <>