Skip to content
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

lp-gateway: Add extrinsics for initiating and disputing message recovery #1970

Merged
merged 11 commits into from
Aug 17, 2024

Conversation

cdamian
Copy link
Contributor

@cdamian cdamian commented Aug 16, 2024

Description

Added:

  • new extrinsics for initiating and disputing message recovery.
  • new gateway events when processing inbound and outbound messages.

Changed:

  • renamed LPEncoding to LPMessage.
    • added new methods from getting dispute messages.
    • changed message hash method.

Checklist:

  • I have added Rust doc comments to structs, enums, traits and functions
  • I have made corresponding changes to the documentation
  • I have performed a self-review of my code
  • I have added tests that prove my fix is effective or that my feature works
  • Added extra events for LP gateway, LP.
  • Removed sender field for outbound gateway message.

@cdamian cdamian mentioned this pull request Aug 16, 2024
4 tasks
@@ -226,7 +226,7 @@ pub enum Message<BatchContent = BatchMessages> {
/// The hash of the message which shall be recovered
hash: [u8; 32],
/// The address of the router
address: Address,
router: [u8; 20],
Copy link
Contributor Author

@cdamian cdamian Aug 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can anyone please confirm that changing these fields is OK?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. The deserialize part in Solidity would expect 32 bytes 🤔, unless this message has special treatment
cc @hieronx

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a few messages which use 32 byte array fields such as RecoverAssets even though for now, 20 bytes suffice. The reasoning behind this is to be well positioned longterm for potential 32 byte addresses. On Centrifuge Chain, we have the luxury of being able to apply migrations. On EVM, that is a much more difficult (and expensive) process AFAIK.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for explaining the whys! I didn't know the exact reason.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I will revert the type, what about the field name then?

@cdamian cdamian force-pushed the feat/lp-v2-message-recovery branch 2 times, most recently from d82316a to 2fc0470 Compare August 16, 2024 18:11
@cdamian cdamian marked this pull request as ready for review August 16, 2024 20:06
@cdamian cdamian marked this pull request as draft August 16, 2024 21:51
@cdamian cdamian force-pushed the feat/lp-v2-message-recovery branch from 3849801 to b3f2f07 Compare August 16, 2024 21:53
@cdamian cdamian marked this pull request as ready for review August 17, 2024 07:20
Copy link
Contributor

@lemunozm lemunozm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Super well organized and easy to review, thanks @cdamian

Just one thing, but apart from that, not a single extra NIT.

Comment on lines +571 to +575
origin: OriginFor<T>,
domain: Domain,
message_hash: MessageHash,
recovery_router: [u8; 32],
messaging_router: T::RouterId,
Copy link
Contributor

@lemunozm lemunozm Aug 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question. Should the domain field always be the domain belonging to the messaging_router passed?

If that is the case, we can extend RouterId: Into<Domain>, which is already implemented in common/routing.rs and save the user to write the domain parameter.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If agree, we can merge this anyways and do it in a next PR

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's do it separately and not waste another CI run?

Comment on lines +542 to +546
origin: OriginFor<T>,
domain: Domain,
message_hash: MessageHash,
recovery_router: [u8; 32],
messaging_router: T::RouterId,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, and probably in any place where we're passing both domain and router_id, because router_id already carries the domain information

@lemunozm lemunozm mentioned this pull request Aug 17, 2024
9 tasks
Copy link

codecov bot commented Aug 17, 2024

Codecov Report

Attention: Patch coverage is 74.32432% with 19 lines in your changes missing coverage. Please review.

Project coverage is 48.96%. Comparing base (771fb78) to head (b3f2f07).
Report is 1 commits behind head on main.

Files Patch % Lines
.../liquidity-pools-gateway/src/message_processing.rs 72.72% 9 Missing ⚠️
pallets/liquidity-pools/src/message.rs 0.00% 7 Missing ⚠️
pallets/liquidity-pools-gateway/src/lib.rs 91.17% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1970      +/-   ##
==========================================
+ Coverage   48.86%   48.96%   +0.10%     
==========================================
  Files         183      183              
  Lines       13095    13133      +38     
==========================================
+ Hits         6399     6431      +32     
- Misses       6696     6702       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@cdamian
Copy link
Contributor Author

cdamian commented Aug 17, 2024

@lemunozm @wischli can we go ahead and merge it since everything is green? We can tackle the other item in a separate PR.

Copy link
Contributor

@lemunozm lemunozm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure! Everything looks super great to me. Thanks Cosmin!

Copy link
Contributor

@wischli wischli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work - LGTM! One minor nit that can be ignored or applied in another PR.

///
/// Hash - hash of the message that should be recovered.
/// Router - the address of the recovery router.
fn initiate_recovery_message(hash: [u8; 32], router: [u8; 32]) -> Self;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Should use MessageHash type in signature

Suggested change
fn initiate_recovery_message(hash: [u8; 32], router: [u8; 32]) -> Self;
fn initiate_recovery_message(hash: MessageHash, router: [u8; 32]) -> Self;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add it in - #1974

///
/// Hash - hash of the message that should be disputed.
/// Router - the address of the recovery router.
fn dispute_recovery_message(hash: [u8; 32], router: [u8; 32]) -> Self;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Should use MessageHash type in signature

Suggested change
fn dispute_recovery_message(hash: [u8; 32], router: [u8; 32]) -> Self;
fn dispute_recovery_message(hash: MessageHash, router: [u8; 32]) -> Self;

pallets/liquidity-pools-gateway/src/lib.rs Show resolved Hide resolved
@cdamian cdamian merged commit 03262c5 into main Aug 17, 2024
14 of 22 checks passed
@cdamian cdamian deleted the feat/lp-v2-message-recovery branch August 17, 2024 11:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants