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 v1++ #1211
Connectors v1++ #1211
Conversation
d368e22
to
939834c
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.
Some notes on the Xcm config changes 👀
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.
LGTM! Simple, and readable! A lot of cool factorizations 🚀 .
Minor comments below
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.
LGTM, great work! I also agree with @lemunozm's minor comments.
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.
Looks already good!
Just some minor stuff that could be adapted.
fn add_pool_zero() { | ||
let msg = Message::<Domain, PoolId, TrancheId, Balance, Rate>::AddPool { pool_id: 0 }; | ||
let encoded = msg.encode(); | ||
pub type ConnectorMessage = Message<Domain, PoolId, TrancheId, Balance, Rate>; |
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'm worried that because Message
is something generic for these types, we could be testing that it's working with the test types, but different configurations of the connector pallet could lead to different serializations. i.e. How a Rate
is encoding is defined by the Rate
used in the configuration. Nevertheless is the pallet who should set how that rate should be deserialized by the data format specification agreed upon.
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.
Yeah that's a good point. What safe-guards us is the expected_hex
values, that's why it's important to have those in the tests 👍
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.
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.
We went for Option<B>
right?
I think it is fine to move forward with this, knowing that we need to adapt the encoding/decoding anyways because of V2 in the near future. We should revisit the proposal then again and have a stable, secure way of doing that on substrate and solidity then.
Yes, sorry, I messed up A and B. Still need to learn the letters apparently 😄 And agreed on the approach 💯 |
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.
LGTM!
33cdf32
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.
Re-Approve.
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.
Re-approve
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.
Re-approving!
Changes
Decode for Message
DescendOrigin
instruction at headMultiLocation
toAccountId
conversion (AccountIdHash
)To Do
origin
of the handle functionDecode
forMessage