Support multisig address inside MsgCreateChainLink

[ryuash]

Feature description

I would like to link my multisig addresses to my profile

Implementation proposal

[dadamu]

@RiccardoM @bragaz
The chain-link in Desmos also does not serve multisig account as well, the proto of chain-link should be modified to handle it.
In addition, create-chain-link-json cmd should be separated into create-json-file and sign-json-file as well.
What do you think?

[RiccardoM]

@dadamu Can we have a specification of how it should be edited? It's probably better to open an ADR for this

[dadamu]

@RiccardoM Okay, let me open an ADR and research more about multisig.

[dadamu]

@RiccardoM @bragaz Before completing the adr, I would like to discuss with what I researched and the idea how to implement the feature.

In general, there are two problem which should be solved:

1. Multisig address regeneration

it is impossible to confirm if the multisig address is right by pubkeys of signers.
For instance, there is a multisig address generated by 3 keypairs with threshold which is 2, then the create-chain-link which the user prepared is signed with only 2 pubkey. There is a problem that Desmos can't regenerate multisig address since it contains only 2 pubkey. The way of multisig generation is here.

To solve it, the chain-link-json must be signed by all keypairs involved the multisig generation.

2. The verification process of multisignature

The verification process of multisig signature is also big different from the single keypair. The multisignature contains a list of pubkeys, and a list of signatures generated by them.
The process is like:

1. Check the number of signature and pubkeys are more than threshold
2. Iterate signatures and verify it with pubkeys

It means we need to implement the feature to verify and store the multisignature.

Let me know what do you think, @RiccardoM @bragaz.

[RiccardoM]

Thanks @dadamu for the details explanation of where the problems may lie with multisig accounts. I've taken some time to dig deeper inside the Cosmos SDK codebase, in order to understand how the multisig are handled for transaction and how we can leverage the same process for our case. Here is what I got from my journey:

• The SDK has two different types of public keys: cryptotypes.PubKey, which represents a generic public key, and multisig.PubKey, which represents a generic multisig public key.
• The SDK provides an interface to represent a generic signature: SignatureData. This is then implemented for both single key signatures (using SingleSignatureData) and for multi signatures (using MultiSignatureData).
• The SDK also comes with some util methods used to convert a SignatureData instance to a Proto-compatible type, and vice-versa. These methods are: SignatureDataToProto and SignatureDataFromProto. These methods are also used when serializing/deserializing the signatures generated using the desmos tx sign and desmos tx multisig commands.
• In order to verify a signature, the SDK uses the two public methods associated with each key type: crytptotypes.PubKey#VerifySignature and multisig.PubKey#VerifyMultisignature. You can see an example of such usage inside the VerifySignature method that is used when verifying a transaction. The first requires a SingleSignatureData instance, while the second requires a MultiSignatureData instance.

With all of these, I think I found out how we can change our code to support multisig accounts as well:

1. Require users to provide a SignatureData instance inside the link proof.
2. When verifying the signature, check the SignatureData type and
   1. If it's a SingleSignatureData, make sure the account public key is a cryptotypes. PubKey and then use the VerifySignature method to verify the signature.
   2. If it's a MultiSignatureData, make sure the account public key is a multisig.PubKey and then use the VerifyMultisignature method to verify the signature.

All in all, our Proof type should become something like

type Proof struct {
  PlainText []byte
  Signature SignatureData
  PublicKey PubKey
}

Notes

About SingleSignatureData

As you might note, the SingleSignatureData has a field named SignMode which contains the signature mode used when encoding the transaction during the signature. Since we require the user to provide us with the plain text that has been signed, we do not need this value and so it can be set to any value (even an invalid one).

Applicability

It should be discussed whether or not this method should be applied to chain link proofs too.