Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

how to transfer native assets between two relaychain account from parachain side? #3500

Closed
yrong opened this issue Jul 20, 2021 · 8 comments
Closed

Comments

@yrong
Copy link

yrong commented Jul 20, 2021

the requirement here is just to transfer some ksm from relaychain accountA to accountB, but instead of straightforwardly using polkadot js I would like to invoke from parachain, currently I'm using [cumlulus ParentAsUmp route] (https://github.com/yrong/bifrost/blob/167d8eadd0c5de6cd9d5b2e38f3483a987b6557a/runtime/asgard/src/lib.rs#L767) to send message but the problem is that origin contains only parachain account and the source accountId part missing.

Then I notice that there is RelayedFrom xcm format which will keep the original accountId so I wrap a xcmp call with TransferAsset embed in RelayedFrom message

And then another issue comes is that current polkadot xcm executor can not extract accountId in RelayedFrom message with the default accountId convertor so do some hack in extension of SovereignAccountOf types to achieve that.

The whole hack is in this commit and after all above steps I can transfer assets from parachain side but I would like to know is this the proper way or is there any way without hacking the current polkadot implementation?

@bkchr
Copy link
Member

bkchr commented Jul 20, 2021

CC @apopiak

@apopiak
Copy link
Contributor

apopiak commented Jul 20, 2021

I don't expect the relaychain to trust a community chain enough to give it control over its accounts directly like this.
If I understand what you want to do correctly, a parachain could take control of e.g. the treasury account which we would want to avoid ;-)
The scenario that will be supported will likely be the following:
There could be a deterministic account id generated (e.g. sth like hash(parachain id, parachain account)) for origins coming from parachains. You could then send funds to that generated id and remote control it from the parachain.

@yrong
Copy link
Author

yrong commented Jul 20, 2021

@apopiak thanks for the reply. Let me explain the background a little bit, we are bifrost and one of our service is to help other parachains to participant crowdloan with assets locked while still provide liquidity in the form of Staking derivatives. Currently we're using multi-signer to achieve it and you can check description here

In next step we would like to replace the multi-signer with xcmp which require 2 steps. First a xcm transfer call to transfer some ksm directly from personal account to the parachain account in relaychain side. Then a transact call to contribute to fund with the parachain account. You may check some code snippet for detail.

Since we act only as a crowdloan contribute proxy here we do not want to ask people to send their native ksm assets to our parachain first which maybe is what you suggest here if I understand correctly.

The current hacks we made are just some temporarily workrounds but from what @gavofyork last time clarified my understanding is that such restrictions will be relaxed sooner or later so our solution is technically feasible.

image

image (6)

So I would like to know is their any other way to achieve it without sacrificing the security?

@apopiak
Copy link
Contributor

apopiak commented Jul 20, 2021

[...] First a xcm transfer call to transfer some ksm directly from personal account to the parachain account in relaychain side. [...]

As mentioned above: This will not be possible. AFAICT parachains will not be able to transact as arbitrary accounts on the relaychain.

Since we act only as a crowdloan contribute proxy here we do not want to ask people to send their native ksm assets to our parachain first which maybe is what you suggest here if I understand correctly.

I suggest they send it to an account id that does not have an associated private key and can only be controlled via XCM from your parachain, thus opting in to your parachain controlling these funds.

The current hacks we made are just some temporarily workrounds but from what @gavofyork last time clarified my understanding is that such restrictions will be relaxed sooner or later so our solution is technically feasible.

image

image (6)

Note that this only says that you can lift these kinds of limitations earlier on a parachain instead of the relaychain.

So I would like to know is their any other way to achieve it without sacrificing the security?

Well I gave a sketch of my suggested solution above. I'll try to sketch something in a PR to give you a better idea.

@yrong
Copy link
Author

yrong commented Jul 21, 2021

@apopiak appreciate for your clarification and now I understand the relaychain asset transfer from parachain is not doable.

For the derivated account you provided in #3505 since we've already stored each contribution in child trie same as what crowdloan module does so with ump transact all contribution origin from the proxy parachain account is ok

@apopiak
Copy link
Contributor

apopiak commented Jul 21, 2021

I talked more with Gav about this usecase and want to clarify that we don't plan on adding derived accounts, so my suggested strategy would not work.

@yrong
Copy link
Author

yrong commented Jul 22, 2021

@apopiak Thanks for your effort and hope parity can lift the current limations in xcmp as soon as possible which we believe will promote our polka ecosystem a lot

@apopiak
Copy link
Contributor

apopiak commented Jul 22, 2021

👍 It will definitely be opened some, but generic relaychain accounts will not be able to be controlled from parachains.
Feel free to open an issue for the particular calls you would like to be able to call via Transact and the data you want to be able to read out.

Closing this.

@apopiak apopiak closed this as completed Jul 22, 2021
yrong added a commit to yrong/polkadot that referenced this issue Jul 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants