This commit introduces a new concept called `NotificationService` which
allows Polkadot protocols to communicate with the underlying
notification protocol implementation directly, without routing events
through `NetworkWorker`. This implies that each protocol has its own
service which it uses to communicate with remote peers and that each
`NotificationService` is unique with respect to the underlying
notification protocol, meaning `NotificationService` for the transaction
protocol can only be used to send and receive transaction-related
notifications.

The `NotificationService` concept introduces two additional benefits:
  * allow protocols to start using custom handshakes
  * allow protocols to accept/reject inbound peers

Previously the validation of inbound connections was solely the
responsibility of `ProtocolController`. This caused issues with light
peers and `SyncingEngine` as `ProtocolController` would accept more
peers than `SyncingEngine` could accept which caused peers to have
differing views of their own states. `SyncingEngine` would reject excess
peers but these rejections were not properly communicated to those peers
causing them to assume that they were accepted.

With `NotificationService`, the local handshake is not sent to remote
peer if peer is rejected which allows it to detect that it was rejected.

This commit also deprecates the use of `NetworkEventStream` for all
notification-related events and going forward only DHT events are
provided through `NetworkEventStream`. If protocols wish to follow each
other's events, they must introduce additional abtractions, as is done
for GRANDPA and transactions protocols by following the syncing protocol
through `SyncEventStream`.

Fixes https://github.com/paritytech/polkadot-sdk/issues/512
Fixes https://github.com/paritytech/polkadot-sdk/issues/514
Fixes https://github.com/paritytech/polkadot-sdk/issues/515
Fixes https://github.com/paritytech/polkadot-sdk/issues/554
Fixes https://github.com/paritytech/polkadot-sdk/issues/556

---
These changes are transferred from
https://github.com/paritytech/substrate/pull/14197 but there are no
functional changes compared to that PR

---------

Co-authored-by: Dmitry Markin <[email protected]>
Co-authored-by: Alexandru Vasile <[email protected]>

This was never used and we probably don't need it anyway.

Co-authored-by: ordian <[email protected]>
Co-authored-by: Vladimir Istyufeev <[email protected]>

Step in https://github.com/paritytech/polkadot-sdk/issues/171

This PR adds `derive_impl` on all `frame_system` config impls for mock
runtimes. The overridden configs are maintained as of now to ensure
minimal changes.

---------

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

Currently the polkadot node will backoff from block authoring if
finality starts lagging. This PR disables this mechanism on production
networks (polkadot and kusama) and adds a flags to optionally force
enabling it.

We're going to bridge Polkadot Bridge Hub with [Polkadot Bulletin
chain](https://github.com/zdave-parity/polkadot-bulletin-chain) soon
(and Rococo Bridge Hub with 1:1 copy of Polkadot Bulletin chain even
sooner), so we need a variant for that chain in `NetworkId`. As
suggested, I'm adding a new variant for it to the `NetworkId` (we may
have used `ByGenesis(_)`, but decision was made to have a dedicated
variant for that).

Addresses #409.

This request has been raised by multiple community members - the ability
for the nomination pool root role to configure permissionless commission
claiming:

> Would it be possible to have a claim_commission_other extrinsic for
claiming commission of nomination pools permissionless?

This PR does not quite introduce this additional call, but amends
`do_claim_commission` to check a new `claim_permission` field in the
`Commission` struct, configured by an enum:

```
enum CommissionClaimPermission {
   Permissionless,
   Account(AccountId),
}
```
This can be optionally set in a bonded pool's
`commission.claim_permission` field:

```
struct BondedPool {
   commission: {
      <snip>
      claim_permission: Option<CommissionClaimPermission<T::AccountId>>,
   },
   <snip>
}
```

This is a new field and requires a migration to add it to existing
pools. This will be `None` on pool creation, falling back to the `root`
role having sole access to claim commission if it is not set; this is
the behaviour as it is today. Once set, the field _can_ be set to `None`
again.

