-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: ADR-015: Improve chain link signature support #968
feat!: ADR-015: Improve chain link signature support #968
Conversation
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Codecov Report
@@ Coverage Diff @@
## master #968 +/- ##
==========================================
- Coverage 80.54% 80.49% -0.06%
==========================================
Files 172 172
Lines 15095 15223 +128
==========================================
+ Hits 12158 12253 +95
- Misses 2415 2442 +27
- Partials 522 528 +6
Continue to review full report at Codecov.
|
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
…/adr-015-improve-chain-link-signature-support
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work! So this supports also the signatures made with Metamask right?
Yes, it does. It supports ETH |
// -------------------------------------------------------------------------------------------------------------------- | ||
|
||
// CosmosSingleSignature is the signature data for a single signer | ||
message CosmosSingleSignature { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking if there are better ways to name this type after what @dadamu said:
Luckily, thanks to solana-wallet-adapter providing the function signing a raw message(arbitrary string), we can use the same process as CosmosSingleSignature [...].
This means that what has been currently named CosmosSingleSignature
is actually compatible with other ecosystems different from the Cosmos one. For this reason, I think a better name should be used instead.
@dadamu Proposed GeneralSingleSignature
, but maybe even a shorter SingleSignature
can work.
What do you think @bragaz @kwunyeung?
Note
By looking at the code, we know that the signing algorithm used to verify the signature will be based on the type of the public key provided. The currently supported public key types are Ed25519
, Secp256r1
and Secp256k1
. As @dadamu said, for Solana we should use /cosmos.crypto.ed25519.PubKey
(hence why this signature also works for that ecosystem).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@RiccardoM I think we can use something like: StandardSingleSignature
or GeneralSingleSignature
is ok. Then we can add in the docs the supported chains of such signature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bragaz Hmm I'm not sure about those. I mean what does Standard
mean? Standard compared to what? Is there really a standard among all signatures?
The same for General
: I don't see why we should prepend General
and not just leaving SingleSignature
instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@RiccardoM From my side, the General
is compared to EVM
or other unique spec signatures. Noting that SingleSignature
is the general signature based on general private/public key signing should be enough as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm okay with SingleSignature
too. I was trying to add more context with General
and Standard
but it actually make more confusion after I've read @RiccardoM comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up renaming CosmosSingleSignature
to SingleSignature
, and removing EVMSignature
in favor or SingleSignature
as well. Now EVM-compatible signatures can be specified by simply using the proper SignatureValueEncoding
inside a SingleSignature
itself:
var evmSignature = types.NewSingleSignature(
types.SIGNATURE_VALUE_ENCODING_EMV_PERSONAL_SIGN,
signatureBz.
)
Since the verification for both Cosmos and EVM signatures relies on the PubKey
type anyway, there was no need to distinguish them aside from validating how the value was encoded. But this can be done by simply using an enum of possible value encoding algorithms supported. This should make it easier for clients and developers to create the correct signature type since we only have two possible types (SingleSignature
and CosmosMultiSignature
).
panic(fmt.Sprintf("unsupported signing mode: %s", signature.Mode)) | ||
} | ||
|
||
v6Signature := types.NewCosmosSingleSignature(signingMode, signature.Signature) | ||
signatureAny, err = codectypes.NewAnyWithValue(v6Signature) | ||
if err != nil { | ||
panic(err) | ||
} | ||
|
||
case *v5types.MultiSignatureData: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a test for MultiSignatrueData
migrations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added it
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
// Mode is the signing mode of the single signer | ||
cosmos.tx.signing.v1beta1.SignMode mode = 1; | ||
// ValueEncoding represents how the value has been encoded before being signed | ||
SignatureValueEncoding value_encoding = 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would remain the naming mode
with SignMode
instead of value_encoding
with SignatureValueEncoding
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this too, but then I thought: signature modes are things like Secp256k1, Ed25519, etc while in this case we want to specify how the signature value has been encoded before signing (Amino, Protobuf, PersonalSign, etc). So I think this makes more sense. Does it make sense to you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think PersonalSign
is not a encoding method since the plain text of it is raw text, it is the method to sign a raw text message into signature. Besides, secp256k1
and ed25519
algorithms are based on the keys since they use different curves to sign message with the key, it is described here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can just call it SignatureType
then? And have SIGNATURE_TYPE_COSMOS_AMINO
, SIGNATURE_TYPE_EVM_PERSONAL_SIGN
, etc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@RiccardoM That is great! I agree with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up going for SignatureValueType
which I think it's more explanatory than SignatureType
which might be confused for something else
type CosmosSignature interface { | ||
Signature | ||
GetSignatureValueEncoding() (SignatureValueEncoding, error) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't CosmosSignature
merge into Signature
and remove this interface?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it makes sense. Done that
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome job! Ready to ship~
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
Description
This PR adds support for different signature algorithms (namely EVM-compatible
personal_sign
) when creating a chain link, as per ADR-015.personal_sign
has been chosen to be the first EVM-compatible signature algorithm supported due to the fact that most wallets support this and it allows to specify an arbitrary message to be signed.Closes: #871
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change