-
Notifications
You must be signed in to change notification settings - Fork 296
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
relay account and tests #651
base: master
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## master #651 +/- ##
==========================================
- Coverage 76.02% 75.99% -0.04%
==========================================
Files 78 78
Lines 6557 6644 +87
==========================================
+ Hits 4985 5049 +64
- Misses 1572 1595 +23
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to add this struct in orml-xcm-support
? It looks like a runtime config to me.
it is something to be used by all the runtime and potentially used by other parachains. |
xcm-support/src/lib.rs
Outdated
Ok(AccountId32 { | ||
id: who.into(), | ||
network: Network::get(), | ||
} | ||
.into()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will reverse to MultiLocation { parents: 0, interior: X1(AccountId32), }
, no?
That means it will not convert back to the input if calling RelaychainAccountId32Aliases.convert(location).reverse()
which would be desirable, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a good point, as the reverse path is not currently go through, I may miss here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
after I change here to return (1, AccountId32).into()
. If we config (...,AccountId32Aliases,RelaychainAccountId32Aliases)
, then reverse on AccountId
will always return (parents:0, X1(AccountId32))
. But when I change the order to (...,RelaychainAccountId32Aliases, AccountId32Aliases)
, then reverse on AccountId
will always return (parents:1, X1(AccountId32))
. this sounds no better solution if those two config has same trait bounds, unless we make them different.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've post an issue on polkadot: paritytech/polkadot#4296. would you mind to see if that's a potential problem? @KiChjang @apopiak
current the xcm format is in my testcase the event below shows that there're 0.016 used as fee payment, and 0.98 KSM lefted in AssetsTrapped:
|
Yeah we should allow Also maybe should support |
it's easy add e.g. relaychain has xcm format let alice = X1(Junction::AccountId32 {
network: NetworkId::Kusama,
id: ALICE.into(),
});
let call = Call::Balances(pallet_balances::Call::<Runtime>::transfer {
dest: BOB.into(),
value: 500,
});
Relay::execute_with(|| {
let _ = RelayBalances::deposit_creating(&ALICE, 20_000);
let xcm = vec![
TransferReserveAsset {
assets: (Here, 10_000).into(),
dest: Parachain(1).into(),
xcm: Xcm::<()>(vec![
BuyExecution {
fees: (Parent, 10_000).into(),
weight_limit: Limited(6050 as u64),
},
Transact {
origin_type: OriginKind::SovereignAccount,
require_weight_at_most: 6_000 as u64,
call: call.encode().into(),
},
DepositAsset {
assets: All.into(),
max_assets: 1,
beneficiary: (0, alice.clone()).into(),
}
]),
},
];
XcmExecutor::<relay::XcmConfig>::execute_xcm_in_credit(alice, Xcm(xcm), 10, 10);
}); also If change let alice = X1(Junction::AccountId32 {
network: NetworkId::Kusama,
id: ALICE.into(),
});
let bob = X1(Junction::AccountId32 {
network: NetworkId::Kusama,
id: BOB.into(),
});
Relay::execute_with(|| {
let _ = RelayBalances::deposit_creating(&ALICE, 20_000);
assert_eq!(21_000, RelayBalances::free_balance(&ALICE));
let xcm = vec![
TransferReserveAsset {
assets: (Here, 10_000).into(),
dest: Parachain(1).into(),
xcm: Xcm::<()>(vec![
BuyExecution {
fees: (Parent, 10_000).into(), // use relaychain asset as fee payment
weight_limit: Limited(6050 as u64),
},
WithdrawAsset((Here, 500).into()), // withdraw Alice on parachain
// BuyExecution may add here too
DepositAsset {
assets: All.into(),
max_assets: 1,
beneficiary: (0, bob).into(), // deposit to Bob on parachain
}
]),
},
];
XcmExecutor::<relay::XcmConfig>::execute_xcm_in_credit(alice, Xcm(xcm), 10, 10);
}); if relaychain xcm format is |
max_weight: Weight, | ||
_weight_credit: &mut Weight, | ||
) -> Result<(), ()> { | ||
ensure!(origin.contains_parents_only(1), ()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to make this a configurable generic that implements Contains<MultiLocation>
?
We have a use-case for allowing sibling chains to send Transact
instructions to us.
RelaychainAccountId32Aliases
to xcm-supportAllowRelayedPaidExecutionFromParent
to xcm-supportAllowRelayedPaidExecutionFromParent
is needed because in the case of relaychain account sendTransact
to parachain, thenDescendOrigin
is automatically added as the first instruction sended to parachain. so it's used as Barrier check to allow this situation passing through.RelaychainAccountId32Aliases
is used as convert relaychain account to account controlled on parachain. and it's related to above case whenDescendOrigin
appendorigin
(which isParent
) withAccount
which result to(Parent, Account)
.closes #636