This PR implements conformance tests between our network backends
(litep2p and libp2p).

The PR creates a setup for extending testing in the future, while
implementing the following tests:
- connectivity check: Connect litep2p -> libp2p and libp2p -> litep2p
- request response check: Send 32 requests from one backend to the other
- notification check: Send 128 ping pong notifications and 128 from one
backend to the other

cc @paritytech/networking

---------

Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>

# Description

Currently, the `#[benchmarks]` macro always add `<T:Config>` to the
expanded code even if a where clause is used. Using a where clause which
also includes a trait bound for the generic `T` is triggering [this
clippy
warning](https://rust-lang.github.io/rust-clippy/master/index.html#multiple_bound_locations)
from Rust 1.78 onwards. We've found that
[here](https://github.com/freeverseio/laos/blob/main/pallets/precompiles-benchmark/src/precompiles/vesting/benchmarking.rs#L126-L132)
in LAOS, as we need to include `T: pallet_vesting::Config` in the where
clause, here's the outcome:

```rust
error: bound is defined in more than one place
   --> pallets/precompiles-benchmark/src/precompiles/vesting/benchmarking.rs:130:1
    |
130 | / #[benchmarks(
131 | |     where
132 | |         T: Config + pallet_vesting::Config,
    | |         ^
133 | |         T::AccountIdToH160: ConvertBack<T::AccountId, H160>,
134 | |         BalanceOf<T>: Into<U256>,
135 | |         BlockNumberFor<T>: Into<U256>
136 | | )]
    | |__^
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#multiple_bound_locations
    = note: `-D clippy::multiple-bound-locations` implied by `-D warnings`
    = help: to override `-D warnings` add `#[allow(clippy::multiple_bound_locations)]`
    = note: this error originates in the attribute macro `benchmarks` (in Nightly builds, run with -Z macro-backtrace for more info)
```

While this is a harmless warning, only thrown due to a trait bound for T
is being defined twice in an expanded code that nobody will see, and
while annotating the benchmarks module with
`#[allow(clippy::multiple_bound_locations)]` is enough to get rid of it,
it might cause unnecessary concerns.

Hence, I think it's worth slightly modifying the macro to avoid this.

## Review Notes

What I propose is to include `<T: Config>` (or its instance version) in
the expanded code only if no where clause was specified, and include
that trait bound in the where clause if one is present.

I considered always creating a where clause which includes `<T: Config>`
even if the macro doesn't specify a where clause and totally getting rid
of `<T: Config>`, but discarded the idea for simplicity.

I also considered checking if `T:Config` is present in the provided
where clause (as it's the case in the LAOS example I provided) before
adding it, but discarded the idea as well due to it implies a bit more
computation and having `T:Config` defined twice in the where clause is
harmless: the compiler will ignore the second occurrence and nobody will
see it's there.

If you think this change is worth it and one of the discarded ideas
would be a better approach, I'm happy to push that code instead.

# Description

This PR ensure that only valid syntax is uses inside the `Cargo.toml`. 

## Integration

Not sure if worth backporting. Came across this when trying to package
`try-runtime-cli`.

## Review Notes

It should be obvious that this is not valid syntax. I am not able to add
labels and doubt this requires a prdoc.

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

When trying to reproduce bugs we sometimes need to deploy code that
wouldn't pass validation. This PR adds a new environment variable
`REVIVE_SKIP_VALIDATION` that when set will skip all validation except
the contract blob size limit.

Please note that this only applies to when the pallet is compiled for
`std` and hence will never be part of on-chain.

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Changes:
- Expose a `force_set_head` function from the `MessageQueue` pallet via
a new trait: `ForceSetHead`. This can be used to force the MQ pallet to
process this queue next.
- The change only exposes an internal function through a trait, no audit
is required.

## Context

For the Asset Hub Migration (AHM) we need a mechanism to prioritize the
inbound upward messages and the inbound downward messages on the AH. To
achieve this, a minimal (and no breaking) change is done to the MQ
pallet in the form of adding the `force_set_head` function.

An example use of how to achieve prioritization is then demonstrated in
`integration_test.rs::AhmPrioritizer`. Normally, all queues are
scheduled round-robin like this:

`| Relay | Para(1) | Para(2) | ... | Relay | ... `

The prioritizer listens to changes to its queue and triggers if either:
- The queue processed in the last block (to keep the general round-robin
scheduling)
- The queue did not process since `n` blocks (to prevent starvation if
there are too many other queues)

In either situation, it schedules the queue for a streak of three
consecutive blocks, such that it would become:

`| Relay | Relay | Relay | Para(1) | Para(2) | ... | Relay | Relay |
Relay | ... `

It basically transforms the round-robin into an elongated round robin.
Although different strategies can be injected into the pallet at
runtime, this one seems to strike a good balance between general service
level and prioritization.

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: muharem <ismailov.m.h@gmail.com>

Cargo.lock change to subxt were rolled back 
Fixing it and updating it in Cargo.toml so it does not happen again

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Closes #3270

---------

Co-authored-by: command-bot <>

When debugging stuff, it is useful to see the full hashes and not only
the "short form". This makes it easier to read logs and follow blocks.

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

#### Overview

This PR introduces a new mechanism to capture and report metrics related
to timings of transaction lifecycle events, which are currently not
available. By exposing these timings, we aim to augment transaction-pool
reliability dashboards and extend existing Grafana boards.

A new `unknown_from_block_import_txs` metric is also introduced. It
provides the number of transactions in imported block which are not
known to the node's transaction pool. It allows to monitor alignment of
transaction pools across the nodes in the network.

#### Notes for reviewers
- **[Per-event
Metrics](https://github.com/paritytech/polkadot-sdk/blob/8a53992e/substrate/client/transaction-pool/src/fork_aware_txpool/metrics.rs#L84-L105)
Collection**: implemented by[
`EventsMetricsCollector`](https://github.com/paritytech/polkadot-sdk/blob/8a53992e/substrate/client/transaction-pool/src/fork_aware_txpool/metrics.rs#L353-L358)
which allows to capture both submission timestamps and transaction
status updates. An asynchronous
[`EventsMetricsCollectorTask`](https://github.com/paritytech/polkadot-sdk/blob/8a53992e/substrate/client/transaction-pool/src/fork_aware_txpool/metrics.rs#L503-L526)
processes the metrics-related messages sent by the
`EventsMetricsCollector` and reports the timings of transaction statuses
updates to Prometheus. This task implements event[
de-duplication](https://github.com/paritytech/polkadot-sdk/blob/8a53992e/substrate/client/transaction-pool/src/fork_aware_txpool/metrics.rs#L458)
using a `HashMap` of
[`TransactionEventMetricsData`](https://github.com/paritytech/polkadot-sdk/blob/8a53992e/substrate/client/transaction-pool/src/fork_aware_txpool/metrics.rs#L424-L435)
entries which also holds transaction submission timestamps used to
[compute
timings](https://github.com/paritytech/polkadot-sdk/blob/8a53992e/substrate/client/transaction-pool/src/fork_aware_txpool/metrics.rs#L489-L495).
Transaction-related items are removed when transaction's final status is
[reported](https://github.com/paritytech/polkadot-sdk/blob/8a53992e/substrate/client/transaction-pool/src/fork_aware_txpool/metrics.rs#L496).
- Transaction submission timestamp is reusing the timestamp of
`TimedTransactionSource` kept in mempool. It is reported to
`EventsMetricsCollector` in
[`submit_at`](https://github.com/paritytech/polkadot-sdk/blob/8a53992e/substrate/client/transaction-pool/src/fork_aware_txpool/fork_aware_txpool.rs#L735)
and
[`submit_and_watch`](https://github.com/paritytech/polkadot-sdk/blob/8a53992e/substrate/client/transaction-pool/src/fork_aware_txpool/fork_aware_txpool.rs#L836)
methods of `ForkAwareTxPool`.
- Transaction updates are reported to `EventsMetricsCollector` from
`MultiViewListener`
[task](https://github.com/paritytech/polkadot-sdk/blob/8a53992e/substrate/client/transaction-pool/src/fork_aware_txpool/multi_view_listener.rs#L494).
This allows to gather metrics for _watched_ and _non-watched_
transactions (what enables metrics on non-rpc-enabled collators).
- New metric
([`unknown_from_block_import_txs`](https://github.com/paritytech/polkadot-sdk/blob/8a53992e/substrate/client/transaction-pool/src/fork_aware_txpool/metrics.rs#L59-L60))
allowing checking alignment of pools across the network is
[reported](https://github.com/paritytech/polkadot-sdk/blob/8a53992e/substrate/client/transaction-pool/src/fork_aware_txpool/fork_aware_txpool.rs#L1288-L1292)
using new `TxMemPool`
[method](https://github.com/paritytech/polkadot-sdk/blob/8a53992e

/substrate/client/transaction-pool/src/fork_aware_txpool/tx_mem_pool.rs#L605-L611).

fixes: #7355, #7448

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Sebastian Kunert <skunert49@gmail.com>
Co-authored-by: Iulian Barbu <14218860+iulianbarbu@users.noreply.github.com>

Follow up from
https://github.com/paritytech/polkadot-sdk/pull/6362#issuecomment-2629744365

The goal of this PR is to have the scheduler pallet work on a parachain
which does not produce blocks on a regular schedule, thus can use the
relay chain as a block provider.

Because blocks are not produced regularly, we cannot make the assumption
that block number increases monotonically, and thus have new logic to
handle multiple spend periods passing between blocks.

Requirement: 

instead of using the hard coded system block number. We add an
associated type BlockNumberProvider

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

The command no longer support multiple audience, also the mapping was
wrong.

Includes a fix on the `wait` job (for waiting images to be ready).

Fix `build-linux-substrate` when opening PRs from a `polkadot-sdk` fork

Failed CI job example:
https://github.com/paritytech/polkadot-sdk/actions/runs/13284026730/job/37088673786?pr=7548

Related to https://github.com/paritytech/polkadot-sdk/issues/7360

Update some dependencies needed for implementing
`DecodeWithMemTracking`:
`parity-scale-codec` -> 3.7.4
`finality-grandpa` -> 0.16.3
`bounded-collections` -> 0.2.3
`impl-codec` -> 0.7.1

Implementation of on-demand credits as described in
[RFC-1](https://github.com/polkadot-fellows/RFCs/blob/main/text/0001-agile-coretime.md#instantaneous-coretime)

---------

Co-authored-by: ordian <write@reusable.software>
Co-authored-by: Dónal Murray <donalm@seadanda.dev>

to zombienet-sdk 0.2.24 (also needed to update to this version for
slashing to work).

---------

Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Co-authored-by: Alexandru Vasile <60601340+lexnv@users.noreply.github.com>

Add debug endpoint to eth-rpc for capturing a block or a single
transaction traces

See:
-  PR #7166

---------

Co-authored-by: Alexander Theißen <alex.theissen@me.com>
Co-authored-by: command-bot <>
Co-authored-by: Yuri Volkov <0@mcornholio.ru>
Co-authored-by: Maksym H <1177472+mordamax@users.noreply.github.com>
Co-authored-by: Santi Balaguer <santiago.balaguer@gmail.com>
Co-authored-by: Dónal Murray <donal.murray@parity.io>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: xermicus <cyrill@parity.io>

add a warning about hidden file not transfered.

cargo remote is not really configurable so I just use my own fork for
now: https://github.com/sgeisler/cargo-remote/pull/25

PR adds [evm-test-suite](https://github.com/paritytech/evm-test-suite)
in CI.

close https://github.com/paritytech/ci_cd/issues/1103

`#[allow(dead_code)]` -> `#![allow(dead_code)]` in templates

Use `rpc_port` instead of `ws_port` in bridge tests since `ws_port` is
deprecated.

closes https://github.com/polkadot-developers/polkadot-docs/issues/238

---------

Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>

# Description

Fixes #7039

The Preservation of transfer method of fungible and fungibles adapters
is changed from Preserve to Expendable. So the behavior of the
TransferAsset will be consistent with the WithdrawAsset function, as in
[fungible](https://github.com/paritytech/polkadot-sdk/blob/f3ab3854

/polkadot/xcm/xcm-builder/src/fungible_adapter.rs#L217)
and [fungibles](https://github.com/paritytech/polkadot-sdk/issues/url)
adapter.

This pull request includes changes to the `fungible_adapter.rs` and
`fungibles_adapter.rs` files in the `polkadot/xcm/xcm-builder`
directory. The main change involves modifying the transfer method to use
the `Expendable` strategy instead of the `Preserve` strategy.

Changes to transfer strategy:

*
[`polkadot/xcm/xcm-builder/src/fungible_adapter.rs`](diffhunk://#diff-6ebd77385441f2c8b023c480e818a01c4b43ae892c73ca30144cd64ee960bd66L67-R67):
Changed the transfer method to use `Expendable` instead of `Preserve`.
*
[`polkadot/xcm/xcm-builder/src/fungibles_adapter.rs`](diffhunk://#diff-82221429de4c4c88be3d2976ece6475ef4fa56a32abc70290911bd47191f8e17L61-R61):
Changed the transfer method to use `Expendable` instead of `Preserve`.

---------

Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
Co-authored-by: Adrian Catangiu <adrian@parity.io>

Add support for eth_get_logs rpc method

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: xermicus <cyrill@parity.io>

- Charge the nested gas meter for loading the code of the child
contract, so that we can properly associate the gas cost to the child
call frame.
- Move the enter_child_span and exit_child_span around the
do_transaction closure to properly capture all failures
- Add missing trace capture for call transfer

---------

Co-authored-by: Alexander Theißen <alex.theissen@me.com>
Co-authored-by: command-bot <>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Bastian Köcher <git@kchr.de>

# Description

Resolves #5777

Previously `wasm-builder` used hacks such as `-Zbuild-std` (required
`rust-src` component) and `RUSTC_BOOTSTRAP=1` to build WASM runtime
without WASM features: `sign-ext`, `multivalue` and `reference-types`,
but since Rust 1.84 (will be stable on 9 January, 2025) the situation
has improved as there is new
[`wasm32v1-none`](https://doc.rust-lang.org/beta/rustc/platform-support/wasm32v1-none.html)
target that disables all "post-MVP" WASM features except
`mutable-globals`.

Previously, your `rust-toolchain.toml` looked like this:

```toml
[toolchain]
channel = "stable"
components = ["rust-src"]
targets = ["wasm32-unknown-unknown"]
profile = "default"
```

It should now be updated to something like this:

```toml
[toolchain]
channel = "stable"
targets = ["wasm32v1-none"]
profile = "default"
```

To build the runtime:

```bash
cargo build --package minimal-template-runtime --release
```

## Integration

If you...

Let's burry out the old `RUSTC_BOOTSTRAP` hack. This is required when
you don't use `rustup` which automatically switches to the nightly
toolchain when it detects nightly CLI args.

Co-authored-by: Alexander Theißen <alex.theissen@me.com>

This PR introduces BlockNumberProvider config for the nomination pool
pallet.
closes part of https://github.com/paritytech/polkadot-sdk/issues/6297

This should fix some compilation warnings discovered under rustc 1.83

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Migrate subtrate's zombienet test from gitlab to gha.

---------

Co-authored-by: alvicsam <alvicsam@gmail.com>

- Fix a deadlock on the RWLock cache
- Remove eth-indexer, we won't need it anymore, the indexing will be
started from within eth-rpc directly

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

- [x] refactor view functions metadata according to #6833 in preparation
for V16, and move them to pallet-level metadata
- [x] add `view_functions_experimental` macro to `pallet_macros` with
API docs
- [x] improve pallet-level UI testing for view functions

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>

#7463 follow up with RPC fixes

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

approval-voting-parallel has been running on all network types except
polkadot since release `1.17.0`, so it has around 2 months of baking and
running without any reported issues, so let's enable it on polkadot as
well.

After running in polkadot for awhile the flag will be entirely removed.

---------

Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>

This PR introduces BlockNumberProvider config for the conviction voting
pallet.
closes part of https://github.com/paritytech/polkadot-sdk/issues/6297

---------

Co-authored-by: muharem <ismailov.m.h@gmail.com>
Co-authored-by: command-bot <>

Recently there were some requests to build and deploy a binary, for
example `polkadot`, in the `release` or `production` profile to do some
testing.
So far we had only a
[release](https://github.com/paritytech/polkadot-sdk/blob/master/.github/workflows/release-20_build-rc.yml)
pipeline that could do it in the GitHub but to use it, there was a lot
of extra overhead needed.
This pipeline should simplify this case and give a possibility to build
a binary in desired profile from any branch for the testing purposes.
Something similar to what we have for runtimes in the [srtool
repo](https://github.com/paritytech/srtool/actions/workflows/manual.yml)
It won't be used in any release activities though.

CC: @BulatSaif

There is a small issue on restart, where if finality is lagging across
session boundary and the validator restarts, then the validator won't be
able to contribute anymore with assginments/approvals and gossiping for
the blocks from the previous session, because after restart it builds
the Topology only for the new session, so without a topology it won't be
able to distribute assignments and approvals because everything in
`approval-distribution` is gated on having a topology for the block.

The fix is to also keep track of the last finalized block and its
session and if it is different from the list of encountered sessions,
build its topology and send it to the rest of subsystems.

---------

Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Co-authored-by: ordian <write@reusable.software>

This PR introduces BlockNumberProvider config for pallet society.
closes part of https://github.com/paritytech/polkadot-sdk/issues/6297

- Closes https://github.com/paritytech/license-scanner/issues/44
- Silent because only comments are changed in the crates.

## What's inside

First, we change the file traversal mechanism from shell globbing to
walking through files which happens inside the `license-scanner` - so it
has knowledge about directory structure and can correlate files with
corresponding Cargo manifest.

Next, added `MIT-0` and `Unlicense` to the allowed list of licenses.
`Unlicense` appears only once across {Substrate,Cumulus,Polkadot} - in
`penpal-runtime`.

Finally, updated headers in files that do not match the corresponding
manifest license.

---------

Co-authored-by: cornholio <0@mcornholio.ru>