#### Changes
- [x] Add `commision.claim_permission` field.
- [x] Add `can_claim_commission` and amend `do_claim_commission`.
- [x] Add `set_commission_claim_permission` call.
- [x] Test to cover new configs and call.
- [x] Add and amend benchmarks.
- [x] Generate new weights + slot into call
`set_commission_claim_permission`.
- [x] Add migration to introduce `commission.claim_permission`, bump
storage version.
- [x] Update Westend weights.
- [x] Migration working.

---------

Co-authored-by: command-bot <>

Our executor currently only supports the WASM MVP feature set, however
nowadays when compiling WASM the Rust compiler has more features enabled
by default.

We do set the `-C target-cpu=mvp` flag to make sure that *our* code gets
compiled in a way that is compatible with our executor, however this
doesn't affect Rust's standard library crates (`std`, `core` and
`alloc`) which are by default precompiled and still can make use of
these extra features.

So in this PR we force the compiler to also compile the standard library
crates for us to make sure that they also only use the MVP features.

I've added the `WASM_BUILD_STD` environment variable which can be used
to disable this behavior if set to `0`.

Unfortunately this *will* slow down the compile times when building
runtimes, but there isn't much that we can do about that.

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

---------

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

**Overview:**
Adding an extra malus variant focusing on disputing finalized blocks. It
will:
- wrap around approval-voting
- listen to `OverseerSignal::BlockFinalized` and when encountered start
a dispute for the `dispute_offset`th ancestor
- simply pass through all other messages and signals

Add zombienet tests testing various edgecases:
- disputing freshly finalized blocks
- disputing stale finalized blocks
- disputing eagerly pruned finalized blocks (might be separate PR)

**TODO:**
- [x] Register new malus variant
- [x] Simple pass through wrapper (approval-voting)
- [x] Simple network definition
- [x] Listen to block finalizations
- [x] Fetch ancestor hash
- [x] Fetch session index
- [x] Fetch candidate
- [x] Construct and send dispute message
- [x] zndsl test 1 checking that disputes on fresh finalizations resolve
valid Closes #1365
- [x] zndsl test 2 checking that disputes for too old finalized blocks
are not possible Closes #1364
- [ ] zndsl test 3 checking that disputes for candidates with eagerly
pruned relay parent state are handled correctly #1359 (deferred to a
separate PR)
- [x] Unit tests for new malus variant (testing cli etc)
- [x] Clean/streamline error handling
- [ ] ~~Ensure it tests properly on session boundaries~~

---------

Co-authored-by: Javier Viola <[email protected]>
Co-authored-by: Marcin S. <[email protected]>
Co-authored-by: Tsvetomir Dimitrov <[email protected]>

## 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]>

Use non-zero weight limit in benchmarking `pallet_xcm::execute()` so the
given XCM actually executes.

closes #2194 

cc @mrcnski



---------

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

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 <>

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]>

Deprecates `RewardDestination::Controller` variant.

- [x] `RewardDestination::Controller` annotated with `#[deprecated]`.
- [x] `Controller` variant is now handled the same way as `Stash` in
`payout_stakers`.
- [x] `set_payee` errors if `RewardDestination::Controller` is provided.
- [x] Added `update_payee` call to lazily migrate
`RewardDestination::Controller` `Payee` storage entries to
`RewardDestination::Account(controller)` .
- [x] `payout_stakers_dead_controller` has been removed from benches &
weights - was not used.
- [x] Tests no longer use `RewardDestination::Controller`.

---------

Co-authored-by: command-bot <>
Co-authored-by: Gonçalo Pestana <[email protected]>
Co-authored-by: georgepisaltu <[email protected]>

Adding on top of the new builder pattern for creating XCM programs, I'm
adding some more APIs:

