Closed ryuash closed 2 years ago
@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?
@dadamu Can we have a specification of how it should be edited? It's probably better to open an ADR for this
@RiccardoM Okay, let me open an ADR and research more about multisig.
@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:
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.
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:
It means we need to implement the feature to verify and store the multisignature.
Let me know what do you think, @RiccardoM @bragaz.
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:
cryptotypes.PubKey
, which represents a generic public key, and multisig.PubKey
, which represents a generic multisig public key. SignatureData
. This is then implemented for both single key signatures (using SingleSignatureData
) and for multi signatures (using MultiSignatureData
). 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. 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:
SignatureData
instance inside the link proof. SignatureData
type and
SingleSignatureData
, make sure the account public key is a cryptotypes. PubKey
and then use the VerifySignature
method to verify the signature. 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
}
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).
It should be discussed whether or not this method should be applied to chain link proofs too.
I would like to link my multisig addresses to my profile
Implementation proposal