Closed hacheigriega closed 3 days ago
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.
I will remove unused code like VRF key or CLI endpoint for creating validator with VRF in a separate PR tomorrow
- My thinking was that when we release a new binary that expects some new key to be registered, we would also update the CLI and have the validators use the updated CLI to generate a new set of keys and register their pubkeys.
- My thinking at the moment is that signing and verifying should be separated. Signing should be done using utility or context, whereas verifying should be supported by the pubkey module, which would expose the method through expected keepers. I think this separation makes sense because signing deals with the key file and is relevant only to validators. Would love to discuss more if you have doubts, but this is my current thinking.
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: