Cosmos-sdk: Same message type for MsgPacket and MsgAcknowledgment

[ancazamfir]

Summary of Bug

The message types for MsgPacket
https://github.com/cosmos/cosmos-sdk/blob/8bc645a418cfc8db6f45352085d3f6485537d3c6/x/ibc/04-channel/types/msgs.go#L403

and MsgAcknowledgment
https://github.com/cosmos/cosmos-sdk/blob/8bc645a418cfc8db6f45352085d3f6485537d3c6/x/ibc/04-channel/types/msgs.go#L512

are the same "ics04/opaque".

For MsgTimeout the type is "ics04/timeout".
https://github.com/cosmos/cosmos-sdk/blob/8bc645a418cfc8db6f45352085d3f6485537d3c6/x/ibc/04-channel/types/msgs.go#L457

These types show in the event's "message.actions" list and it would be good to be able to distinguish them, e.g.ics04/recv, ics04/timeout, ics04/acknowledgment.
Also, any reason for the / in these types?

Version

master

Steps to Reproduce

Using the Go Relayer: monitor events with:
rly development listen ibc1 --data
and then:
rly tx raw xfer-send ibc0 ibc1 9999n0token false $(rly ch addr ibc1)

---

For Admin Use

• [x] Not duplicate issue
• [ ] Appropriate labels applied
• [x] Appropriate contributors tagged
• [x] Contributor assigned/self-assigned

[ancazamfir]

At a higher level, the relation between the "message.." attributes and the different events is not clear to me. For example, the events emitted for client_update and recv_packet transactions look like this:

"events":{
  "fungible_token_packet.module":["ibc_transfer"],
  "fungible_token_packet.receiver":["cosmos1g09sutc7srrn87245ncck9j4mf60uvxt9wx70m"],
  "fungible_token_packet.value":["9999transfer/ibczeroxfer/n0token"],
  "message.action":["update_client","ics04/opaque"],
  "message.module":["ibc_client"],
  "message.sender":["cosmos1g09sutc7srrn87245ncck9j4mf60uvxt9wx70m","cosmos1g09sutc7srrn87245ncck9j4mf60uvxt9wx70m","cosmos1g09sutc7srrn87245ncck9j4mf60uvxt9wx70m","cosmos1xpxukh94rtcr8763hc6g6yustfpee5y9dxqa26"],
  "recv_packet.packet_ack":["{\"success\":true}"],
  "recv_packet.packet_data":[..],
  "recv_packet.packet_dst_channel":["ibczeroxfer"],
  "recv_packet.packet_dst_port":["transfer"],
  "recv_packet.packet_sequence":["2"],
  "recv_packet.packet_src_channel":["ibconexfer"],
  "recv_packet.packet_src_port":["transfer"],
  "recv_packet.packet_timeout_height":["1127"],
  "recv_packet.packet_timeout_timestamp":["0"],
  "tm.event":["Tx"],
  "transfer.amount":["3529stake","9999transfer/ibczeroxfer/n0token"],
  "transfer.recipient":["cosmos17xpfvakm2amg962yls6f84z3kell8c5lserqta","cosmos1g09sutc7srrn87245ncck9j4mf60uvxt9wx70m"],
  "tx.hash":["87DF417FF92E8CC04D7B78D18B375AD5762A4CC20A06D1ECB6FD262ADBE4E948"],
  "tx.height":["131"],
  "update_client.client_id":["ibczeroclient"],
  "update_client.client_type":["tendermint"],
}

Should it be in fact: "message.module":["ibc_client", "ibc_channels"]? Can I map the "ics04/opaque" to the "recv_packet.." events?
And which module emitted the "transfer..." attributes? Is it "ibc_transfer"? Should there be another event like:
"fungible_token_packet.action":["transfer"]?

I am trying to understand what are the conventions here. For the Rust relayer I am looking at extracting all IBC events and assumed that if I scan the "message.action" list (maybe ziped with the "message.module"), I can deterministically map each element to a set of IBC events and keep their strict order (in case of multiple Tx-es of same and/or different types).
Everything looks fine for client, connection and channel messages. But when I look at the packet events, besides the issue above, with many modules handling it (ibc_channels, ibc_transfer, bank ..) the structure of events becomes less clear and maybe I had the wrong expectation all along.

A dump of the events for an ics20 transfer can be found here:
https://gist.github.com/ancazamfir/6baeff42007536d86aee6cbcc3684e02

Could I get some help going over these and verify if they are correct?

[ancazamfir]

At a higher level, the relation between the "message.." attributes and the different events is not clear ..

Opened https://github.com/cosmos/cosmos-sdk/issues/6459 to track this.
In the meantime is it possible to change the MsgAcknowledgment to have type ics04/acknowledgment?
https://github.com/cosmos/cosmos-sdk/blob/8bc645a418cfc8db6f45352085d3f6485537d3c6/x/ibc/04-channel/types/msgs.go#L512

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[colin-axner]

I can take this on as well as #6459 .

I will update the MsgAcknowledgement and MsgPacket type's as well as do a sweep of ibc and ibc-transfer events to ensure consistency and then update docs to reflect how to interact with them

[colin-axner]

How did you get the relayer to printout events? I'd like to try reproducing the above logs

[ancazamfir]

I put some details in the steps to reproduce:
Using the Go Relayer: monitor events with:
rly development listen ibc1 --data

I don't think it compiles with master anymore, but the goz phase two.
I usually run /.dev-env script initially to setup everything. And either run the listen command above while this is running, or you can also use the raw relayer commands to create transactions.

[colin-axner]

Ok so I've done a bit of digging and I think the main issue here is this line:

"message.action":["update_client","ics04/opaque"],

message actions are released once per message making it very useful in marking where message events begin and end. However, I initially found it very confusing why there were two values for message.action since each event is a type (message), attribute key (action), and attribute value (update client). From what I can tell, these values are being combined by type.attributekey by tendermint when it returns ResultEvent. In fact the events returned from an sdk.Result looks more like this:

        - connection_open_init
            - connection_id: connectionid0
            - client_id: client0Fortestchain1
            - counterparty_client_id: client0Fortestchain0
            - counterparty_connection_id: connectionid0
            - connection_id: mysupercoolconn
            - client_id: client0Fortestchain1
            - counterparty_client_id: client0Fortestchain0
            - counterparty_connection_id: connectionid0
        - message
            - action: connection_open_init
            - module: ibc_connection
            - action: connection_open_init
            - module: ibc_connection

Here you can clearly see 2 connection_open_init messages were sent and could parse the events with much more ease since you'd just need to split all the actions. This is also a stringified version of the events which flattens and does lexicographical ordering. I believe you could directly parse the events where they looks something like:

message.action
msg0 event0
msg0 event 1
...
message.action
msg1 event 0
...
etc

Relying on the tendermint combination of events would require knowing exactly all the events emitted per message type. This can be a bit of work since events could even vary depending on the result of its execution ie, ibc-transfer refunds your money (bank events) or it doesn't refund your money (no bank events).

I'm looking into finding a way of subscribing to events that maintains the ordering emitted by the SDK. I believe just having events returned as abci.Event would even solve this issue.

[colin-axner]

opened an issue on tendermint

[colin-axner]

I think this issue in relation to basic relaying of TAO packets isn't significant so I will update the docs on a conceptual overview of relaying TAO packets based on events.