Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow signed origins to send arbitrary XCMs from some system chains #407

Merged

Conversation

acatangiu
Copy link
Contributor

@acatangiu acatangiu commented Jul 26, 2024

Relaxing the SendXcmOrigin filter for some of the System chains:

  • Relay Kusama: already open to signed origins and pluralities ✅

  • Relay Polkadot: relax to same level as Kusama ^ ✅

  • Asset Hubs (P and K): open up to signed origins ✅

  • People (P and K): allow signed origins ✅

  • Encointer: allow signed origins ✅

  • Collectives Polkadot: no change, only Fellows collective allowed ❌

  • Bridge Hubs (P and K): no change, no arbitrary XCM sends allowed ❌

  • Coretime (P and K): no change, no arbitrary XCM sends allowed ❌

We could allow it on all chains but on some of them there are no usecases afaict, so starting out conservative, opening it up only on chains where it's wanted.

Relaxing the `SendXcmOrigin` filter for some of the System chains:
- Relay Kusama: already open to signed origins and pluralities
- Relay Polkadot: relax to same level as Kusama ^

- Asset Hubs (P and K): open up to signed origins
- People (P and K): allow signed origins
- Encointer: allow signed origins

- Collectives Polkadot: no change, only Fellows collective allowed
- Bridge Hubs: no change, no arbitrary XCM sends allowed
- Coretime Kusama: no change, no arbitrary XCM sends allowed

We could allow it on all chains but on some of them there are no
usecases afaict, so starting out conservative, opening it up only
on chains where it's wanted.
@acatangiu
Copy link
Contributor Author

Coretime Kusama: no change, no arbitrary XCM sends allowed

Maybe from Coretime chain there would be users that want to Transact to other chains from their signed accounts?

@acatangiu
Copy link
Contributor Author

@joepetrowski WDYT about current list?

@acatangiu
Copy link
Contributor Author

Coretime Kusama: no change, no arbitrary XCM sends allowed

Maybe from Coretime chain there would be users that want to Transact to other chains from their signed accounts?

cc @seadanda

@joepetrowski
Copy link
Contributor

The list looks reasonable to me. Will let @seadanda chime in.

@seadanda
Copy link
Contributor

List looks fine to me too, I don't see any immediate usecase for arbitrary Transacts.
It might be useful to check with Lastic and RegionX to see if they plan to make use of functionality like that.
@poppyseedDev @Szegoo

@Szegoo
Copy link
Contributor

Szegoo commented Aug 15, 2024

No use cases from our side so far, but there could potentially be some, so I wouldn't be against it.

@poppyseedDev
Copy link

Same opinion as @Szegoo here.

@acatangiu
Copy link
Contributor Author

acatangiu commented Aug 22, 2024

@joepetrowski @seadanda @Szegoo @poppyseedDev what about a full(ish) review?

relay/polkadot/src/xcm_config.rs Outdated Show resolved Hide resolved
@acatangiu
Copy link
Contributor Author

@kianenigma @shawntabrizi @xlc need another review here please

@acatangiu
Copy link
Contributor Author

/merge

@fellowship-merge-bot fellowship-merge-bot bot enabled auto-merge (squash) September 5, 2024 08:43
@fellowship-merge-bot
Copy link
Contributor

Enabled auto-merge in Pull Request

Available commands
  • /merge: Enables auto-merge for Pull Request
  • /merge cancel: Cancels auto-merge for Pull Request
  • /merge help: Shows this menu

For more information see the documentation

@fellowship-merge-bot fellowship-merge-bot bot merged commit fac5569 into polkadot-fellows:main Sep 5, 2024
47 checks passed
@acatangiu acatangiu deleted the relax-xcm-send-filter branch September 5, 2024 10:03
ntn-x2 added a commit to KILTprotocol/kilt-node that referenced this pull request Oct 8, 2024
Fixes KILTprotocol/ticket#3625.

# Description

* Removed the requirement that the pool must be enabled (i.e., not
stopped) for the XCM `Matcher` implementation to work. The matcher
should not really care about that. All other XCM components have not
changed.
* Add a new storage map to the switch pallet to track pending switches.
The storage is updated either when calling `switch`, or when receiving a
query response, which deletes entries from the map, as defined by the
`OnResponse` implementation of the pallet itself.
* Two more events for transfer finalisation and reversal have been
added.
* One error thrown when setting up a new pair with previous pending
transfers still in storage is also added.
* The pallet takes two more config items that aid in the error recovery
process.
* The XCM message sent to destination has changed. It now does the
transfer as two distinct steps withdraw + deposit, where the second
could fail. In either case, a report message is sent back to the source
chain that will handle it accordingly.
* I updated existing tests to check for the new storage map, and wrote
tests for the `OnResponse` implementation.
* I added a few support types and traits both in `runtime-common` and
`kilt-support`.

I will refactor the code in a different PR, where I will also tackle
KILTprotocol/ticket#3628.

## How to test

You can run a Chopsticks environment, set up a switch pair, and try to
do a switch for an account that has enough KILTs but has no ED on
AssetHub. The operation will eventually fail and the transfer will be
reverted back on KILT. A revert event is generated.
You can also test a correct transfer, which will behave as before, while
removing the pending transfer storage entry and generating an event for
the transfer finalization.

## TODO

- [x] Add runtime logic
- [x] Test happy case with Chopsticks
- [x] Update unit tests to check for the new storage entries
- [x] Test with upcoming runtime allowing signed origins to send XCM
messages ([PR](polkadot-fellows/runtimes#407))
- [x] Update the hook trait to account for the new state a switch can be
in
- [x] Add unit tests for the new feature
- [x] Update relevant calls, tests and benchmarks to clean up the
additional storage
- [x] Add event and tests when transfer is finally confirmed
- [x] Test case when pair is paused with pending confirmations with
Chopsticks
- [x] Review XCM components to allow more things while the switch pair
is paused (to accommodate the new revert capabilities)
- [x] Update docs
- [x] Revise log messages and log levels
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants