Skip to content
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

Merged
merged 21 commits into from
Jul 21, 2022

Conversation

RiccardoM
Copy link
Contributor

@RiccardoM RiccardoM commented Jul 18, 2022

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...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

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...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

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>
@github-actions github-actions bot added kind/build Related to the build of the project x/CLI x/profiles Module that allows to create and manage decentralized social profiles labels Jul 18, 2022
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
Copy link

codecov bot commented Jul 18, 2022

Codecov Report

Merging #968 (3bcbc99) into master (c7ff50d) will decrease coverage by 0.05%.
The diff coverage is 76.25%.

❗ Current head 3bcbc99 differs from pull request most recent head c9faac3. Consider uploading reports for the commit c9faac3 to get more accurate results

@@            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     
Impacted Files Coverage Δ
x/profiles/types/models_chain_links.go 74.28% <73.77%> (-2.86%) ⬇️
x/profiles/legacy/v6/store.go 67.55% <84.61%> (+4.44%) ⬆️
x/profiles/types/codec.go 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c7ff50d...c9faac3. Read the comment docs.

Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
@RiccardoM RiccardoM marked this pull request as ready for review July 18, 2022 11:40
@RiccardoM
Copy link
Contributor Author

@dadamu @bragaz If you can review this it would be great. I will take care of updating the docs once everything is fine for you

Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
@RiccardoM RiccardoM changed the title feat: ADR-015: Improve chain link signature support feat!: ADR-015: Improve chain link signature support Jul 18, 2022
…/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>
Copy link
Contributor

@leobragaz leobragaz left a 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?

@RiccardoM
Copy link
Contributor Author

RiccardoM commented Jul 19, 2022

Awesome work! So this supports also the signatures made with Metamask right?

Yes, it does. It supports ETH personal_sign signature. The test case present is actually testing against a signature generated with MetaMask

// --------------------------------------------------------------------------------------------------------------------

// CosmosSingleSignature is the signature data for a single signer
message CosmosSingleSignature {
Copy link
Contributor Author

@RiccardoM RiccardoM Jul 20, 2022

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).

Copy link
Contributor

@leobragaz leobragaz Jul 20, 2022

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.

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

@RiccardoM RiccardoM Jul 21, 2022

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:
Copy link
Contributor

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?

Copy link
Contributor Author

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>
@github-actions github-actions bot added the kind/adr An issue or PR relating to an architectural decision record label Jul 21, 2022
@github-actions github-actions bot added the kind/ci Improve the CI/CD label Jul 21, 2022
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
@github-actions github-actions bot removed the kind/ci Improve the CI/CD label Jul 21, 2022
Signed-off-by: Riccardo Montagnin <riccardo.montagnin@gmail.com>
@RiccardoM RiccardoM requested a review from dadamu July 21, 2022 06:37
// 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
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

@dadamu dadamu Jul 21, 2022

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

@RiccardoM RiccardoM Jul 21, 2022

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

Comment on lines 241 to 244
type CosmosSignature interface {
Signature
GetSignatureValueEncoding() (SignatureValueEncoding, error)
}
Copy link
Contributor

@dadamu dadamu Jul 21, 2022

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?

Copy link
Contributor Author

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>
@RiccardoM RiccardoM requested a review from dadamu July 21, 2022 08:54
Copy link
Contributor

@dadamu dadamu left a 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>
@RiccardoM RiccardoM added the automerge Automatically merge PR once all prerequisites pass label Jul 21, 2022
@mergify mergify bot merged commit 058447a into master Jul 21, 2022
@mergify mergify bot deleted the riccardom/adr-015-improve-chain-link-signature-support branch July 21, 2022 12:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge Automatically merge PR once all prerequisites pass kind/adr An issue or PR relating to an architectural decision record kind/build Related to the build of the project x/CLI x/profiles Module that allows to create and manage decentralized social profiles
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support more signature algorithm and specifications inside chain links proofs
3 participants