-
Notifications
You must be signed in to change notification settings - Fork 9
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(pubkey): Pubkey module #342
base: main
Are you sure you want to change the base?
Conversation
refactor: added integration tests add query command feat: pkr module implementation with add-key tx and query endpoints feat: pkr module implemented with tests fix: fix e2e tests and proto query api
chore: CHANGELOG update
chore: proto lint and error msg typo fix chore: fix test name
chore: add missing proto files and lint test: improve add key msg validation and unit tests fix: use comet private key type to save to file style: lint refactor: replace some user defined errors with sdk ones
bafa188
to
e3f9d5e
Compare
I guess it's not entirely clear for me how this module interfaces with modules that need access to the private keys, or how the dependencies are managed. Maybe it helps to illustrate the following scenarios:
It would be nice if we could leave all the details of how the keys are managed/stored/etc in the PKR module. I don't think it's possible to express this purely in terms of method/function calls and we'll have to keep a manual file somewhere that links a consumer module identifier to the kind of key it needs.
Pretty sure I'm simplifying things too much, but I feel like this should be possible. |
|
chore: regenerate proto and lint proto chore: lint
572492a
to
e2be9f2
Compare
I will remove unused code like VRF key or CLI endpoint for creating validator with VRF in a separate PR tomorrow |
Lets discuss this tomorrow, maybe we can do some pseudocode to see pros and cons to both approaches. |
The key interface and the linting error are addressed in PR #365. |
Explanation of Changes
This PR adds a new module
x/pubkey
, which will serve as the public key registry for various signing keys used in the SEDA Protocol. The module store follows the following scheme:There is no application logic that prevents a validator operator from adding any public keys at any index. However, they should use the official, up-to-date CLI to generate the correct set of SEDA keys and send a transaction that would register their public keys at correct indices. In the initial implementation, the CLI generates a single secp256k1 key, whose public key is to be registered at index 0. The SEDA key file is saved in the same directory as the validator key file. By default, the location is
$CHAIN_DIR/config/seda_keys.json
.To generate and register the SEDA keys:
To use an existing SEDA key file:
To query a given validator's SEDA public keys: