-
Notifications
You must be signed in to change notification settings - Fork 226
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
Add support for secp256k1 consensus keys #1358
Merged
romac
merged 5 commits into
informalsystems:main
from
mkaczanowski:support_secp256k1_consenus_key_config
Sep 29, 2023
Merged
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
9759848
support secp256k1 curve in priv_validator_key.json
mkaczanowski 05f117d
fix invalid comments
mkaczanowski 1c65ded
fix inconsistent variable naming
mkaczanowski 7ff521d
fix clippy lints
mkaczanowski b21e644
Add changelog entry
romac File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
- `[tendermint]` Add support for secp256k1 consensus keys | ||
([\#1364](https://github.com/informalsystems/tendermint-rs/issues/1364)) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
11 changes: 11 additions & 0 deletions
11
config/tests/support/config/priv_validator_key.secp256k1.json
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
{ | ||
"address": "0799B6E1F13F1ECC7E891765F499A73665F42866", | ||
"pub_key": { | ||
"type": "tendermint/PubKeySecp256k1", | ||
"value": "A2hdb2LlTQ+sxqpknkA2v0RgQ6a6Q4t5OwhebIqSr8qu" | ||
}, | ||
"priv_key": { | ||
"type": "tendermint/PrivKeySecp256k1", | ||
"value": "aVmw0npSBEqPU4v6qEZ9o3z5nCpHjicwFDdIBRUbSrM=" | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Feature-guarded enum variants bring fragility. I'd rather make the whole thing non-optional,
secp256k1
support does not add much in terms of dependencies. But the enum is#[non_exhaustive]
so maybe it's OK for now.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.
since the
secp256k1
is marked almost everywhere as feature I fell with the same approach. But I agree that conditional enums are not as great. Though rust is pretty good with handling conditional compilation via features.Therefore I hold no strong opinion 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.
The problem with conditional enum variants is that they make match expressions fail to compile dependent on features.
#[non_exhaustive]
does a lot to make it less fragile, as you can't have a match that would be exhaustive without certain features and then fail to compile if the features are enabled. But anyone wanting to match on the conditionally-enabled variant would have to enable the corresponding feature. This, perhaps, is no worse than other conditionally defined APIs, so I'm willing to let it go.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.
FYI, I believe the original motivation for feature-gating was at the time libsecp256k1 was being used and it didn’t work with WASM.
We’ve since moved to the pure Rust
k256
crate so that isn’t an issue.I think it would probably make more sense to feature gate all the cryptographic functionality under a single feature rather than just secp256k1, that way people who just want e.g. tendermint-rpc for an API client aren’t pulling in a bunch of crypto deps they aren’t using.