Skip to content
Snippets Groups Projects
Select Git revision
  • 8083
  • gh-readonly-queue/master/pr-8070-6a3bcf86ced6723f9d3ef2c05fb0e550e935b046 protected
  • 8070
  • 7936
  • 8095
  • gh-readonly-queue/master/pr-7933-f1d1d9c5c8d0effe4c60b81f6eaaa112ddc14658 protected
  • master default protected
  • 8094
  • 7686
  • 7882
  • 8093
  • 8001
  • 7980
  • 8038
  • gh-readonly-queue/master/pr-8070-f1d1d9c5c8d0effe4c60b81f6eaaa112ddc14658 protected
  • gh-readonly-queue/master/pr-8062-342f46a4e37749a749a405e6cacece9687f2a9f2 protected
  • gh-readonly-queue/master/pr-7703-d13f1f60adc942621e2d335b0ea5d54accc02140 protected
  • gh-readonly-queue/master/pr-8071-9be43c0abf0a02a28d8fd4bbe9cfaed17dfcf18c protected
  • 6224
  • 8068
20 results
Search by author
  • Any Author
  • Aaro Altonen Aaro Altonen altonen
  • Administrator Administrator Admin0
  • Alexander Alexander alvicsam
  • Alexander Kalankhodzhaev Alexander Kalankhodzhaev kalaninja
  • Alexander Theißen Alexander Theißen athei
  • Alexandra Alexandra a13xndra
  • Alin Dima Alin Dima alindima
  • Andrew Jones Andrew Jones ascjones
  • André Silva André Silva andresilva
  • Anthony Lazam Anthony Lazam lazam
  • Anton Anton melekes
  • Anton Vilhelm Ásgeirsson Anton Vilhelm Ásgeirsson antonva
  • Arsham Teymouri Arsham Teymouri ArshamTeymouri
  • Artyom Bakhtin Artyom Bakhtin bakhtin
  • Bernardo A. Rodrigues Bernardo A. Rodrigues bernardoaraujor
  • Bradley Olson Bradley Olson BradleyOlson64
  • Branislav Kontur Branislav Kontur bkontur
  • Bulat Saifullin Bulat Saifullin BulatSaif
  • Chevdor Chevdor chevdor
  • Chris Kerr Chris Kerr piffle-rack
20 authors
  1. Feb 27, 2025
  3. Feb 24, 2025
    • Raymond Cheung's avatar
      Enhance XCM Debugging with Log Capture in Unit Tests (#7594) · d189f9e7
      Raymond Cheung authored 
      
# Description

This PR introduces a lightweight log-capturing mechanism for XCM unit
tests, simplifying debugging by enabling structured log assertions. It
partially addresses #6119 and #6125, offering an optional way to verify
logs in tests while remaining unobtrusive in normal execution.

# Key Changes

* [x] Introduces a log capture utility in `sp_tracing`.
* [x] Adds XCM test examples demonstrating how and when to use log
capturing.

# Review Notes:

* The log capture mechanism is opt-in and does not affect existing tests
unless explicitly used.
* The implementation is minimal and does not add complexity to existing
test setups.
* It provides a structured alternative to
[`sp_tracing::init_for_tests()`](https://paritytech.github.io/polkadot-sdk/master/sp_tracing/fn.init_for_tests.html)
for log verification in automated tests.

---------

Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      d189f9e7
  5. Feb 20, 2025
    • Alexander Theißen's avatar
      Update to Rust stable 1.84.1 (#7625) · e2d3da61
      Alexander Theißen authored 
      Ref https://github.com/paritytech/ci_cd/issues/1107

We mainly need that so that we can finally compile the `pallet_revive`
fixtures on stable. I did my best to keep the commits focused on one
thing to make review easier.

All the changes are needed because rustc introduced more warnings or is
more strict about existing ones. Most of the stuff could just be fixed
and the commits should be pretty self explanatory. However, there are a
few this that are notable:

## `non_local_definitions `

A lot of runtimes to write `impl` blocks inside functions. This makes
sense to reduce the amount of conditional compilation. I guess I could
have moved them into a module instead. But I think allowing it here
makes sense to avoid the code churn.

## `unexpected_cfgs`

The FRAME macros emit code that references various features like `std`,
`runtime-benchmarks` or `try-runtime`. If a create that uses those
macros does not have those features we get this warning. Those were
mostly when ...
      e2d3da61
  7. Feb 17, 2025
  9. Feb 07, 2025
    • Przemek Rzad's avatar
      Ensure license headers match the Cargo manifest licenses (#5776) · 3726493d
      Przemek Rzad authored 
      
- 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: Yuri Volkov's avatarcornholio <0@mcornholio.ru>
      3726493d
  11. Jan 23, 2025
    • runcomet's avatar
      Balances: Configurable Number of Genesis Accounts with Specified Balances for Benchmarking (#6267) · 04847d51
      runcomet authored 
      
# Derived Dev Accounts

Resolves https://github.com/paritytech/polkadot-sdk/issues/6040

## Description
This update introduces support for creating an arbitrary number of
developer accounts at the genesis block based on a specified derivation
path. This functionality is gated by the runtime-benchmarks feature,
ensuring it is only enabled during benchmarking scenarios.

### Key Features
- Arbitrary Dev Accounts at Genesis: Developers can now specify any
number of accounts to be generated at genesis using a hard derivation
path.

- Default Derivation Path: If no derivation path is provided (i.e., when
`Option<dev_accounts: (..., None)>` is set to `Some` at genesis), the
system will default to the path `//Sender//{}`.

- No Impact on Total Token Issuance: Developer accounts are excluded
from the total issuance of the token supply at genesis, ensuring they do
not affect the overall balance or token distribution.

polkadot address: 14SRqZTC1d8rfxL8W1tBTnfUBPU23ACFVPzp61FyGf4ftUFg

---------

Co-authored-by: default avatarSebastian Kunert <skunert49@gmail.com>
      04847d51
  13. Dec 20, 2024
    • Xavier Lau's avatar
      Reorder dependencies' keys (#6967) · a843d15e
      Xavier Lau authored 
      
It doesn't make sense to only reorder the features array.

For example:

This makes it hard for me to compare the dependencies and features,
especially some crates have a really really long dependencies list.
```toml​
[dependencies]
c = "*"
a = "*"
b = "*"

[features]
std = [
  "a",
  "b",
  "c",
]
```

This makes my life easier.
```toml​
[dependencies]
a = "*"
b = "*"
c = "*"

[features]
std = [
  "a",
  "b",
  "c",
]
```

---------

Co-authored-by: default avatarBastian Köcher <git@kchr.de>
Co-authored-by: command-bot <>
      a843d15e
  15. Dec 12, 2024
  17. Dec 05, 2024
    • Francisco Aguirre's avatar
      Added fallback_max_weight to Transact for sending messages to V4 chains (#6643) · f31c70aa
      Francisco Aguirre authored 
      
Closes: https://github.com/paritytech/polkadot-sdk/issues/6585

Removing the `require_weight_at_most` parameter in V5 Transact had only
one problem. Converting a message from V5 to V4 to send to chains that
didn't upgrade yet. The conversion would not know what weight to give to
the Transact, since V4 and below require it.

To fix this, I added back the weight in the form of an `Option<Weight>`
called `fallback_max_weight`. This can be set to `None` if you don't
intend to deal with a chain that hasn't upgraded yet. If you set it to
`Some(_)`, the behaviour is the same. The plan is to totally remove this
in V6 since there will be a good conversion path from V6 to V5.

---------

Co-authored-by: default avatarGitHub Action <action@github.com>
Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
      f31c70aa
  19. Dec 03, 2024
  21. Nov 06, 2024
  23. Oct 18, 2024
    • georgepisaltu's avatar
      FRAME: Reintroduce `TransactionExtension` as a replacement for `SignedExtension` (#3685) · b76e91ac
      georgepisaltu authored 
      
Original PR https://github.com/paritytech/polkadot-sdk/pull/2280
reverted in https://github.com/paritytech/polkadot-sdk/pull/3665

This PR reintroduces the reverted functionality with additional changes,
related effort
[here](https://github.com/paritytech/polkadot-sdk/pull/3623).
Description is copied over from the original PR

First part of [Extrinsic
Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415)

Introduces a new trait `TransactionExtension` to replace
`SignedExtension`. Introduce the idea of transactions which obey the
runtime's extensions and have according Extension data (né Extra data)
yet do not have hard-coded signatures.

Deprecate the terminology of "Unsigned" when used for
transactions/extrinsics owing to there now being "proper" unsigned
transactions which obey the extension framework and "old-style" unsigned
which do not. Instead we have __*General*__ for the former and
__*Bare*__ for the latter. (Ultimately, the latter will be phased out as
a type of transaction, and Bare will only be used for Inherents.)

Types of extrinsic are now therefore:
- Bare (no hardcoded signature, no Extra data; used to be known as
"Unsigned")
- Bare transactions (deprecated): Gossiped, validated with
`ValidateUnsigned` (deprecated) and the `_bare_compat` bits of
`TransactionExtension` (deprecated).
  - Inherents: Not gossiped, validated with `ProvideInherent`.
- Extended (Extra data): Gossiped, validated via `TransactionExtension`.
  - Signed transactions (with a hardcoded signature) in extrinsic v4.
- General transactions (without a hardcoded signature) in extrinsic v5.

`TransactionExtension` differs from `SignedExtension` because:
- A signature on the underlying transaction may validly not be present.
- It may alter the origin during validation.
- `pre_dispatch` is renamed to `prepare` and need not contain the checks
present in `validate`.
- `validate` and `prepare` is passed an `Origin` rather than a
`AccountId`.
- `validate` may pass arbitrary information into `prepare` via a new
user-specifiable type `Val`.
- `AdditionalSigned`/`additional_signed` is renamed to
`Implicit`/`implicit`. It is encoded *for the entire transaction* and
passed in to each extension as a new argument to `validate`. This
facilitates the ability of extensions to acts as underlying crypto.

There is a new `DispatchTransaction` trait which contains only default
function impls and is impl'ed for any `TransactionExtension` impler. It
provides several utility functions which reduce some of the tedium from
using `TransactionExtension` (indeed, none of its regular functions
should now need to be called directly).

Three transaction version discriminator ("versions") are now permissible
(RFC [here](https://github.com/polkadot-fellows/RFCs/pull/84)) in
extrinsic version 5:
- 0b00000100 or 0b00000101: Bare (used to be called "Unsigned"):
contains Signature or Extra (extension data). After bare transactions
are no longer supported, this will strictly identify an Inherents only.
Available in both extrinsic versions 4 and 5.
- 0b10000100: Old-school "Signed" Transaction: contains Signature, Extra
(extension data) and an extension version byte, introduced as part of
[RFC99](https://github.com/polkadot-fellows/RFCs/blob/main/text/0099-transaction-extension-version.md).
Still available as part of extrinsic v4.
- 0b01000101: New-school "General" Transaction: contains Extra
(extension data) and an extension version byte, as per RFC99, but no
Signature. Only available in extrinsic v5.

For the New-school General Transaction, it becomes trivial for authors
to publish extensions to the mechanism for authorizing an Origin, e.g.
through new kinds of key-signing schemes, ZK proofs, pallet state,
mutations over pre-authenticated origins or any combination of the
above.

`UncheckedExtrinsic` still maintains encode/decode backwards
compatibility with extrinsic version 4, where the first byte was encoded
as:
- 0b00000100 - Unsigned transactions
- 0b10000100 - Old-school Signed transactions, without the extension
version byte

Now, `UncheckedExtrinsic` contains a `Preamble` and the actual call. The
`Preamble` describes the type of extrinsic as follows:
```rust
/// A "header" for extrinsics leading up to the call itself. Determines the type of extrinsic and
/// holds any necessary specialized data.
#[derive(Eq, PartialEq, Clone)]
pub enum Preamble<Address, Signature, Extension> {
	/// An extrinsic without a signature or any extension. This means it's either an inherent or
	/// an old-school "Unsigned" (we don't use that terminology any more since it's confusable with
	/// the general transaction which is without a signature but does have an extension).
	///
	/// NOTE: In the future, once we remove `ValidateUnsigned`, this will only serve Inherent
	/// extrinsics and thus can be renamed to `Inherent`.
	Bare(ExtrinsicVersion),
	/// An old-school transaction extrinsic which includes a signature of some hard-coded crypto.
	/// Available only on extrinsic version 4.
	Signed(Address, Signature, ExtensionVersion, Extension),
	/// A new-school transaction extrinsic which does not include a signature by default. The
	/// origin authorization, through signatures or other means, is performed by the transaction
	/// extension in this extrinsic. Available starting with extrinsic version 5.
	General(ExtensionVersion, Extension),
}
```

## Code Migration

### NOW: Getting it to build

Wrap your `SignedExtension`s in `AsTransactionExtension`. This should be
accompanied by renaming your aggregate type in line with the new
terminology. E.g. Before:

```rust
/// The SignedExtension to the basic transaction logic.
pub type SignedExtra = (
	/* snip */
	MySpecialSignedExtension,
);
/// Unchecked extrinsic type as expected by this runtime.
pub type UncheckedExtrinsic =
	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, SignedExtra>;
```

After:

```rust
/// The extension to the basic transaction logic.
pub type TxExtension = (
	/* snip */
	AsTransactionExtension<MySpecialSignedExtension>,
);
/// Unchecked extrinsic type as expected by this runtime.
pub type UncheckedExtrinsic =
	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, TxExtension>;
```

You'll also need to alter any transaction building logic to add a
`.into()` to make the conversion happen. E.g. Before:

```rust
fn construct_extrinsic(
		/* snip */
) -> UncheckedExtrinsic {
	let extra: SignedExtra = (
		/* snip */
		MySpecialSignedExtension::new(/* snip */),
	);
	let payload = SignedPayload::new(call.clone(), extra.clone()).unwrap();
	let signature = payload.using_encoded(|e| sender.sign(e));
	UncheckedExtrinsic::new_signed(
		/* snip */
		Signature::Sr25519(signature),
		extra,
	)
}
```

After:

```rust
fn construct_extrinsic(
		/* snip */
) -> UncheckedExtrinsic {
	let tx_ext: TxExtension = (
		/* snip */
		MySpecialSignedExtension::new(/* snip */).into(),
	);
	let payload = SignedPayload::new(call.clone(), tx_ext.clone()).unwrap();
	let signature = payload.using_encoded(|e| sender.sign(e));
	UncheckedExtrinsic::new_signed(
		/* snip */
		Signature::Sr25519(signature),
		tx_ext,
	)
}
```

### SOON: Migrating to `TransactionExtension`

Most `SignedExtension`s can be trivially converted to become a
`TransactionExtension`. There are a few things to know.

- Instead of a single trait like `SignedExtension`, you should now
implement two traits individually: `TransactionExtensionBase` and
`TransactionExtension`.
- Weights are now a thing and must be provided via the new function `fn
weight`.

#### `TransactionExtensionBase`

This trait takes care of anything which is not dependent on types
specific to your runtime, most notably `Call`.

- `AdditionalSigned`/`additional_signed` is renamed to
`Implicit`/`implicit`.
- Weight must be returned by implementing the `weight` function. If your
extension is associated with a pallet, you'll probably want to do this
via the pallet's existing benchmarking infrastructure.

#### `TransactionExtension`

Generally:
- `pre_dispatch` is now `prepare` and you *should not reexecute the
`validate` functionality in there*!
- You don't get an account ID any more; you get an origin instead. If
you need to presume an account ID, then you can use the trait function
`AsSystemOriginSigner::as_system_origin_signer`.
- You get an additional ticket, similar to `Pre`, called `Val`. This
defines data which is passed from `validate` into `prepare`. This is
important since you should not be duplicating logic from `validate` to
`prepare`, you need a way of passing your working from the former into
the latter. This is it.
- This trait takes a `Call` type parameter. `Call` is the runtime call
type which used to be an associated type; you can just move it to become
a type parameter for your trait impl.
- There's no `AccountId` associated type any more. Just remove it.

Regarding `validate`:
- You get three new parameters in `validate`; all can be ignored when
migrating from `SignedExtension`.
- `validate` returns a tuple on success; the second item in the tuple is
the new ticket type `Self::Val` which gets passed in to `prepare`. If
you use any information extracted during `validate` (off-chain and
on-chain, non-mutating) in `prepare` (on-chain, mutating) then you can
pass it through with this. For the tuple's last item, just return the
`origin` argument.

Regarding `prepare`:
- This is renamed from `pre_dispatch`, but there is one change:
- FUNCTIONALITY TO VALIDATE THE TRANSACTION NEED NOT BE DUPLICATED FROM
`validate`!!
- (This is different to `SignedExtension` which was required to run the
same checks in `pre_dispatch` as in `validate`.)

Regarding `post_dispatch`:
- Since there are no unsigned transactions handled by
`TransactionExtension`, `Pre` is always defined, so the first parameter
is `Self::Pre` rather than `Option<Self::Pre>`.

If you make use of `SignedExtension::validate_unsigned` or
`SignedExtension::pre_dispatch_unsigned`, then:
- Just use the regular versions of these functions instead.
- Have your logic execute in the case that the `origin` is `None`.
- Ensure your transaction creation logic creates a General Transaction
rather than a Bare Transaction; this means having to include all
`TransactionExtension`s' data.
- `ValidateUnsigned` can still be used (for now) if you need to be able
to construct transactions which contain none of the extension data,
however these will be phased out in stage 2 of the Transactions Horizon,
so you should consider moving to an extension-centric design.

---------

Signed-off-by: default avatargeorgepisaltu <george.pisaltu@parity.io>
Co-authored-by: default avatarGuillaume Thiolliere <gui.thiolliere@gmail.com>
Co-authored-by: default avatarBranislav Kontur <bkontur@gmail.com>
      b76e91ac
  25. Sep 25, 2024
    • Adrian Catangiu's avatar
      xcm-executor: validate destinations for ReserveWithdraw and Teleport transfers (#5660) · b5ac7a9d
      Adrian Catangiu authored 
      
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: default avatarAdrian Catangiu <adrian@parity.io>
Co-authored-by: default avatarBranislav Kontur <bkontur@gmail.com>
      b5ac7a9d
  27. Jul 15, 2024
    • Jun Jiang's avatar
      Remove most all usage of `sp-std` (#5010) · 7ecf3f75
      Jun Jiang authored 
      
This should remove nearly all usage of `sp-std` except:
- bridge and bridge-hubs
- a few of frames re-export `sp-std`, keep them for now
- there is a usage of `sp_std::Writer`, I don't have an idea how to move
it

Please review proc-macro carefully. I'm not sure I'm doing it the right
way.

Note: need `/bot fmt`

---------

Co-authored-by: default avatarBastian Köcher <git@kchr.de>
Co-authored-by: command-bot <>
      7ecf3f75
  29. Jun 24, 2024
    • Oliver Tale-Yazdi's avatar
      Lift all dependencies (the big one) (#4716) · 8efa0544
      Oliver Tale-Yazdi authored 
      
After preparing in https://github.com/paritytech/polkadot-sdk/pull/4633,
we can lift also all internal dependencies up to the workspace.

This does not actually change anything, but uses `workspace = true` for
all dependencies. You can check it with:
```bash
git checkout -q $(git merge-base oty-lift-all-deps origin/master)
cargo tree -e features > master.out

git checkout -q oty-lift-all-deps
cargo tree -e features > new.out
diff master.out new.out
```

It did not yet lift 100% of dependencies, some inside of `target.*` or
some that had conflicting aliases introduced recently. But i will do
these together in a follow-up with CI checks.

Can be reproduced with [zepter](https://github.com/ggwpez/zepter/):
`zepter transpose d lift-to-workspace "regex:.*" --version-resolver
highest --skip-package "polkadot-sdk" --ignore-errors --fix`.

---------

Signed-off-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      8efa0544
  31. Jun 13, 2024
  33. May 16, 2024
    • Francisco Aguirre's avatar
      XCM Cookbook (#2633) · 289f5bbf
      Francisco Aguirre authored 
      # Context

XCM docs are currently an md book hosted with github pages:
https://paritytech.github.io/xcm-docs/.
While that's fine, it's not in line with the work being done in the
polkadot-sdk docs.

# Main addition

This PR aims to fix that by bringing the docs back to this repo.
This does not have all the information currently present in the mdbook
xcm-docs but aims to be a good chunk of it and fully replace it over
time.

I also added the sections `guides` and `cookbook` which will be very
useful for users wanting to get into XCM.
For now I only added one example to the cookbook, but have ideas for
guides and more examples.
Having this docs be in rust docs is very useful for the cookbook.

# TODO

- [x] Use `FungibleAdapter`
- [x] Improve and relocate mock message queue
- [x] Fix license issue. Why does docs/sdk/ not have this problem? (Just
added the licenses)

# Next steps

- More examples in the cookbook
- End-to-end XCM guide with zombienet testing

---------

Co-authored-by: co...
      289f5bbf
  35. May 15, 2024
    • Alexandru Gheorghe's avatar
      Make vscode rustanalyzer fast again (#4470) · e31fcffb
      Alexandru Gheorghe authored 
      
This bump of versions:

https://github.com/paritytech/polkadot-sdk/pull/4409/files#diff-13ee4b2252c9e516a0547f2891aa2105c3ca71c6d7a1e682c69be97998dfc87eR11936

reintroduced a dependency to proc-macro-crate 2.0.0 which is suffering
from: https://github.com/bkchr/proc-macro-crate/pull/42 this, so bump
parity-scale-codec to a newer version to eliminate the bad
proc-macro-crate 2.0.0 dependency.

---------

Signed-off-by: default avatarAlexandru Gheorghe <alexandru.gheorghe@parity.io>
Co-authored-by: command-bot <>
      e31fcffb
  37. May 08, 2024
    • Francisco Aguirre's avatar
      XcmDryRunApi - Dry-running extrinsics to get their XCM effects (#3872) · 7213e363
      Francisco Aguirre authored 
      
# Context

Estimating fees for XCM execution and sending has been an area with bad
UX.
The addition of the
[XcmPaymentApi](https://github.com/paritytech/polkadot-sdk/pull/3607)
exposed the necessary components to be able to estimate XCM fees
correctly, however, that was not the full story.
The `XcmPaymentApi` works for estimating fees only if you know the
specific XCM you want to execute or send.
This is necessary but most UIs want to estimate the fees for extrinsics,
they don't necessarily know the XCM program that's executed by them.

# Main addition

A new runtime API is introduced, the `XcmDryRunApi`, that given an
extrinsic, or an XCM program, returns its effects:
- Execution result
- Local XCM (in the case of an extrinsic)
- Forwarded XCMs
- List of events

This API can be used on its own for dry-running purposes, for
double-checking or testing, but it mainly shines when used in
conjunction with the `XcmPaymentApi`.
UIs can use these two APIs to estimate transfers.

# How it works

New tests are added to exemplify how to incorporate both APIs.
There's a mock test just to make sure everything works under
`xcm-fee-payment-runtime-api`.
There's a real-world test using Westend and AssetHubWestend under
`cumulus/parachains/integration-tests/emulated/tests/assets/asset-hub-westend/src/tests/xcm_fee_estimation.rs`.
Added both a test for a simple teleport between chains and a reserve
transfer asset between two parachains going through a reserve.

The steps to follow:
- Use `XcmDryRunApi::dry_run_extrinsic` to get local XCM program and
forwarded messages
- For each forwarded message
- Use `XcmPaymentApi::query_delivery_fee` LOCALLY to get the delivery
fees
- Use `XcmPaymentApi::query_xcm_weight` ON THE DESTINATION to get the
remote execution weight
- (optional) Use `XcmPaymentApi::query_acceptable_payment_assets` ON THE
DESTINATION to know on which assets the execution fees can be paid
- Use `XcmPaymentApi::query_weight_to_asset_fee` ON THE DESTINATION to
convert weight to the actual remote execution fees
- Use `XcmDryRunApi::dry_run_xcm` ON THE DESTINATION to know if a new
message will be forwarded, if so, continue

# Dear reviewer

The changes in this PR are grouped as follows, and in order of
importance:
- Addition of new runtime API
- Definition, mock and simple tests:
polkadot/xcm/xcm-fee-payment-runtime-api/*
- Implemented on Westend, Asset Hub Westend and Penpal, will implement
on every runtime in a following PR
- Addition of a new config item to the XCM executor for recording xcms
about to be executed
  - Definition: polkadot/xcm/xcm-executor/*
  - Implementation: polkadot/xcm/pallet-xcm/*
- had to update all runtime xcm_config.rs files with `type XcmRecorder =
XcmPallet;`
- Addition of a new trait for inspecting the messages in queues
  - Definition: polkadot/xcm/xcm-builder/src/routing.rs
  - Implemented it on all routers:
    - ChildParachainRouter: polkadot/runtime/common/src/xcm_sender.rs
- ParentAsUmp: cumulus/primitives/utility/src/lib.rs (piggybacked on
implementation in cumulus/pallets/parachain-system/src/lib.rs)
    - XcmpQueue: cumulus/pallets/xcmp-queue/src/lib.rs
    - Bridge: bridges/modules/xcm-bridge-hub-router/src/lib.rs
- More complicated and useful tests:
-
cumulus/parachains/integration-tests/emulated/tests/assets/asset-hub-westend/src/tests/xcm_fee_estimation.rs

## Next steps

With this PR, Westend, AssetHubWestend, Rococo and AssetHubRococo have
the new API.
UIs can test on these runtimes to create better experiences around
cross-chain operations.

Next:
- Add XcmDryRunApi to all system parachains
- Integrate xcm fee estimation in all emulated tests
- Get this on the fellowship runtimes

---------

Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
      7213e363
  39. May 07, 2024
    • Branislav Kontur's avatar
      Add support for versioned notification for HRMP pallet (#4281) · b709dccd
      Branislav Kontur authored 
      
Closes: https://github.com/paritytech/polkadot-sdk/issues/4003 (please
see for the problem description)

## TODO
- [x] add more tests covering `WrapVersion` corner cases (e.g. para has
lower version, ...)
- [x] regenerate benchmarks `runtime_parachains::hrmp` (fix for Rococo
is here: https://github.com/paritytech/polkadot-sdk/pull/4332)

## Questions / possible improvements
- [ ] A `WrapVersion` implementation for `pallet_xcm` initiates version
discovery with
[note_unknown_version](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/pallet-xcm/src/lib.rs#L2527C5-L2527C25),
there is possibility to avoid this overhead in this HRMP case to create
new `WrapVersion` adapter for `pallet_xcm` which would not use
`note_unknown_version`. Is it worth to do it or not?
- [ ] There's a possibility to decouple XCM functionality from the HRMP
pallet, allowing any relay chain to generate its own notifications. This
approach wouldn't restrict notifications solely to the XCM. However,
it's uncertain whether it's worthwhile or desirable to do so? It means
making HRMP pallet more generic. E.g. hiding HRMP notifications behind
some trait:
	```
	trait HrmpNotifications {

		fn on_channel_open_request(
			sender: ParaId,
			proposed_max_capacity: u32,
			proposed_max_message_size: u32) -> primitives::DownwardMessage;

fn on_channel_accepted(recipient: ParaId) ->
primitives::DownwardMessage;

fn on_channel_closing(initiator: ParaId, sender: ParaId, recipient:
ParaId) -> primitives::DownwardMessage;
	}
	```
and then we could have whatever adapter, `impl HrmpNotifications for
VersionedXcmHrmpNotifications {...}`,
	```
	impl parachains_hrmp::Config for Runtime {
	..
		type HrmpNotifications = VersionedXcmHrmpNotifications;
	..
	}
	```

---------

Co-authored-by: command-bot <>
Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      b709dccd
  41. Apr 29, 2024
    • Shawn Tabrizi's avatar
      Refactor XCM Simulator Example (#4220) · 4875ea11
      Shawn Tabrizi authored 
      
This PR does a "developer experience" refactor of the XCM Simulator
Example.

I was looking for existing code / documentation where developers could
better learn about working with and configuring XCM.

The XCM Simulator was a natural starting point due to the fact that it
can emulate end to end XCM scenarios, without needing to spawn multiple
real chains.

However, the XCM Simulator Example was just 3 giant files with a ton of
configurations, runtime, pallets, and tests mashed together.

This PR breaks down the XCM Simulator Example in a way that I believe is
more approachable by a new developer who is looking to navigate the
various components of the end to end example, and modify it themselves.

The basic structure is:

- xcm simulator example
    - lib (tries to only use the xcm simulator macros)
    - tests
    - relay-chain
        - mod (basic runtime that developers should be familiar with)
        - xcm-config
            - mod (contains the `XcmConfig` type
            - various files for each custom configuration  
    - parachain
        - mock_msg_queue (custom pallet for simulator example)
        - mod (basic runtime that developers should be familiar with)
        - xcm-config
            - mod (contains the `XcmConfig` type
            - various files for each custom configuration

I would like to add more documentation to this too, but I think this is
a first step to be accepted which will affect how documentation is added
to the example

---------

Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
Co-authored-by: default avatarKian Paimani <5588131+kianenigma@users.noreply.github.com>
      4875ea11
  43. Apr 23, 2024
    • Branislav Kontur's avatar
      Ensure outbound XCMs are decodable with limits + add `EnsureDecodableXcm`... · 118cd6f9
      Branislav Kontur authored 
      Ensure outbound XCMs are decodable with limits + add `EnsureDecodableXcm` router (for testing purposes) (#4186)

This PR:
- adds `EnsureDecodableXcm` (testing) router that attempts to *encode*
and *decode* passed XCM `message` to ensure that the receiving side will
be able to decode, at least with the same XCM version.
- fixes `pallet_xcm` / `pallet_xcm_benchmarks` assets data generation

Relates to investigation of
https://substrate.stackexchange.com/questions/11288 and missing fix
https://github.com/paritytech/polkadot-sdk/pull/2129 which did not get
into the fellows 1.1.X release.

## Questions/TODOs

- [x] fix XCM benchmarks, which produces undecodable data - new router
catched at least two cases
  - `BoundedVec exceeds its limit`
  - `Fungible asset of zero amount is not allowed`  
- [x] do we need to add `sort` to the `prepend_with` as we did for
reanchor [here](https://github.com/paritytech/polkadot-sdk/pull/2129)?
@serban300 (**created separate/follow-up PR**:
https://github.com/paritytech/polkadot-sdk/pull/4235)
- [x] We added decoding check to `XcmpQueue` -> `validate_xcm_nesting`,
why not to added to the `ParentAsUmp` or `ChildParachainRouter`?
@franciscoaguirre

 (**created separate/follow-up PR**:
https://github.com/paritytech/polkadot-sdk/pull/4236)
- [ ] `SendController::send_blob` replace `VersionedXcm::<()>::decode(`
with `VersionedXcm::<()>::decode_with_depth_limit(MAX_XCM_DECODE_DEPTH,
data)` ?

---------

Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
      118cd6f9
  45. Apr 22, 2024
  47. Apr 02, 2024
  49. Mar 27, 2024
  51. Mar 26, 2024
    • Dcompoze's avatar
      Fix spelling mistakes across the whole repository (#3808) · 002d9260
      Dcompoze authored 
      **Update:** Pushed additional changes based on the review comments.

**This pull request fixes various spelling mistakes in this
repository.**

Most of the changes are contained in the first **3** commits:

- `Fix spelling mistakes in comments and docs`

- `Fix spelling mistakes in test names`

- `Fix spelling mistakes in error messages, panic messages, logs and
tracing`

Other source code spelling mistakes are separated into individual
commits for easier reviewing:

- `Fix the spelling of 'authority'`

- `Fix the spelling of 'REASONABLE_HEADERS_IN_JUSTIFICATION_ANCESTRY'`

- `Fix the spelling of 'prev_enqueud_messages'`

- `Fix the spelling of 'endpoint'`

- `Fix the spelling of 'children'`

- `Fix the spelling of 'PenpalSiblingSovereignAccount'`

- `Fix the spelling of 'PenpalSudoAccount'`

- `Fix the spelling of 'insufficient'`

- `Fix the spelling of 'PalletXcmExtrinsicsBenchmark'`

- `Fix the spelling of 'subtracted'`

- `Fix the spelling of '...
      002d9260
  53. Mar 19, 2024
    • Juan Ignacio Rios's avatar
      Add HRMP notification handlers to the xcm-executor (#3696) · 8b3bf39a
      Juan Ignacio Rios authored 
      
Currently the xcm-executor returns an `Unimplemented` error if it
receives any HRMP-related instruction.
What I propose here, which is what we are currently doing in our forked
executor at polimec, is to introduce a trait implemented by the executor
which will handle those instructions.

This way, if parachains want to keep the default behavior, they just use
`()` and it will return unimplemented, but they can also implement their
own logic to establish HRMP channels with other chains in an automated
fashion, without requiring to go through governance.

Our implementation is mentioned in the [polkadot HRMP
docs](https://arc.net/l/quote/hduiivbu), and it was suggested to us to
submit a PR to add these changes to polkadot-sdk.

---------

Co-authored-by: default avatarBranislav Kontur <bkontur@gmail.com>
Co-authored-by: command-bot <>
      8b3bf39a
  55. Mar 15, 2024
  57. Mar 13, 2024
  59. Mar 04, 2024
  61. Feb 13, 2024
  63. Feb 12, 2024
    • Oliver Tale-Yazdi's avatar
      Lift dependencies to the workspace (Part 1) (#2070) · e80c2473
      Oliver Tale-Yazdi authored 
      Changes (partial https://github.com/paritytech/polkadot-sdk/issues/994):
- Set log to `0.4.20` everywhere
- Lift `log` to the workspace

Starting with a simpler one after seeing
https://github.com/paritytech/polkadot-sdk/pull/2065 from @jsdw

.
This sets the `default-features` to `false` in the root and then
overwrites that in each create to its original value. This is necessary
since otherwise the `default` features are additive and its impossible
to disable them in the crate again once they are enabled in the
workspace.

I am using a tool to do this, so its mostly a test to see that it works
as expected.

---------

Signed-off-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      e80c2473
  65. Feb 08, 2024
    • Louis Merlin's avatar
      Add try_state and integrity_test to XCM simulator fuzzer (#3222) · 84d89e37
      Louis Merlin authored 
      This adds `try_state()` and `integrity_test()` to the four runtimes of
the XCM-simulator fuzzer.

With this, we are able to stress-test [message-queue's
try_state](https://github.com/paritytech/polkadot-sdk/blob/7df1ae3b/substrate/frame/message-queue/src/lib.rs#L1245-L1347).

This also adds the `Transact` block-listing from #2424 to avoid
false-positives.

Thank you @ggwpez for the help with the runtime configurations.
      84d89e37
  67. Jan 31, 2024
    • Branislav Kontur's avatar
      [frame] `#[pallet::composite_enum]` improved variant count handling + removed... · bb8ddc46
      Branislav Kontur authored 
      [frame] `#[pallet::composite_enum]` improved variant count handling + removed `pallet_balances`'s `MaxHolds` config (#2657)

I started this investigation/issue based on @liamaharon

 question
[here](https://github.com/paritytech/polkadot-sdk/pull/1801#discussion_r1410452499).

## Problem

The `pallet_balances` integrity test should correctly detect that the
runtime has correct distinct `HoldReasons` variant count. I assume the
same situation exists for RuntimeFreezeReason.

It is not a critical problem, if we set `MaxHolds` with a sufficiently
large value, everything should be ok. However, in this case, the
integrity_test check becomes less useful.

**Situation for "any" runtime:**
- `HoldReason` enums from different pallets:
```rust
        /// from pallet_nis
        #[pallet::composite_enum]
	pub enum HoldReason {
		NftReceipt,
	}

        /// from pallet_preimage
        #[pallet::composite_enum]
	pub enum HoldReason {
		Preimage,
	}

        // from pallet_state-trie-migration
        #[pallet::composite_enum]
	pub enum HoldReason {
		SlashForContinueMigrate,
		SlashForMigrateCustomTop,
		SlashForMigrateCustomChild,
	}
```

- generated `RuntimeHoldReason` enum looks like:
```rust
pub enum RuntimeHoldReason {

    #[codec(index = 32u8)]
    Preimage(pallet_preimage::HoldReason),

    #[codec(index = 38u8)]
    Nis(pallet_nis::HoldReason),

    #[codec(index = 42u8)]
    StateTrieMigration(pallet_state_trie_migration::HoldReason),
}
```

- composite enum `RuntimeHoldReason` variant count is detected as `3`
- we set `type MaxHolds = ConstU32<3>`
- `pallet_balances::integrity_test` is ok with `3`(at least 3)

However, the real problem can occur in a live runtime where some
functionality might stop working. This is due to a total of 5 distinct
hold reasons (for pallets with multi-instance support, it is even more),
and not all of them can be used because of an incorrect `MaxHolds`,
which is deemed acceptable according to the `integrity_test`:
  ```
  // pseudo-code - if we try to call all of these:

T::Currency::hold(&pallet_nis::HoldReason::NftReceipt.into(),
&nft_owner, deposit)?;
T::Currency::hold(&pallet_preimage::HoldReason::Preimage.into(),
&nft_owner, deposit)?;

T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForContinueMigrate.into(),
&nft_owner, deposit)?;

  // With `type MaxHolds = ConstU32<3>` these two will fail

T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomTop.into(),
&nft_owner, deposit)?;

T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomChild.into(),
&nft_owner, deposit)?;
  ```  


## Solutions

A macro `#[pallet::*]` expansion is extended of `VariantCount`
implementation for the `#[pallet::composite_enum]` enum type. This
expansion generates the `VariantCount` implementation for pallets'
`HoldReason`, `FreezeReason`, `LockId`, and `SlashReason`. Enum variants
must be plain enum values without fields to ensure a deterministic
count.

The composite runtime enum, `RuntimeHoldReason` and
`RuntimeFreezeReason`, now sets `VariantCount::VARIANT_COUNT` as the sum
of pallets' enum `VariantCount::VARIANT_COUNT`:
```rust
#[frame_support::pallet(dev_mode)]
mod module_single_instance {

	#[pallet::composite_enum]
	pub enum HoldReason {
		ModuleSingleInstanceReason1,
		ModuleSingleInstanceReason2,
	}
...
}

#[frame_support::pallet(dev_mode)]
mod module_multi_instance {

	#[pallet::composite_enum]
	pub enum HoldReason<I: 'static = ()> {
		ModuleMultiInstanceReason1,
		ModuleMultiInstanceReason2,
		ModuleMultiInstanceReason3,
	}
...
}


impl self::sp_api_hidden_includes_construct_runtime::hidden_include::traits::VariantCount
    for RuntimeHoldReason
{
    const VARIANT_COUNT: u32 = 0
        + module_single_instance::HoldReason::VARIANT_COUNT
        + module_multi_instance::HoldReason::<module_multi_instance::Instance1>::VARIANT_COUNT
        + module_multi_instance::HoldReason::<module_multi_instance::Instance2>::VARIANT_COUNT
        + module_multi_instance::HoldReason::<module_multi_instance::Instance3>::VARIANT_COUNT;
}
```

In addition, `MaxHolds` is removed (as suggested
[here](https://github.com/paritytech/polkadot-sdk/pull/2657#discussion_r1443324573))
from `pallet_balances`, and its `Holds` are now bounded to
`RuntimeHoldReason::VARIANT_COUNT`. Therefore, there is no need to let
the runtime specify `MaxHolds`.


## For reviewers

Relevant changes can be found here:
- `substrate/frame/support/procedural/src/lib.rs` 
-  `substrate/frame/support/procedural/src/pallet/parse/composite.rs`
-  `substrate/frame/support/procedural/src/pallet/expand/composite.rs`
-
`substrate/frame/support/procedural/src/construct_runtime/expand/composite_helper.rs`
-
`substrate/frame/support/procedural/src/construct_runtime/expand/hold_reason.rs`
-
`substrate/frame/support/procedural/src/construct_runtime/expand/freeze_reason.rs`
- `substrate/frame/support/src/traits/misc.rs`

And the rest of the files is just about removed `MaxHolds` from
`pallet_balances`

## Next steps

Do the same for `MaxFreezes`
https://github.com/paritytech/polkadot-sdk/issues/2997.

---------

Co-authored-by: command-bot <>
Co-authored-by: default avatarBastian Köcher <git@kchr.de>
Co-authored-by: default avatarDónal Murray <donal.murray@parity.io>
Co-authored-by: default avatargupnik <nikhilgupta.iitk@gmail.com>
      bb8ddc46
  69. Jan 26, 2024
  71. Jan 24, 2024
    • dependabot[bot]'s avatar
      Bump arbitrary from 1.3.0 to 1.3.2 (#3037) · b57e53dc
      dependabot[bot] authored 
      
Bumps [arbitrary](https://github.com/rust-fuzz/arbitrary) from 1.3.0 to
1.3.2.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/rust-fuzz/arbitrary/blob/main/CHANGELOG.md">arbitrary's
changelog</a>.</em></p>
<blockquote>
<h2>1.3.2</h2>
<p>Released 2023-10-30.</p>
<h3>Added</h3>
<ul>
<li>Added <code>Arbitrary</code> implementations for
<code>Arc&lt;[T]&gt;</code> and
<code>Rc&lt;[T]&gt;</code>. <a
href="https://redirect.github.com/rust-fuzz/arbitrary/pull/160">#160</a></li>
</ul>
<hr />
<h2>1.3.1</h2>
<p>Released 2023-10-11.</p>
<h3>Fixed</h3>
<ul>
<li>Fixed an issue with generating collections of collections in
<code>arbitrary_take_rest</code> where
<code>&lt;Vec&lt;Vec&lt;u8&gt;&gt;&gt;::arbitrary_take_rest</code> would
never
generate <code>vec![vec![]]</code> for example. See
<a
href="https://redirect.github.com/rust-fuzz/arbitrary/pull/159">#159</a>
for details.</li>
</ul>
<hr />
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/rust-fuzz/arbitrary/commit/66e75c5bf57275d400d3ebc746e0cee4f6ff9596"><code>66e75c5</code></a>
Bump to version 1.3.1</li>
<li><a
href="https://github.com/rust-fuzz/arbitrary/commit/04054dfa1a0f07b233db0581c2d61615df737ade"><code>04054df</code></a>
Merge pull request <a
href="https://redirect.github.com/rust-fuzz/arbitrary/issues/160">#160</a>
from kpreid/arcslice</li>
<li><a
href="https://github.com/rust-fuzz/arbitrary/commit/ef5dff63e4f3079acc6455445f0a8080d4857813"><code>ef5dff6</code></a>
Implement <code>Arbitrary</code> for <code>Arc\&lt;[A]&gt;</code> and
<code>Rc\&lt;[A]&gt;</code>.</li>
<li><a
href="https://github.com/rust-fuzz/arbitrary/commit/b3e8342ea8dc8437aff3d3a1f5b95b7c02bf57f5"><code>b3e8342</code></a>
Bump to version 1.3.1</li>
<li><a
href="https://github.com/rust-fuzz/arbitrary/commit/c1fa740bb777940bda77a4154d035805b4ecce5b"><code>c1fa740</code></a>
Merge pull request <a
href="https://redirect.github.com/rust-fuzz/arbitrary/issues/159">#159</a>
from fitzgen/arbitrary-take-rest-and-collections-of-c...</li>
<li><a
href="https://github.com/rust-fuzz/arbitrary/commit/f19fd7a512fe953e902954d01fe046475d8f01a7"><code>f19fd7a</code></a>
Add clippy allow for existing code running afoul of new clippy lint</li>
<li><a
href="https://github.com/rust-fuzz/arbitrary/commit/27560f182b5f0feb8dbd70791cbadd6fbd622411"><code>27560f1</code></a>
Fix <code>Unstructured::arbitrary_take_rest_iter</code> for collections
of collections</li>
<li><a
href="https://github.com/rust-fuzz/arbitrary/commit/80d6bfe5e8c864a05ed8c1f0a107bca632ea8c61"><code>80d6bfe</code></a>
Merge pull request <a
href="https://redirect.github.com/rust-fuzz/arbitrary/issues/157">#157</a>
from jyn514/ip-addr</li>
<li><a
href="https://github.com/rust-fuzz/arbitrary/commit/7d3364edb6a39554c4b97f0d0548289f001121fe"><code>7d3364e</code></a>
impl Arbitrary for IpAddr</li>
<li><a
href="https://github.com/rust-fuzz/arbitrary/commit/0bdbec8a9fdf19a18e6cb8ffe4022b9a6a588cf2"><code>0bdbec8</code></a>
Merge pull request <a
href="https://redirect.github.com/rust-fuzz/arbitrary/issues/151">#151</a>
from Ekleog-NEAR/patch-2</li>
<li>Additional commits viewable in <a
href="https://github.com/rust-fuzz/arbitrary/compare/v1.3.0...v1.3.2">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=arbitrary&package-manager=cargo&previous-version=1.3.0&new-version=1.3.2)](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 <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: default avatardependabot[bot] <support@github.com>
Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      b57e53dc
    • Just van Stam's avatar
      Transactional processing for XCM (#1222) · 50eb12cf
      Just van Stam authored 
      
Moved from: https://github.com/paritytech/polkadot/pull/6951

closes https://github.com/paritytech/polkadot-sdk/issues/490

- [x] update cumulus

--- 
This PR introduces transactional processing of certain xcm instructions.
For the list of instructions checkout
https://github.com/paritytech/polkadot-sdk/issues/490. The transactional
processing is implemented as an xcm-executor config item. The two
implementations in this PR are `FrameTransactionalProcessor` and `()`.
The `()` implementation does no transactional processing. Each
implementation of the `ProcessTransaction` trait has an
`IS_TRANSACTIONAL` const that tells the XCVM if transactional processing
is actually implemented. If Transactional processing is implemented,
changes to touched registers should also be rolled back to prevent
inconsistencies.


Note for reviewers:
Check out the following safety assumption:
https://github.com/paritytech/polkadot-sdk/pull/1222/files#diff-4effad7d8c1c9de19fd27e18661cbf2128c8718f3b2420a27d2f816e0749ea53R30

---------

Co-authored-by: default avatarKeith Yeung <kungfukeith11@gmail.com>
Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
Co-authored-by: command-bot <>
      50eb12cf
  73. Jan 22, 2024
  75. Jan 18, 2024