Key Management across State Chain and CFE

[kylezs]

Ideally we have one place to manage the keys across the state chain and the CFE. It's probably easiest to use the substrate standard and then have the CFE read from that keystore, as the CFE needs to use the chain's keys anyway, to submit extrinsics back to the chain.

How does substrate do it? and does anyone have ideas on how the CFE might then use the substrate keys?

[morelazers]

You can find some hints in the state-chain/node directory.

/// Configuration of the client keystore.
#[derive(Debug, Clone)]
pub enum KeystoreConfig {
	/// Keystore at a path on-disk. Recommended for native nodes.
	Path {
		/// The path of the keystore.
		path: PathBuf,
		/// Node keystore's password.
		password: Option<SecretString>
	},
	/// In-memory keystore. Recommended for in-browser nodes.
	InMemory,
}

It appears as though you are able to configure a path on disk from where the node will read its keys.

[morelazers]

I would probably be in favour of storing the Engine-specific keys outside of any directory created by Substrate, in the event that a failure (or even a normal operation!) of the State Chain node results in data loss. What would the argument be for merging these locations?

Maybe we can allow the Operator to specify a path to a directory which contains private keys which are required for the various broadcasters?

[kylezs]

The argument is simplicity really, we'd already be duplicating one key by having a separate CFE store, the validator key, because the CFE needs to submit extrinsics using that key.

I'm pretty sure substrate stores keys in a separate location to chain data for this reason, but @andyjsbell or @dandanlen would be able to confirm/deny this.

[andyjsbell]

Maybe this will help, apologies for long post, items omitted that have nothing to do with the keystore.

At present the keystore is stored at specified --base-path under keystore

Chainflip Team <https://github.com/chainflip-io>
Runs the state chain of Chainflip

USAGE:
    state-chain-node [FLAGS] [OPTIONS]
    state-chain-node <SUBCOMMAND>

FLAGS:
        --keystore-path <PATH>                                   
            Specify custom keystore path

        --keystore-uri <keystore-uri>                            
            Specify custom URIs to connect to for keystore-services

        --node-key <KEY>                                         
            The secret key to use for libp2p networking.
            
            The value is a string that is parsed according to the choice of `--node-key-type` as follows:
            
            `ed25519`: The value is parsed as a hex-encoded Ed25519 32 byte secret key, i.e. 64 hex characters.
            
            The value of this option takes precedence over `--node-key-file`.
            
            WARNING: Secrets provided as command-line arguments are easily exposed. Use of this option should be limited
            to development and testing. To use an externally managed secret key, use `--node-key-file` instead.
        --node-key-file <FILE>
            The file from which to read the node's secret key to use for libp2p networking.
            
            The contents of the file are parsed according to the choice of `--node-key-type` as follows:
            
            `ed25519`: The file must contain an unencoded 32 byte or hex encoded Ed25519 secret key.
            
            If the file does not exist, it is created with a newly generated secret key of the chosen type.
        --node-key-type <TYPE>
            The type of secret key to use for libp2p networking.
            
            The secret key of the node is obtained as follows:
            
            * If the `--node-key` option is given, the value is parsed as a secret key according to the type. See the
            documentation for `--node-key`.
            
            * If the `--node-key-file` option is given, the secret key is read from the specified file. See the
            documentation for `--node-key-file`.
            
            * Otherwise, the secret key is read from a file with a predetermined, type-specific name from the chain-
            specific network config directory inside the base directory specified by `--base-dir`. If this file
            does not exist, it is created with a newly generated secret key of the chosen type.
            
            The node's secret key determines the corresponding public key and hence the node's peer ID in the context of
            libp2p. [default: Ed25519]  [possible values: Ed25519]

        --password <password>                                    
            Password used by the keystore

        --password-filename <PATH>                               
            File that contains the password used by the keystore

[dandanlen]

It might help to think about the different types of keys we need.

• Aura Key
• GRANDPA Key
• Stash key to control funds (claiming + determines nodeId for staking purposes)
• Controller / Session* key, used by the CFE to sign transactions. Presumably setting/updating this requires access to the Stash key.
• Anything else?

I would suggest one keystore that stores the Aura, Grandpa and CFE / Controller keys.
I don't think the stash key should be stored on the server at all - it should be used only for intervention by the operator of the validator node when they want to claim funds or update the controller key.

*I'm using these interchangeably but not sure if they really are. Polkadot has a the notion of controller keys for stakers and session keys for... I'm not quite sure what? @andyjsbell ? Either way I think we only need one of the two, it doesn't really matter what we call it.

[morelazers]

We also need keys for each of the account-based chains on which we are broadcasting transactions: ETH | BSC | etc.

[dandanlen]

Oof yes, true. I guess it makes sense for these to also belong to the CFE keystore, right? How do we get them in there?

BSC

👀 something you want to tell us?

[morelazers]

All hail CZ.