feat(pubkey): Pubkey module

[hacheigriega]

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:

validator_address | index -> public_key

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:

sedad tx pubkey add-seda-keys --from <validator_operator_key> --gas-prices 1000000000aseda --gas auto --gas-adjustment 2.0

To use an existing SEDA key file:

sedad tx pubkey add-seda-keys --key-file ~/.sedad/config/seda_keys.json --from <validator_operator_key> --gas-prices 1000000000aseda --gas auto --gas-adjustment 2.0

To query a given validator's SEDA public keys:

sedad query pubkey validator-keys <validator_operator_addr>

[Thomasvdam]

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:

1. We create a new module that needs to make use of the PKR, how does this new key get added?
2. A module needs to have something signed, how does this happen?

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.

• New module needs a keypair: add an entry to a list that consists of an ID (the index, should be unique) and the key implementation (how to generate, how to sign?)
• On add-keys command the CLI iterates over the list, generates keys at the index of that module, publishes the new public keys in the TX. Private keys get stored in 1 file.
• New module needs something signed, calls a method on the PKR module to sign data with the key under ID X, PKR returns signed bytes.

Pretty sure I'm simplifying things too much, but I feel like this should be possible.

[hacheigriega]

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

[hacheigriega]

I will remove unused code like VRF key or CLI endpoint for creating validator with VRF in a separate PR tomorrow

[Thomasvdam]

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

[hacheigriega]

The key interface and the linting error are addressed in PR #365.

[gluax]

My comments may be me not understanding the cosmos SDK too well. But it's a security issue if we store private info in plain text in a file.

[gluax]

Is this standard for cosmos? I'd say it's a risk to store a private key as plain text in a file. So we should additionally have the option to do it as an ENV var.

[hacheigriega]

created an issue based on what we discussed: #368

[gluax]

These are private keys right? This is fine for devnet. Cosmos offers the file backend for a similar case, but they do specify you should NOT use file storage for an official deployment.

This security stuff could also done in another pr. Also maybe we could leverage the existing system cosmos has to use a different storage backed.

[hacheigriega]

created an issue #368

[gluax]

Oh, I do see this here, can we just use the keyring to store these private keys? In a dev environment that works cause they allow you to use the file backend.

[hacheigriega]

Keyring is unsuitable for this purpose because we need repeated access to the key without the key owner's approval every time.