-
Notifications
You must be signed in to change notification settings - Fork 86
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
Add multi-router support in LP gateway. #1893
base: main
Are you sure you want to change the base?
Conversation
/// This can only be set by an admin. | ||
#[pallet::storage] | ||
#[pallet::getter(fn domain_multi_routers)] | ||
pub type DomainMultiRouters<T: Config> = |
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.
Added a separate storage and extrinsic since I'm not sure how to proceed in this case - do we eventually remove the old storage after a migration or can we nuke/replace it 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.
You can replace it now. If needed, the migration can go along with this PR, which I think is quite straightforward: just adding the current router, if it exists, into the vector and purge the old storage
Re-basing on main. |
cdc56a2
to
a5e30b1
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1893 +/- ##
==========================================
+ Coverage 47.36% 47.38% +0.01%
==========================================
Files 176 176
Lines 13305 13325 +20
==========================================
+ Hits 6302 6314 +12
- Misses 7003 7011 +8 ☔ View full report in Codecov by Sentry. |
c145538
to
22a8f03
Compare
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.
Pretty straightforward change. Wanted to propose a few things if we are anyways working on this:
- Add a dedicated
Queue
for Inbound and Outbound that is currently served by on idle, so that we can easily switch toTasks
in the future. - (NOT SURE IF GOOD IDEA) Instead of iterating over all routers we could have a
DoubleMap
and then serving the message in a queue does take care of-
- Ensuring that a message can be send over each
Router
only once
- Ensuring that a message can be send over each
-
Furthermore
We will need to have the same for inbound logic. So a the Gateway
must take care of a few things
-
Outgoing
- Each Message is sent only once over each existing
Router
- Each Message is sent only once over each existing
-
Incoming
- Each Message is only forwarded to the
LiquidityPools
pallet once some information has been verified.
NOTE: It is to be determined how this will happen, but we should already take care right now that messages are "queued" until this verification has happened.
- Each Message is only forwarded to the
I think
|
@mustermeiszer we already have a queue in place for outbound messages - do you mean that we should replace that with a queue implementation that will serve both the LP gateway and the main LP pallet? |
I think now it makes sense, because there will be much more processing needed. Having a general The general idea of the multi router logic is. Sending:
Receiving
I really, really strongly am against exposing the I would have split the the enum into an For sending batches I would also say we have an |
22a8f03
to
7e40381
Compare
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.
First fast look to this. Will do another one more deeply soon!
//TODO(cdamian) - do we need to add the deprecated fields? | ||
// | ||
// | ||
// 25 - Freeze tranche tokens | ||
// DEPRECATED_Freeze, | ||
// 26 - Unfreeze tranche tokens | ||
// DEPRECATED_Unfreeze, | ||
/// Trigger a redeem request. | ||
/// | ||
/// Note - placeholder that should be updated. | ||
TriggerRedeemRequest, | ||
/// A multi-directional message used for verifying | ||
/// both inbound and outbound messages. | ||
MessageProof { | ||
proof: [u8; 32], | ||
}, |
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.
Sorry @cdamian I didn't know, your feature came with new messages from LPv2. In that case, maybe it makes more sense to add those to lpv2 branch.
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.
Maybe this PR can be split into something which is idempotent over how main
works with LPv1 (it means, not sending any proof, just the original message by one router). And a new very small PR over LPv2 sending the proof.
That way most changes are done over main
avoiding future git conflicts
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.
Yea, I was afraid we might have to do this. Will look into doing a smooth transition.
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.
OK, am currently thinking about splitting this in 3 parts, and (roughly) do the following on top of the LPv2 branch:
1 - add the new queue pallet;
2 - use the new queue pallet in the gateway;
3 - add proof processing for inbound/outbound 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.
Just a brief scan. Nothing to complain, sounds and looks like a solid plan.
Description
The LP gateway queue logic was moved to a new pallet which is used for handling both inbound/outbound messages.
Outbound messages
Changed processing of outbound messages by sending the actual message once, using one router, and sending message proofs using the remaining routers.
Inbound messages
Inbound messages are sent for further processing (i.e. to the LP pallet) only when the required number of message proofs is received.
Checklist: