Descend XCM origin instead of clearing it where possible #109
Conversation
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>
|
cc @albertov19 @xlc |
|
@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. |
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 Also saw this discussion -> polkadot-fellows/runtimes#67 |
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 |
But they already do implement it. All System Chains (Relay included) on both Kusama and Polkadot include a
I checked and indeed the XCM send filter ( Either way, like I said before this is orthogonal to this RFC, no? |
Agreed - I just saw |
|
|
||
| ## Unresolved Questions | ||
|
|
||
| How to achieve this for all workflows, not just point-to-point XCM programs with no intermediary hops? |
There was a problem hiding this comment.
This is how to do it:
|
Closing this in favor of more extensible #122 |
…structions The AllowTopLevelPaidExecutionFrom allows ClearOrigin instructions before the expected BuyExecution instruction, it also allows messages without any origin altering instructions. This commit enhances the barrier to also support messages that use AliasOrigin, or DescendOrigin. This is sometimes desired in asset transfer XCM programs that need to run the inbound assets instructions using the origin chain root origin, but then want to drop privileges for the rest of the program. Currently these programs drop privileges by clearing the origin completely, but that also unnecessarily limits the range of actions available to the rest of the program. Using DescendOrigin or AliasOrigin allows the sending chain to instruct the receiving chain what the deprivileged real origin is. See polkadot-fellows/RFCs#109 and polkadot-fellows/RFCs#122 for more details on how DescendOrigin and AliasOrigin could be used instead of ClearOrigin. Signed-off-by: Adrian Catangiu <adrian@parity.io>
…structions The AllowTopLevelPaidExecutionFrom allows ClearOrigin instructions before the expected BuyExecution instruction, it also allows messages without any origin altering instructions. This commit enhances the barrier to also support messages that use AliasOrigin, or DescendOrigin. This is sometimes desired in asset transfer XCM programs that need to run the inbound assets instructions using the origin chain root origin, but then want to drop privileges for the rest of the program. Currently these programs drop privileges by clearing the origin completely, but that also unnecessarily limits the range of actions available to the rest of the program. Using DescendOrigin or AliasOrigin allows the sending chain to instruct the receiving chain what the deprivileged real origin is. See polkadot-fellows/RFCs#109 and polkadot-fellows/RFCs#122 for more details on how DescendOrigin and AliasOrigin could be used instead of ClearOrigin. Signed-off-by: Adrian Catangiu <adrian@parity.io>
…#5917) The AllowTopLevelPaidExecutionFrom allows ClearOrigin instructions before the expected BuyExecution instruction, it also allows messages without any origin altering instructions. This commit enhances the barrier to also support messages that use AliasOrigin, or DescendOrigin. This is sometimes desired in asset transfer XCM programs that need to run the inbound assets instructions using the origin chain root origin, but then want to drop privileges for the rest of the program. Currently these programs drop privileges by clearing the origin completely, but that also unnecessarily limits the range of actions available to the rest of the program. Using DescendOrigin or AliasOrigin allows the sending chain to instruct the receiving chain what the deprivileged real origin is. See polkadot-fellows/RFCs#109 and polkadot-fellows/RFCs#122 for more details on how DescendOrigin and AliasOrigin could be used instead of ClearOrigin. --------- Signed-off-by: Adrian Catangiu <adrian@parity.io>
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.