-
Notifications
You must be signed in to change notification settings - Fork 587
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
chore: adding basic Msg service and SubmitTx rpc boilerplate #2086
Conversation
docs/ibc/proto-docs.md
Outdated
| ----- | ---- | ----- | ----------- | | ||
| `owner` | [string](#string) | | | | ||
| `connection_id` | [string](#string) | | | | ||
| `timeout` | [string](#string) | | | |
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.
should timeout be Height or uint64 Timestamp here?
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 should support both. Should be similar to MsgTransfer
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, I think we should support both going forward but the current implementation uses clienttypes.ZeroHeight
.
I think we can only support the timeout height via the new execution path - i.e. existing auth modules using the SendTx
go API directly won't be able to specify a height, right?
For SubmitTx
we can use uint64
for timeout_timestamp
and ibc.core.client.v1.Height
for timeout_height
like MsgTransfer
as @colin-axner suggests! :)
string owner = 1; | ||
string connection_id = 2 [(gogoproto.moretags) = "yaml:\"connection_id\""]; | ||
string timeout = 3; | ||
repeated google.protobuf.Any msg = 4; |
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.
@damiannolan what's the reason for using Any
s here? Shouldn't we just be taking in the ics27 packet data
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 if an end user wants to use x/group
or x/gov
they can't really construct the packet data type as it expects a proto encoded []byte
of message data. If we use Any
it can be defined in JSON and submitted for proposal execution. Essentially like it's done here. We would have a proto-JSON encoded MsgSubmitTx
which has a nested array of ICA messages to be executed on the host.
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.
Okay so this is an any which is decoded into packet data?
We cannot assume the counterparty uses any's for message delivery (this is SDK behaviour). I also suspect folks will want to make use of the memo field (it allows for a short term hack of enabling top level middleware for application handling, ie memo field: "swap:lp" would indicate, swap tokens then lp)
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 it'd be problematic to use Any to represent the messages delivered to the counterparty chain. These messages would need to be registered on the controller chain since the SDK will verify the Any URL is registered on the interface registry. Does that make sense?
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.
Okay so this is an any which is decoded into packet data?
I was thinking that this would be an array Any
s which would be encoded into packet data using SerializeCosmosTx
.
These messages would need to be registered on the controller chain since the SDK will verify the Any URL is registered on the interface registry. Does that make sense?
This does make a lot of sense! It's a good point, do you know where in the SDK this would fail if for example you tried to provide an osmosis specific message type (swap) via a cosmos-hub(controller) group proposal?
I think this may be kind of problematic from a ux perspective...
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 believe the issue occurs because UnpackAny
will call UnpackInterfaces
which will try to unpackany
the nested Any, but this will fail to resolve. This is why the migration code has the mock solo machine client state/consensus state
I like |
ah sorry, i misread the error, there is already a SendTx in the controller keeper. If i understand this function correctly, this functionality is actually what should now be triggered by the new SubmitTx msg_server handler right? except we would take the Msg and parse the messages from that rather than the InterchainAccountPacketData |
Codecov Report
@@ Coverage Diff @@
## main #2086 +/- ##
==========================================
- Coverage 79.40% 79.28% -0.13%
==========================================
Files 170 170
Lines 11837 11855 +18
==========================================
Hits 9399 9399
- Misses 2022 2040 +18
Partials 416 416
|
5a65a82
to
aa6ce16
Compare
Ah yea, those names will collide as two functions for the same keeper. We want to leave the old function for backwards compatibility purposes. The new msg handler should perform the same functionality as the existing function but take in the arguments in form of MsgSubmitTx |
bf8e21d
to
fee8080
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.
It's ok to have owner be an address on the controller chain. It also needs to be a signer, so that user-controlled ICAs are secure
func NewMsgSubmitTx(connectionID, owner string, timeoutHeight clienttypes.Height, timeoutTimestamp uint64, msgs []*icatypes.InterchainAccountPacketData) *MsgSubmitTx { | ||
return &MsgSubmitTx{ | ||
ConnectionId: connectionID, | ||
Owner: owner, |
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 should be an AccAddress I believe because it is on the controller chain, we know it should be a valid address
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.
is it better to cast it in the proto or check if its a valid addr in ValidateBasic?
|
||
// GetSigners implements sdk.Msg | ||
func (msg MsgSubmitTx) GetSigners() []sdk.AccAddress { | ||
return []sdk.AccAddress{} |
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.
return []sdk.AccAddress{} | |
return []sdk.AccAddress{owner} |
This needs to be authenticated by owner signature
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 would fill out this function in the next PR along with validate basic :)
option (gogoproto.equal) = false; | ||
option (gogoproto.goproto_getters) = false; | ||
|
||
string owner = 1; |
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 can also be cast to sdk.Address
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.
is it better to cast it in the proto or check if its a valid addr in ValidateBasic?
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 it is fine to leave as is, primarily because the owner is also the signer and all of our Msg types have the signer as an uncasted string (albeit I'm not sure why)
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 it makes sense just to apply the casting change to all our messages at once. The SDK does some different things nowadays anyways
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 looked into this some more. Looks like the SDK intentionally chose to go with a string in 2020 (during amino -> proto migration). Might have been some concern with the gRPC gateway, nevertheless there's talk about removing reliance on the global bech32 config and moving it to be a param of the auth keeper, so you'd need access to the auth keeper to get the acc address (they want to change get signers to return a string instead of an address)
Lets keep with what we have. It'll be easier to deal with everything uniformly
Realize my requests are addressed in #2135 . Ignore the above! |
788b4b4
to
a9e44a1
Compare
…go into ics27/refactor-genesis-types
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.
🚀 🚀
// Timeout timestamp in absolute nanoseconds since unix epoch. | ||
// The timeout is disabled when set to 0. | ||
uint64 timeout_timestamp = 4 [(gogoproto.moretags) = "yaml:\"timeout_timestamp\""]; | ||
ibc.applications.interchain_accounts.v1.InterchainAccountPacketData packet_data = 5; |
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 should add yaml tags and I think we can probs make this a value type instead of a pointer:
(gogoproto.nullable) = false
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, left minor suggestions
|
||
string owner = 1; | ||
string connection_id = 2 [(gogoproto.moretags) = "yaml:\"connection_id\""]; | ||
// Timeout height relative to the current block height. |
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 not sure we should be taking in a relative height here (especially since the timestamp is labeled as absolute). I think I'd prefer external UX to just figure out the correct timeout height
Is there a specific use case we can think of which needs a relative timeout?
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 just grabbed the timeout parameters from the transfer app -- i guess the relative height might make sense if you want a time limit on the action relative to when you've submitted the tx (ie: you want to trigger a swap only within the next 24 hours)
* add protos/rpcs, boilerplate (cherry picked from commit f263794)
…2142) * add protos/rpcs, boilerplate (cherry picked from commit f263794) Co-authored-by: Charly <[email protected]> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Description
Please review #2133 first!
NOTE: i updated the tx name to be SubmitTx in order to avoid name collision with the current SendTx method in the ICA controller keeper. Open to other suggestions!
closes: #2052
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerCodecov Report
in the comment section below once CI passes