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

Descend XCM origin instead of clearing it where possible #109

Closed

Conversation

acatangiu
Copy link
Contributor

XCM programs that want to ensure that the following XCM instructions cannot command the authority of the Original Origin (such as asset transfer programs) should consider, where possible, using DescendOrigin into a demoted, safer origin rather than ClearOrigin which clears the origin completely.

XCM programs that want to ensure that the following XCM instructions
cannot command the authority of the Original Origin (such as asset
transfer programs) should consider, where possible, using DescendOrigin
into a demoted, safer origin rather than ClearOrigin which clears the
origin completely.

Signed-off-by: Adrian Catangiu <adrian@parity.io>
@acatangiu
Copy link
Contributor Author

cc @albertov19 @xlc

@albertov19
Copy link

@acatangiu - We still need to push a standard for remote origin calculation among chains. There were a lot of discussions back in the day, and a standard was set, but the standard has not been implemented in either the Relay Chain or System Chains.

@acatangiu
Copy link
Contributor Author

There were a lot of discussions back in the day, and a standard was set, but the standard has not been implemented in either the Relay Chain or System Chains.

I'm not aware of this. I think this was "before my time", can you help link some issues/discussions/etc?

@albertov19
Copy link

albertov19 commented Jul 24, 2024

There were a lot of discussions back in the day, and a standard was set, but the standard has not been implemented in either the Relay Chain or System Chains.

I'm not aware of this. I think this was "before my time", can you help link some issues/discussions/etc?

Original PR and Discussions -> paritytech/polkadot#6662
Gav's PR -> paritytech/polkadot#7329
Moonbeam introducing the standard -> moonbeam-foundation/moonbeam#2344

Also saw this discussion -> polkadot-fellows/runtimes#67

@acatangiu
Copy link
Contributor Author

@acatangiu - We still need to push a standard for remote origin calculation among chains.

I think that's orthogonal to this RFC - the mechanism proposed here works regardless of the remote origin calculation mechanism.

But looking at the state of the ecosystem, seems we are going towards alignment, although many parachains don't seem to care about this conversion and have no hashed description configured:

(non-exhaustive list)

@albertov19
Copy link

@acatangiu - We still need to push a standard for remote origin calculation among chains.

I think that's orthogonal to this RFC - the mechanism proposed here works regardless of the remote origin calculation mechanism.

But looking at the state of the ecosystem, seems we are going towards alignment, although many parachains don't seem to care about this conversion and have no hashed description configured:

(non-exhaustive list)

Agreed - but the standard would solidify if system chains and the relay chain would implement it. Also, those chains filter polkadotXcm.send so we can't do remote origin things from Relay Chain to Moonbeam for example.

@acatangiu
Copy link
Contributor Author

Agreed - but the standard would solidify if system chains and the relay chain would implement it.

But they already do implement it. All System Chains (Relay included) on both Kusama and Polkadot include a HashedDescription<AccountId, DescribeFamily<DescribeAllTerminal>> location to AccountId convertor.

Also, those chains filter polkadotXcm.send so we can't do remote origin things from Relay Chain to Moonbeam for example.

I checked and indeed the XCM send filter (SendXcmOrigin) could be relaxed for system chains, but we should do so with usecases in mind, not just for configuration alignment purposes. In particular, I would allow SignedOrigins to send arbitrary XCMs from Relay and Asset Hub, but I don't see any point for it in Bridge Hub, or Collectives for example.

Either way, like I said before this is orthogonal to this RFC, no?

@albertov19
Copy link

Agreed - but the standard would solidify if system chains and the relay chain would implement it.

But they already do implement it. All System Chains (Relay included) on both Kusama and Polkadot include a HashedDescription<AccountId, DescribeFamily<DescribeAllTerminal>> location to AccountId convertor.

Also, those chains filter polkadotXcm.send so we can't do remote origin things from Relay Chain to Moonbeam for example.

I checked and indeed the XCM send filter (SendXcmOrigin) could be relaxed for system chains, but we should do so with usecases in mind, not just for configuration alignment purposes. In particular, I would allow SignedOrigins to send arbitrary XCMs from Relay and Asset Hub, but I don't see any point for it in Bridge Hub, or Collectives for example.

Either way, like I said before this is orthogonal to this RFC, no?

Agreed - I just saw DescendOrigin and wanted to bring this up haha

@anaelleltd anaelleltd added the Proposed Is awaiting 3 formal reviews. label Sep 16, 2024

## Unresolved Questions

How to achieve this for all workflows, not just point-to-point XCM programs with no intermediary hops?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is how to do it:

#122

@acatangiu
Copy link
Contributor Author

Closing this in favor of more extensible #122

@acatangiu acatangiu closed this Sep 17, 2024
@anaelleltd anaelleltd removed the Proposed Is awaiting 3 formal reviews. label Sep 18, 2024
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.

3 participants