Events that Hermes needs

[adizere]

Hermes requires access to the following events to be able to work correctly.

Note: Events are indexed by a tuple {eventType}.{attributeKey} structure (ref: gaia/../testnets/../app.toml).

IBC Client operations

For client creation events

• Event type = create_client
  • Ref here
• Attribute keys that are necessary, 4 in total:
  • height
  • client_id
  • client_type
  • consensus_height
  • Ref here
• In summary, we'll need to index all these event combinations: create_client.height, create_client.client_id, create_client.client_type, create_client.consensus_height.

For client update

• Ref event type: https://github.com/informalsystems/ibc-rs/blob/d070773d9a6b3308c2c142c586823770eb3a1a35/modules/src/events.rs#L101
• Ref attribute keys, 5 of them: https://github.com/informalsystems/ibc-rs/blob/d070773d9a6b3308c2c142c586823770eb3a1a35/modules/src/core/ics02_client/events.rs#L15-L28

For client misbehavior

• https://github.com/informalsystems/ibc-rs/blob/d070773d9a6b3308c2c142c586823770eb3a1a35/modules/src/events.rs#L102
• Attributes are the same as client creation (ref).

For client upgrade

• https://github.com/informalsystems/ibc-rs/blob/d070773d9a6b3308c2c142c586823770eb3a1a35/modules/src/events.rs#L103
• Attributes are the same as client creation (ref).

IBC Connection operations

For connection handshake events

• There are 4 event types: https://github.com/informalsystems/ibc-rs/blob/d070773d9a6b3308c2c142c586823770eb3a1a35/modules/src/events.rs#L104-L108
• For each of these event types, there are 5 possible attributes: https://github.com/informalsystems/ibc-rs/blob/d070773d9a6b3308c2c142c586823770eb3a1a35/modules/src/core/ics03_connection/events.rs#L15-L19

So there's a total of 20 event combinations.

IBC Channel operations

For channel handshake events

• There are 5 event types: https://github.com/informalsystems/ibc-rs/blob/d070773d9a6b3308c2c142c586823770eb3a1a35/modules/src/events.rs#L109-L115
• There are 6 attributes: https://github.com/informalsystems/ibc-rs/blob/d070773d9a6b3308c2c142c586823770eb3a1a35/modules/src/core/ics04_channel/events.rs#L18-L23

For packet events

• There are 6 event types: https://github.com/informalsystems/ibc-rs/blob/d070773d9a6b3308c2c142c586823770eb3a1a35/modules/src/events.rs#L117-L122
• Each event type (with the exception of write_acknowledgement) has these 8 attributes: https://github.com/informalsystems/ibc-rs/blob/d070773d9a6b3308c2c142c586823770eb3a1a35/modules/src/core/ics04_channel/events.rs#L26-L33
• The event for write_acknowledgement has the above 8 attributes plus 1 more: https://github.com/informalsystems/ibc-rs/blob/d070773d9a6b3308c2c142c586823770eb3a1a35/modules/src/core/ics04_channel/events.rs#L34

[ancazamfir]

I am writing a few thoughts and my perspective here, especially related to the discussions in
#1288
#2303.
#2314
(Or I can move it to a different discussion)

A message in a Tx to chain A emits an event that is considered of IBC type if hermes uses (or could use) that event to trigger the relaying of an IBC message to a counterparty chain B.

We have a few examples of tx raw CLIs created for testing (i typically use these in parallel with hermes start) with related testing goals:

• create-client - hermes can send a correct MsgCreateClient message and extract create_client event. hermes start ignores the create_client event as there is no action required.
• update-client - hermes can send a correct MsgUpdateClient message, extract and act on update_client event to detect and send MsgSubmitMisbehaviour
• upgrade-client - hermes can send a correct MsgUpgradeClient. An upgrade_clientevent is generated but we currently don't do any relaying based on it.
• conn-* and chan-* - ability to build a correct Msg*Open.. and act on the corresponding open events to progress handshake, i.e. we send the "next" MsgConnectionOpen.. or MsgChannelOpen.. as required by the protocol.
• ft-transfer - ability to act on send_packet event and send MsgRecvPacket. MsgTimeoutPacket or MsgTimeoutOnClose

In addition we have the "official" CLIs to update a client (same as the tx raw update-client), upgrade a client, open connections and channels. These are more robust, more validation is done, UX is polished, etc. But other than that they do the same thing as their raw counterparts.

With this in mind, let's look at the upgrade chain proposal. This is currently the tx raw upgrade-chain CLI also originally designed for testing (in a way very similar to ft-transfer one) (*).
It builds a specific MsgSubmitProposal that includes in its content field an IBC UpgradeProposal. This is an IBC related proposal even if it is wrapped in a generic governance proposal. It includes the upgraded_client_state, and it basically says that IBC clients will continue to work once the chain is restarted only if they have a state compatible to upgraded_client_state.
The current purpose of this CLI is to set the environment for the upgrade-client above as without an active proposal this latter CLI would fail.

We currently do NOT have an IBC event defined for the government proposal. I believe we should because we could have:

• a better UX around tx raw upgrade-chain CLI
• but more importantly, an upgrade client worker that is spawned on the new "upgrade_proposal" event (**). It would query the proposal status and once active, wait for the chain to halt and upgrade all clients for that chain. If inactive would just exit. Note that not all proposals will trigger this event, just the ones that include IBC upgrade proposals.

In summary, hermes could use an upgrade_proposal IBC event to send a number of MsgUpgradeClient. With this UX whatever chain CLI is used for gov proposals will work without any other user intervention (other than hermes start)

(*) the CLI is limited to changing unbonding_period. We cannot change chain_id, proof_specs, upgrade_path. To make this a production CLI we need a lot more work.
(**) we can extract the current submit_proposal event but we have no idea if this is for an IBC breaking proposal (i.e. UpgradeProposal). We would need to query the proposal with the proposal_id and decode the content, exit if not a proposal of interest. Also fwiw there are two submit_proposal events (with different contents) currently emitted by the gov module which makes things a bit more awkward (only one includes a proposal_id).

[adizere]

This makes a lot of sense, expecting that UpgradeProposals should emit an IBC event. Thank you Anca for the full background on that!

It would be great if we manage to restrict Hermes to caring only about IBC events.