```rust
let paying_fees: Xcm<()> = Xcm::builder() // Only allow paying for fees
  .withdraw_asset() // First instruction has to load the holding register
  .buy_execution() // Second instruction has to be `buy_execution`
  .build();

let paying_fees_invalid: Xcm<()> = Xcm::builder()
  .withdraw_asset()
  .build(); // Invalid, need to pay for fees

let not_paying_fees: Xcm<()> = Xcm::builder_unpaid()
  .unpaid_execution() // Needed
  .withdraw_asset()
  .deposit_asset()
  .build();

let all_goes: Xcm<()> = Xcm::builder_unsafe() // You can do anything
  .withdraw_asset()
  .deposit_asset()
  .build();
```

The invalid bits are because the methods don't even exist on the types
that you'd want to call them on.

---------

Co-authored-by: command-bot <>

Follow up from https://github.com/paritytech/polkadot-sdk/pull/2370 to
add `output` positional argument to undying-collator.

cc @JoshOrndorff

---------

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

Hey guys, as discussed I've changed the name to a more general one
`PvfExecKind`, is this good or too general?
Creating this as a draft, I still have to fix the tests.

Closes #1585

Kusama address: FkB6QEo8VnV3oifugNj5NeVG3Mvq1zFbrUu4P5YwRoe5mQN

---------

Co-authored-by: command-bot <>
Co-authored-by: Marcin S <[email protected]>

Co-authored-by: Marcin S <[email protected]>

The versioned migrations are already there in pallet nomination-pools:

https://github.com/paritytech/polkadot-sdk/blob/f6ee4781/substrate/frame/nomination-pools/src/migration.rs#L27-L48

Just updating the kitchensink runtime to point to them.

This is also nice because it points the dev to an example of how to use
`VersionedMigration`.

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

cc @joepetrowski

Westend now successfully updated to `spec: 103000`, we **have to
remove** the session keys migration before the next release as it
doesn't gracefully handle reapplying it.

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.

The goal of this PR is to migrate Identity deposits from the Relay Chain
to a system parachain.

The problem I want to solve is that `IdentityOf` and `SubsOf` both store
an amount that's held in reserve as a storage deposit. When migrating to
a parachain, we can take a snapshot of the actual `IdentityInfo` and
sub-account mappings, but should migrate (off chain) the `deposit`s to
zero, since the chain (and by extension, accounts) won't have any funds
at genesis.

The good news is that we expect parachain deposits to be significantly
lower (possibly 100x) on the parachain. That is, a deposit of 21 DOT on
the Relay Chain would need 0.21 DOT on a parachain. This PR proposes to
migrate the deposits in the following way:

1. Introduces a new pallet with two extrinsics: 
- `reap_identity`: Has a configurable `ReapOrigin`, which would be set
to `EnsureSigned` on the Relay Chain (i.e. callable by anyone) and
`EnsureRoot` on the parachain (we don't want identities reaped from
there).
- `poke_deposit`: Checks what deposit the pallet holds (at genesis,
zero) and attempts to update the amount based on the calculated deposit
for storage data.
2. `reap_identity` clears all storage data for a `target` account and
unreserves their deposit.
3. A `ReapIdentityHandler` teleports the necessary DOT to the parachain
and calls `poke_deposit`. Since the parachain deposit is much lower, and
was just unreserved, we know we have enough.

One awkwardness I ran into was that the XCMv3 instruction set does not
provide a way for the system to teleport assets without a fee being
deducted on reception. Users shouldn't have to pay a fee for the system
to migrate their info to a more efficient location. So I wrote my own
program and did the `InitiateTeleport` accounting on my own to send a
program with `UnpaidExecution`. Have discussed an
`InitiateUnpaidTeleport` instruction with @franciscoaguirre

 . Obviously
any chain executing this would have to pass a `Barrier` for free
execution.

TODO:

