New Westend/Rococo runtimes not allowing `polkadotXcm.send` from Reg Accounts

[albertov19]

As shown in this PR -> https://github.com/paritytech/polkadot-sdk/pull/1177

https://github.com/paritytech/polkadot-sdk/blob/a9474a6f4b31d4fe66c2f2a590ed60f6938e17dc/polkadot/runtime/rococo/src/xcm_config.rs#L241

The new Rococo/Westend runtimes change the SendXcmOrigin pallet config so that now polkadotXcm.send can be only called by LocalPalletOriginToLocation (besides RuntimeOrigin). Before, it had LocalOriginToLocation.

In a lot of our testings/demos we relied LocalOriginToLocation because it helped us test on Moonbeam our remote origins converter.

cc @al3mart

[al3mart]

Hey, after speaking offline with @albertov19 about their need to dispatch the pallet-xcm::send call with different origins, I asked him to open this issue to see if there might be any further concerns about reverting that change.

Rococo has always tried to follow Kusama as closely as possible, with its difference in some configurations to provide a friendlier testing experience, for instance some of the periods configured in its runtime are shorter.

This scenario might be one of these where it might make sense to differ for dev ex purposes and accommodate for how its users are interfacing with the chain.

My main concern is creating precedents of something being possible to do, not being the case in production, and maybe catching a handful of users with low guard and expecting a similar experience when moving to Kusama or Polkadot.

[girazoki]

Is it the case that something like this will never reach Kusama or Polkadot? In my opinion this a valid case like any other one with XCM: a user sending (with a descended origin) a message to another consensus system.

I think the issue here is more on how the receiving chain handles this origins, and maybe what we should focus on is on creating good documentation on how the receiving change should convert this descended origin into an account.

[albertov19]

To add to what @girazoki said - I completely agree that this should be brought up to Kusama and then Polkadot down the road. This will open up the possibility of users in Polkadot/Kusama to interact with parachains without needing to actually move around the ecosystem, improving UX by a lot!!!

It is important to open up some of the barriers that are constraining XCM usability and teams to build more user friendly XCM-based solutions.

[muharem]

@albertov19 can you explain your use case? if it is not production test cases or demo, I believe it should be done in some dev/demo/test environment. If they are, they should fail, as they would fail in prod/kusama. otherwise rococo/westend cannot be considered as a staging environment.

[albertov19]

@muharem - Our Relay Chain that we run for Moonbase Alpha is based in Westend. Before the PR in question, we would use the relay chain to do all sort of XCM Transact tests, with this new change they all fail.

But just besides that. Why limit the use of polkadotXcm.send? Even in Kusama/Polkadot? Let parachain teams decide how they process DescendOrigin. This unlocks new usecases with computed origins that can unlock more decentralized ways of doing things from the Polkadot Relay chain. Just thinking for example, provide a more trustless solution for Liquid Staking offerings without having users to switch around chains.

Initially it was thought that it was enabled on Westend/Rococo because it was a feature that was going to be available down the road. And it is a very powerful feature. HydraDX and Moonbeam and using DescendOrigin to do remote EVM calls via XCM to enable MRL flows for example. We are talking about real world usage of this things, beyond token transfers that is trivial at this point.

[muharem]

@albertov19 what I am trying to understand, if it is reasonable to temporarily return a prev config to fix things on your side and unblock you. and for not it seems like you are using rococo/westend like a sandbox env, but not like staging.

regarding you the limits for xcm send, I cannot answer. and that worth a separate issue, I would be interested also to see xcm teams' considerations on it and plans.

[albertov19]

@muharem we have staging environments that are using the actual Kusama and Polkadot environments that we use for staging 😉 - We use Westend as the environment for our relay chain in our Testnet.

Either way, I don't believe that your argument of Westend being a staging environment to Kusama is not really that valid because Westend implements paraSudoWrapper or sudo pallet. So it is indeed still a testing environment for some things.

PolkadotXcm.send has been around in Westend for some time and maybe some teams were using it like us to test some scenarios like computed origins for XCM messages with DescendOrigin. Removing it arbitrarily without checking seems rushed

My 2 cents. Let us know if you'll consider bringing this back. On the contrary, as always, we'll have to adapt our tutorials, tests and flows

Thanks

[girazoki]

I am going to go a bit beyond what @albertov19 said, I always expected Westend and Rococo to have those features that at some point would reach Kusama. Clear examples are, e.g., asynchronous backing. In my opinon it is difficult to argue that XCM is valuable without the possibility of sending arbitrary messages, and removing this at all from the scope is dissappointing for us to be honest.

[muharem]

it make sense to me what you saying. may be we should first have a clear definition what everyone should expect from those environments.

[al3mart]

I have proposed reverting the configuration here: https://github.com/paritytech/polkadot-sdk/pull/2571

[albertov19]

Thanks @al3mart