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

connectors-gateway: Add gateway routers #1475

Merged
merged 9 commits into from
Aug 3, 2023

Conversation

cdamian
Copy link
Contributor

@cdamian cdamian commented Aug 1, 2023

Description

Part 3 of - #1376

The routers added in this PR will be used by the Connectors Gateway pallet when sending outgoing messages via EVM or XCM.

Currently there are 3 routers:

  • Axelar EVM - used to call the Axelar Gateway contract which in turn calls the Connectors contract.
  • Axelar XCM - used to call the Axelar Gateway contract which in turn calls the Connectors contract via Moonbeam XCM.
  • Ethereum XCM - used to call the Connectors contract via Moonbeam XCM.

Changes and Descriptions

  • Add Connectors Gateway routers

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

@cdamian cdamian changed the title Connectors gateway 3 gateway routers connectors-gateway: Add gateway routers Aug 1, 2023
@cdamian cdamian mentioned this pull request Aug 1, 2023
4 tasks
@cdamian cdamian force-pushed the connectors-gateway-3-gateway-routers branch 2 times, most recently from 1a05237 to 35dfaa1 Compare August 1, 2023 13:43
@cdamian cdamian marked this pull request as ready for review August 1, 2023 14:03
Copy link
Contributor

@NunoAlexandre NunoAlexandre left a comment

Choose a reason for hiding this comment

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

First Round 🏄‍♂️ A higher level review first mostly addressing the structure we are adopting here.

  1. connectors-gateway-routers is not an actual pallet - it has no Config, no storage, no extrinsics, etc. We can and imo should just make this a sub directory of the connectors-gateway pallet.

  2. Having connectors-gateway-routers/routers/ hosting the "primitives" of the actual routers in the root dir (i.e, connectors-gateway-routers/axelar_evm.rs, connectors-gateway-routers/ethereum_xcm.rs, etc) is counter-intuitive. I suggest that we do:

./connectors-gateway/
  |- ./routers/
     |- ./mod.rs # contains all primitives used by the actual routers; if useful, can group them in `mod`s
     |- axelar_evm.rs
     |- axelar_xcm.rs
     |- ethereum_xcm.rs
  1. the do_init pattern is something that I personally have never seen in Substate. Happy to change my mind, but as of now I'd rather drop that and write a migration instead that sets whatever state we may want to set once we are ready to do that (we know the right weights, chain ids, etc)

@cdamian
Copy link
Contributor Author

cdamian commented Aug 2, 2023

First Round surfing_man A higher level review first mostly addressing the structure we are adopting here.

1. `connectors-gateway-routers` is not an actual pallet - it has no `Config`, no storage, no extrinsics, etc. We can and imo should just make this a sub directory of the `connectors-gateway` pallet.

2. Having `connectors-gateway-routers/routers/` hosting the "primitives" of the actual routers in the root dir (i.e, `connectors-gateway-routers/axelar_evm.rs`, `connectors-gateway-routers/ethereum_xcm.rs`, etc) is counter-intuitive. I suggest that we do:
./connectors-gateway/
  |- ./routers/
     |- ./mod.rs # contains all primitives used by the actual routers; if useful, can group them in `mod`s
     |- axelar_evm.rs
     |- axelar_xcm.rs
     |- ethereum_xcm.rs
4. the `do_init` pattern is something that I personally have never seen in Substate. Happy to change my mind, but as of now I'd rather drop that and write a migration instead that sets whatever state we may want to set once we are ready to do that (we know the right weights, chain ids, etc)

Regarding the last point - there are some pallets with init logic based on the genesis config, the session-info pallet would be one example IIRC.

As for the second part regarding migration/setting of required states, I think it makes sense to have it like this since we would only need one governance step for adding a router, otherwise, in the case of XCM, we would need 2 calls to set the storages + 1 call to set the router, and I don't see a good reason for that.

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.

Just some random comments, not a review at all!

Thanks again for spliting the PRs, much easier to understand everything!

@cdamian cdamian force-pushed the connectors-gateway-3-gateway-routers branch from 35dfaa1 to afb5f32 Compare August 2, 2023 11:02
Copy link
Contributor

@NunoAlexandre NunoAlexandre left a comment

Choose a reason for hiding this comment

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

Looking better already, thanks for taking the comments in consideration 🙏

A few more comments. I will do another round later going through the details of the messages encoding since it's important to check those outs more carefully

@cdamian cdamian force-pushed the connectors-gateway-3-gateway-routers branch from 7505ca8 to cdb99c0 Compare August 3, 2023 09:32
Copy link
Contributor

@NunoAlexandre NunoAlexandre left a comment

Choose a reason for hiding this comment

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

LGTM! We will probably find some quirks when testing this on Moonbase Alpha but since it's all in development and appears correct we are good merging this imo.

The only thing I would still say is whether there really is a need for a separate crate for these routers over having them as a sub-dir of connectors-gateway. Not a blocker for me!

Thanks a lot for all the work and all the positivity in taking in all the review comments 🙏

@cdamian
Copy link
Contributor Author

cdamian commented Aug 3, 2023

LGTM! We will probably find some quirks when testing this on Moonbase Alpha but since it's all in development and appears correct we are good merging this imo.

The only thing I would still say is whether there really is a need for a separate crate for these routers over having them as a sub-dir of connectors-gateway. Not a blocker for me!

Thanks a lot for all the work and all the positivity in taking in all the review comments pray

@mustermeiszer came with the idea of having routers in a separate crate, and given the xcm/evm dependencies that we need there I think it makes sense to have it like that and not to bloat the actual gateway.

@NunoAlexandre
Copy link
Contributor

LGTM! We will probably find some quirks when testing this on Moonbase Alpha but since it's all in development and appears correct we are good merging this imo.
The only thing I would still say is whether there really is a need for a separate crate for these routers over having them as a sub-dir of connectors-gateway. Not a blocker for me!
Thanks a lot for all the work and all the positivity in taking in all the review comments pray

@mustermeiszer came with the idea of having routers in a separate crate, and given the xcm/evm dependencies that we need there I think it makes sense to have it like that and not to bloat the actual gateway.

Fair points, this is fine 👍

@cdamian cdamian merged commit 637ec22 into main Aug 3, 2023
@cdamian cdamian deleted the connectors-gateway-3-gateway-routers branch August 3, 2023 14:00
Copy link
Collaborator

@mustermeiszer mustermeiszer left a comment

Choose a reason for hiding this comment

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

Nice setup! Pretty flexible!

Comment on lines +200 to +206
pallet_xcm_transactor::Pallet::<T>::set_transact_info(
<T as frame_system::Config>::RuntimeOrigin::root(),
self.xcm_domain.location.clone(),
self.xcm_domain.transact_info.transact_extra_weight,
self.xcm_domain.transact_info.max_weight,
self.xcm_domain.transact_info.transact_extra_weight_signed,
)?;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could we run into troubles if

  • RouterA sets these values
  • time passes and we add a new RouterB
  • RouterB overwrites values with a new value?

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 don't think so. In theory, we should only have one router for a specific location, so if at some point we overwrite the router I think it makes sense to overwrite the xcm transactor info that is stored.

// The currency in which we want to pay fees.
CurrencyPayment {
currency: Currency::AsCurrencyId(self.xcm_domain.fee_currency.clone()),
fee_amount: None,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why is this None?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was as per the original connectors implementation found here -

Maybe @NunoAlexandre can provide more specific info?

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