Implement off-chain messages CIP

[educlerici-zondax]

Summary

As the approved Off-Chain Messages #2 CIP, the need arises to implement it, through which the implementation of the MsgSignArbitraryData and the implementation of the MsgProveIdentity will be carried out, for which the subtasks will be generated.

Problem Definition

Work Breakdown

• Implement MsgSignArbitraryData
• Implement MsgProveIdentity

[tac0turtle]

Lets implement this only in hubl. An implementation around this feature should be done with cosmjs for frontend users. There isnt a reason people should do this via cli, imo. Would like to hear if there are other opinions?

[JulianToledano]

Lets implement this only in hubl.

do you mean to let hubl sign and verify the off-chain messages?

I think we should implement the messages (with its protos) and its sign/verify methods within the SDK. At least the MsgSignArbitraryData.

Then we can make use of this in hubl instead of in the cli, although It will become more than just a tool for querying Cosmos SDK based blockchain.

[tac0turtle]

This feature is unrelated to the state machine, I would argue there isnt a need to implement it in this repo as well. This is a feature that should be adopted by wallets. This is useful for airdrops or other forms of user verification/attestation. A chain will not ask someone to verify they own a key locally but against a frontend that can store the attestation.

Could you provide reasoning as to why this should live in the sdk?

[JulianToledano]

I agree, this has nothing to do with the state machine. But there's been a community request for signing arbitrary data for some time #4581. Some zones such as secret did implement this by their own. I think it'll be positive to standardise this in the SDK.

On the other hand, the MsgProveIdentity it's been designed with front-ends in mind so I don't think there's really a need for implement this in the SDK.

[tac0turtle]

Doing something like secret entirely in client/v2 is reasonable. We would like to move all client related auxiliary things there overtime. The goal is that the sdk does not bleed into it as well, it might right now.

[JulianToledano]

hey @tac0turtle 👋

is go-pulsar compatible with gogoproto?

I've defined a proto message but anytime I try to encode it with codec it fails with:
panic: protobuf tag not enough fields in MsgSignArbitraryData.state

Turns out go-pulsar adds these three fields to the message:

	state         protoimpl.MessageState
	sizeCache     protoimpl.SizeCache
	unknownFields protoimpl.UnknownFields

that always end up in this error:
https://github.com/cosmos/gogoproto/blob/c177fc4c5bdd7e216ccfb5c79757c85c7d16edcd/proto/table_unmarshal.go#L338-L342