- [x] Confirm People Chain ParaId
- [x] Confirm People Chain deposit rates (determined in
https://github.com/paritytech/polkadot-sdk/pull/2281)
- [x] Add pallet to Westend

---------

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

Disallow reserve transfers that use teleportable fees if `(origin,
fees)` matches `XcmTeleportFilter`.

Add regression tests for filtering based on `XcmTeleportFilter` for both
`(limited_)reserve_transfer_assets()` and `(limited_)teleport_assets`
extrinsics.

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 #1437

Co-authored-by: Sophia Gold <[email protected]>

Co-authored-by: Marcin S <[email protected]>

## Problem/Motivation
The benchmark for the `ExpectPallet` XCM instruction uses a hard-coded
version `4.0.0` for the `frame_system` pallet. Unfortunately, this
doesn't work for the `polkadot-fellows/runtimes` repository, where we
use dependencies from `crates.io`, e.g.,
[frame-system::23.0.0.0](https://github.com/polkadot-fellows/runtimes/blob/dd7f86f0d50064481ed0b7c0218494a5cfad997e/relay/kusama/Cargo.toml#L83).

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

## Solution
This PR fixes the benchmarks that require pallet information and enables
the runtime to provide the correct/custom pallet information. The
default implementation provides `frame_system::Pallet` with index `0`,
where the version is not hard-coded but read from the runtime.


## Local testing

Added log for `T::valid_pallet` to the benchmarks like:
```
let valid_pallet = T::valid_pallet();
log::info!(
	target: "frame::benchmark::pallet",
	"valid_pallet: {}::{}::{}::{}::{}",
	valid_pallet.index,
	valid_pallet.module_name,
	valid_pallet.crate_version.major,
	valid_pallet.crate_version.minor,
	valid_pallet.crate_version.patch,
);
```

Run benchmarks for `westend`:
```
cargo run --bin=polkadot --features=runtime-benchmarks -- benchmark pallet --steps=2 --repeat=1 --extrinsic=* --heap-pages=4096 --json-file=./bench.json --chain=westend-dev --template=./polkadot/xcm/pallet-xcm-benchmarks/template.hbs --pallet=pallet_xcm_benchmarks::generic --output=./polkadot/runtime/westend/src/weights/xcm
```

---

For actual `frame_system` version:
```
[package]
name = "frame-system"
version = "4.0.0-dev"
```

Log dump:
```
2023-11-13 12:56:45 Starting benchmark: pallet_xcm_benchmarks::generic::query_pallet    
2023-11-13 12:56:45 valid_pallet: 0::frame_system::4::0::0    
2023-11-13 12:56:45 valid_pallet: 0::frame_system::4::0::0    
2023-11-13 12:56:45 valid_pallet: 0::frame_system::4::0::0    
2023-11-13 12:56:45 Starting benchmark: pallet_xcm_benchmarks::generic::expect_pallet    
2023-11-13 12:56:45 valid_pallet: 0::frame_system::4::0::0    
2023-11-13 12:56:45 valid_pallet: 0::frame_system::4::0::0    
2023-11-13 12:56:45 valid_pallet: 0::frame_system::4::0::0 
```


For changed `frame_system` version:
```
[package]
name = "frame-system"
version = "5.1.3-dev"
```

Log dump:
```
2023-11-13 12:51:51 Starting benchmark: pallet_xcm_benchmarks::generic::query_pallet    
2023-11-13 12:51:51 valid_pallet: 0::frame_system::5::1::3    
2023-11-13 12:51:51 valid_pallet: 0::frame_system::5::1::3    
2023-11-13 12:51:51 valid_pallet: 0::frame_system::5::1::3    
2023-11-13 12:51:51 Starting benchmark: pallet_xcm_benchmarks::generic::expect_pallet    
2023-11-13 12:51:51 valid_pallet: 0::frame_system::5::1::3    
2023-11-13 12:51:51 valid_pallet: 0::frame_system::5::1::3    
2023-11-13 12:51:51 valid_pallet: 0::frame_system::5::1::3
```

## References

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

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]>