Submit misbehaviour messages using the consumer id

[insumity]

Summary

WHY

Currently, both misbehaviour messages (MsgSubmitConsumerDoubleVoting and MsgSubmitConsumerMisbehaviour) utilize the chainID (see here and here) in Hermes.

As part of the Permissionless ICS work, we intend to move the Hub away from having a gov proposal launching a consumer chain and instead anyone could launch a chain with a transaction. As a result, we have to move away from using chainID as a unique identifier of consumer chains to a new identifier, called consumerId, because now we might have multiple consumers chains with the same chainID and hence chainID cannot be a unique identifier. We intend to refactor all messages (e.g., MsgOptIn, MsgAssignConsumerKey, etc.) to use consumerId instead of a chainId. This includes also the MsgSubmitConsumerDoubleVoting and MsgSubmitConsumerMisbehaviour messages and hence those messages when constructed by Hermes should contain the consumerId.
This means, we will change the misbehaviour messages to be as follows:

message MsgSubmitConsumerMisbehaviour {
  string submitter = 1 [(cosmos_proto.scalar) = "cosmos.AddressString"];
  // the consumer id of the consumer chain where the misbehaviour occurred
  string consumer_id = 2;
  // The Misbehaviour of the consumer chain wrapping
  // two conflicting IBC headers
  ibc.lightclients.tendermint.v1.Misbehaviour misbehaviour = 3;
}

message MsgSubmitConsumerDoubleVoting {
  string submitter = 1 [(cosmos_proto.scalar) = "cosmos.AddressString"];
  // the consumer id of the consumer chain where the double-voting took place
  string consumer_id = 2;
  // The equivocation of the consumer chain wrapping
  // an evidence of a validator that signed two conflicting votes
  tendermint.types.DuplicateVoteEvidence duplicate_vote_evidence = 3;
  // The light client header of the infraction block
  ibc.lightclients.tendermint.v1.Header infraction_block_header = 4;
}

and we would like Hermes to submit those misbehaviour messages by using the consumerId.

HOW

Hermes could find out the consumerId by querying the provider's clientId for some consumer chain (i.e., query ccvconsumer provider-info) and then querying the provider chain for the consumerId that corresponds to this clientId. We intend to provide a query consumer-id-from-client-id [client-id] query so that Hermes can easily find the consumerId from the clientId.

WHEN

We hope to have the Permissionless ICS Hub (v20) launched in mid September and a have a release candidate by end of August.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[romac]

Thank you for opening this! I have just one remark:

I see in the new definitions you have pasted, that you plan on changing the tags of the fields within the message. I would caution against that, because doing so is not backward-compatible and you would have to release the new version of the message under a different namespace, eg. interchain_security.ccv.provider.v2.

Instead, if you just add the field and do not change the tags of the existing field, then the change would be backward-compatible and you could just make the change without having to use a new namespace. This would also be preferable for us, as it's easier to just include the field when needed rather than switch between two different messages.

[insumity]

Thanks @romac !
That's a really good point. We'll stay with v1 but remain backward-compatible by simply deprecating chain_id and introducing consumer_id. We have not done the changes yet but working on them. If something changes in this front, we'll let you know.

[insumity]

@romac The permissionless work is still under progress in the feat/permissionless branch. However, the latest gaia is using it, so you can already build gaia with the Permissionless ICS.

Furthermore, we introduced this query to receive the consumerId by using the clientId that might be helpful in order to know what consumerId to use when submitting misbehaviour messages.

Let me know if there are any concerns or help needed from our side.

[romac]

Is the query consumer-id-from-client-id query also available as a gRPC query? I am asking because we do not expect operators to have the gaiad binary available for Hermes to call, and instead typically rely on gRPC queries whenever we need information from the chain.

[insumity]

We should have it available as a gRPC query because:

$ grpcurl -plaintext 7.7.7.253:9091 list interchain_security.ccv.provider.v1.Query
...
interchain_security.ccv.provider.v1.Query.QueryConsumerIdFromClientId
...

[romac]

Awesome, thank you! For reference, here is the query definition: https://github.com/cosmos/interchain-security/blob/e1b1dc2831267ae2bf85a95ff844ddb7ada06942/proto/interchain_security/ccv/provider/v1/query.proto#L131-L137