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.
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
feat: LP V2 message forwarding #1971
feat: LP V2 message forwarding #1971
Changes from 1 commit
db9996e
93512ea
b4c4eda
bd6b064
893736a
e5dedb2
006c5a3
042b08a
67d5c3f
ce64041
b39fa47
30eae5c
5cf3752
6a5cb5f
4a0f751
cd72182
9f433f0
be1fc23
047ebac
a253a6f
ba726f0
cbb75b4
b24a5d4
3a15a49
acc6f39
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.
Question. Why the
_domain
is not used?Could make sense the new domain_addres to be:
DomainAddress::Evm(domain, contract)
or similar?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.
Because the origin of the LP message was not
_domain
(say Celo) but thedomain_address.domain()
(say Ethereum). The gateway checks in the allowlist, if it contains Ethereum'sdomain_address.domain()
in the allowlist. I don't believe that Celo's_domain
should be in the allowlist because there is no direct connection configured for Celo, for that purpose we have the forwarder pallet which acts as an allowlist gatekeeper for forwarded domains whereas the gateway acts as gatekeeper for direct connections.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.
Though now I remember why I initially went with the
RouterProvider
! We cannot guarantee that therouter_id
of thereceive
signature here is the same for which we have stored forwarding info. Therefore, we actually need to iterate over all possible router ids!cc @cdamian
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.
Mmm... Ok, here we have two points:
First, I think we need to read
_domain
or_contract
somehow because if the other side forwarder implementation works like ours, it will never forward a message.Second, if we need to use the forwarder domain, how do we get the correct router?
Crazy idea. Could it makes sense that our chain never receives a Forwarder message? I mean, we're the final endpoint, right? The forwarder wrapper should have been unwrapped before reaching centrifuge. So, as a final endpoint, we should never receive a wrapped message.
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 my above crazy idea is not as crazy, and it's related to this thread above with Jeroen about not using the contract.
TLDR: I think we should not receive forwarded messages.
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 is the counterexample to the current implementation of the forwarder pallet.
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.
Completely agree.
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.
Copy pasting here the flows for a 2-router-setup you broke down to make this more explicit:
Flow of a non-forwarded message
Flow of a forwarded message
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.
Since we all have found consensus on this matter, here's the corresponding code: acc6f39
I really hope this was the last raid boss to slay and that we can merge this beast.
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 understand the second line of non-forwaded message is router B in all places right? @wischli
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 we need to move this out from the gateway. If not, the caller of this extrinsic will skip the forwarding logic.
Still not sure where. Maybe on
pallet-axelar-router
orpallet-liquidity-pool-forwarder
(and usingMessage
instead ofVec<u8>
).Or maybe just removing it, because it's no longer used...
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.
Great catch! I propose to add a
MessageDeserializer
AT to the Gateway config which is implemented by our runtime typeMessageSerializer
. This will deserialize the message and pass it to the forwarder pallet which will pass it back to theMessageReiver
impl of the Gateway.So from now:
process
extrinsic -> Gateway impl ofMessageReceiver
To
process
in Gateway ->receive
inMessagSerializer
which deserializes ->receive
in forward pallet which unwraps any forwarded message ->receive
in Gateway which does its thingWDYT?
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.
Note that htis requires instantiating the
router_message
mock pallet, which I am working on right now.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.
Mmm... I am not sure about that walk...
As more I think on it as more I think we can remove this. We no longer need this since Axelar uses the trait to send message to the gateway. If we want to emulate receiving message explicitly, this extrinsic should be in axelar-router
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.
Interested in your take on this @cdamian
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 agree with @lemunozm - the flow that you are describing above would mean that the forwarder can be called by the gateway, in an inbound context, which shouldn't happen? Also, this extrinsic can maybe ensure that no forwarded message is submitted since we have it for special cases?
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.
See here for code changes if we added the
MessageDeserializer
to the Gateway: a253a6fHowever, I have reverted that change and applied @lemunozm's proposal of removing the
receive_message
extrinsic which apparently was only used by the Axelar precompile. I have refactored the existing Gateway UTs for checking theMessageReceiver
implementation which was not tested: cbb75b4