This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reanchor should return canonical location #4470
Reanchor should return canonical location #4470
Changes from all commits
a3b968e
db7cd5f
55da4ea
b441587
95e6bab
f4a3439
81e2396
2a46816
cf270f2
6306c84
915b5d7
b4b1cbb
0dc5a28
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Should this pass? Because it does.
I am having a really hard time understanding this function's behavior.
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.
Yes. All
location
s within a consensus system must be taken to be within some localcontext
(aka the consensus system's ancestry). The ancestry is essentially just the consensus system's location from the point of view of the most distant ancestor consensus system under which the local consensus sits. For the Polkadot Relay, this is conventionally empty (as it is its own universe) but for a parachain which knows that it exists within a broader consensus system it would be theParachain
junction by which the parent Relay-chain refers to it.Local
location
s which begin withParent
should be "escaping" outside of the local consensus system (otherwise there is no need to begin withParent
), however if after theParent
node(s), the rest of the location is such that it descends back into the local consensus then this becomes a non-canonical location. Basically, theParent
items and their corresponding junctions are superfluous because they're already implied by the ancestry.In order to normalise it, we need to detect and remove this case.
In this case the
context
is(PalletInstance(30), PalletInstance(42)
and the
location
isParent, PalletInstance(42), GeneralIndex(69)
. The location is therefore non-canonical, because theParent
is being used to descend outside of the local consensus and beyondPalletInstance(42)
(the last item ofcontext
) and then re-descend immediately back into the very samePalletInstance(42)
. Therefore this location is exactly equivalent to the simpler (and shorter)GeneralIndex(69)
.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.
Yes, I understand now. Basically, we use context and the front of the multilocation and cancel out all "redundant" data, and normalize it.
This was very key. Thanks.
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.
👍 just some note 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.
where I can read about stuff happening here? except code:) I read all papers on xcm I found and ported acala tests. so found reanchor stuff. do not get what it is. actually security of xcm is very unclear.
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.
@dzmitry-lahoda Substrate/Polkadot doesn't have a concept of
CurrencyId
, and it looks to me to be an Acala/Karura concept. Would you kindly raise this issue in their repo instead?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.
:) Substrate/Polkadot has the location and general key concept. why would somebody trust these are genuine? Asset with location FooBar. Parachain X xcmed FooBar from X to Z. Why would we trust that FooBar was not just minted?
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 think you are not understanding that every consensus system (or blockchain in layman terms) is responsible for interpreting incoming XCM messages correctly. As such, how a chain decides to interpret
GeneralKey
orGeneralIndex
is not up to us to decide.Thus, would you please raise this issue to Acala/Karura?
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.
Still not clear. Kusama can have KSM. Kusama can send (if we call its XCM pallet) to send KSM to paracahain. Can someone send KSM back to Kusama? Does Kusama tracks all places it send KSM to be equal? I mean DOT. Polkadot is relay chain. Does DOT sent via XCM has any security/alignment after it was send from Polkadot to Parachain?
So right now I speak about Relay and some abstract Parachain. And some 2 abstract parachains having DOT/KSM. How these could interpret correctly message with asset (1, Here) origin?
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.
MultiLocation
s are relative paths, as explained in Gav's blogpost. A parachain of Kusama/Polkadot will identify KSM/DOT as(1, Here)
. When they send(1, Here)
to the relay chain, their local XCM executor will reanchor the location to be(0, Here)
.As I mentioned in my first message, reanchoring happens automatically behind the scenes and doesn't require any user input. If you are wondering about how assets are transferred between parachains, I have an answer on Stack Exchange that describes in detail how it is done, and how the trust issues are resolved.