Description

Keys for the validator client are randomly generated at runtime. They should be loaded from the filesystem.

Steps to resolve

• Define some file structure for validator client local files.
• At runtime, read the local directory and instantiate all validators.
• Define a key generation routine which can generate these local files.

Additional Info

File structure

I propose a structure like this:

~/.lighthouse/
  - validators/
     - <validator-id>/
       - private.key
       - ...

I propose that validator-id be some unique, deterministic identifier for a validator. The validator public key is a good candidate. Inside the validator-id directory we can store all files relevant to that validator, such as:

• Database for slashing protection
• Database for proof-of-possession (required in later phases)
• Per-validator configuration files.

Multiple validators

We should support multiple validators running on the same binary. For the testnet version, we should just instantiate a validator for every configuration file we can find, instead of adding flags to load a subset of validators.

We can likely handle the case where a user wishes to run multiple binaries on the same machine by pointing the binary to a different config dir. E.g., $ validator-client --config-dir ~/other-config.

Key generation

During key generation I suggest we build a deposit-info.json file which contains the information necessary to register the validator on the Eth1 chain. See DepositInput for the required fields. withdrawal_credentials are defined here.