transfer_with_transact impl - iteration 2

[ghzlatarev]

Signed-off-by: Georgi Zlatarev [email protected]

Design discussion at open-web3-stack#766 .

• Manta's concrete use-case is for front-end dApps (including ours) to be able to transfer any public asset from any chain to Manta and privatize them in one call. So the steps would be like below:
  • ParachainA (on user's behalf, say Alice) sends an XCM message containing both the ParachainA token transfer request and Transact with Manta's to_private extrinsic.
  • Manta, upon receiving ParachainA's message, directly mint the correct amount of pParachainA (private ParachainA token) to Alice's account and dispatch the to_private call with it.

How the code change from first iteration:

• Made the Transact input encoded call data bounded.
• Added an example receiver Barrier that expects the exact set of instrucitons DescendOrigin + WithdrawAsset + BuyExecution + Transact + RefundSurplus + DepositAsset
• Added 3 test cases to illustrate the functionality transacting a remark call after a self-reserve, to-rserve, and to-non-reserve transfers
• Added a transact-only extrinsic, which does the transact without the transfer, to reduce fees.
• Added initial docs
• Added extrinsic weights for the orml extrinsics

Current stage of code is that the sender sends 2 xcm messages:

1. First is token transfer to a sender derivative account.
   1.1. Sender derivative account is crated from the sender multilocation as seen by the receiver chain.
   1.2. Concretely in the mock runtime and tests the multilocation is simply hashed via a blak256 hasher Account32Hash
2. Xcm message with 6 instructions. What happens on the receiver side is:
   2.1 DescendOrigin is used to descend into a unique sender origin, which was used to create the sender derivative account in the first message.
   2.2. WithdrawAsset is used to withdraw the funds sent with the first xcm message.
   2.3. BuyExecution is used to buy execution time.
   2.4. The sender derivative account is also used as local origin to dispatch the call within the Transact instruction.
   2.5. RefundSurplus + DepositAsset is used to deposit any change.

TODOs:

-todo: This code is also similar to this idea https://gist.github.com/xlc/ebc2476afb7ecacdaa5ce95ae3b991c8#xcm-builder and similarly could use a more comprehensive solution to calculate weights on the sender side.
-todo: barrier code can be improved by checking the length of the encoded call data
-todo: in barrier code if we can decode a Call then it can be matched against a configurable set of allowed Calls
-todo: in the barrier code we can can do weight and fee checks of the decoded call via query_call_info and query_call_fee_details paritytech/substrate#11819
-todo: deposit change into any account

---

TODOs:

• bounded input
• workaround the fact that the limit can't be less than u32 --> made it a pallet constant, not configurable for now
• separate dest_weight for Transact

---

• transact_only extrinsic

---

• refund surplus
• add to transact_only as well

---

• transfer_with_transact tests
• assert with the user sovereign account as well
• relative view tests
• transact-only tests

---

• orml weights

---

• barrier

• should work with Limited and Unlimited dest_weight

• expect the Transact instruction

• inspect Transact - check encoded length, for this I need a small PR to polkadot to get encoded.len()

• inspect Transact - take_decode() and match against allowed calls, can be configurable set

• expect the refund instructions as well

---

• min-xcm-fee case -> no need when only 1 currency is transferred

---

• documentation

---

• manta tests