Skip to content
Unverified Commit 86542d6e authored by Adrian Catangiu's avatar Adrian Catangiu Committed by GitHub
Browse files

[xcm-v5] implement RFC#122: InitiateTransfer can alias XCM original origin on destination (#5971)



Built on top of https://github.com/paritytech/polkadot-sdk/pull/5876

# Description

Currently, all XCM asset transfer instructions ultimately clear the
origin in the remote XCM message by use of the `ClearOrigin`
instruction. This is done for security considerations to ensure that
subsequent (user-controlled) instructions cannot command the authority
of the sending chain.

The problem with this approach is that it limits what can be achieved on
remote chains through XCM. Most XCM operations require having an origin,
and following any asset transfer the origin is lost, meaning not much
can be done other than depositing the transferred assets to some local
account or transferring them onward to another chain.

For example, we cannot transfer some funds for buying execution, then do
a `Transact` (all in the same XCM message).

In the case of XCM programs going from source-chain directly to
dest-chain without an intermediary hop, we can enable scenarios such as
above by using the AliasOrigin instruction instead of the ClearOrigin
instruction.

Instead of clearing the source-chain origin, the destination chain shall
attempt to alias source-chain to "original origin" on the source chain.
Most common such origin aliasing would be X1(Parachain(source-chain)) ->
X2(Parachain(source-chain), AccountId32(origin-account)) for the case of
a single hop transfer where the initiator is a (signed/pure/proxy)
account origin-account on source-chain. This is equivalent to using the
DescendOrigin instruction in this case, but also usable in the multi hop
case.

This allows an actor on chain A to Transact on chain B without having to
prefund its SA account on chain B, instead they can simply transfer the
required fees in the same XCM program as the Transact.

As long as the asset transfer has the same XCM route/hops as the rest of
the program, this pattern of usage can be composed across multiple hops,
to ultimately Transact on the final hop using the original origin on the
source chain, effectively abstracting away any intermediary hops.

### XCM `InitiateAssetsTransfer` instruction changes

A new parameter `preserve_origin` to be added to the
`InitiateAssetsTransfer` XCM instruction that specifies if the original
origin should be preserved or cleared.

```diff
InitiateAssetsTransfer {
	destination: Location,
	assets: Vec<AssetTransferFilter>,
	remote_fees: Option<AssetTransferFilter>,
+	preserve_origin: bool,
	remote_xcm: Xcm<()>,
}
```

This parameter is explicitly necessary because the instruction should be
usable between any two chains regardless of their origin-aliasing trust
relationship. Preserving the origin requires some level of trust, while
clearing it works regardless of that relationship.
Specifying `preserve_origin: false` will always work regardless of the
configured alias filters of the
involved chains.

# Testing

- [x] e2e test: User on PenpalA registers foreign token (transacts) on
PenpalB through XCM, while paying all fees using USDT (meaning XCM has
to go through AssetHub) - AH carries over the original origin,
effectively being a transparent proxy,
- [x] e2e test: User/contract on Ethereum registers foreign token
(transacts) on Polkadot-PenpalA through XCM (over bridge), while paying
all fees using DOT (has to go through AssetHub) - AH carries over the
original origin, effectively being a transparent proxy for Ethereum,

---------

Signed-off-by: default avatarAdrian Catangiu <[email protected]>
Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
Co-authored-by: default avatarBranislav Kontur <[email protected]>
parent a1b8381e
Pipeline #503369 waiting for manual action with stages
in 23 minutes and 24 seconds
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment