Special thanks to Sacha Yves Saint-Léger and Danny Ryan for their review.
At the heart of every proof-of-stake system is a signature system. The signatures are used to verify the identity of each validator allowing them to attribute their actions, good and bad.
We can verify honesty by examining a validator’s signed messages, and we can prove maliciousness by showing messages that violate consensus rules.
In fact, in eth2, the identity of a validator East their public key. Concretely, each validator has two sets of keys: a signing key and a withdrawal key.
Signing keys
A signing key is the key a validator needs to sign attestations and offer blocks. Since a validator must sign a message at least once per epoch, the client software must have custody of the key.
Withdrawal keys
Since the client software is always connected to the Internet, it is of course possible that the signing key could be compromised. To reduce the impact of such a violation, the actions a validator can perform are split between two keys.
The signing key, as explained above, is used by the validator to accomplish its tasks. On the other hand, the removal key has the power to control a validator’s funds (transfer* and withdrawal* of ETH).
A validator should only need to use their withdrawal keys a few times during their validator life. This means they can be stored cold and stored with a high degree of security (offline).
* Transfers and withdrawals are not activated until at least phase 1
That’s a lot of keys!
If for every 32ETH staked, you had to save and use 2 independent keys to make a deposit, this would get out of hand very quickly.
Fortunately, we have a solution. The solution is to make the keys use a common secret, so that storing a single secret provides access to multiple keys.
In eth2 this is achieved via EIPs 2333 And 2334: a set of standards that describe how withdrawal and signing keys are related, and how they can be derived from a single mnemonic.
Mnemonic
Mnemonics are another way to encode secrets and are a much simpler way for users to store and back up their private keys.
The idea being that it is easier to memorize or write sausage solution strong isolate focus glide frame door clown million shuffle impulse that 0x1e9f2afcc0737f4502e8d4238e4fe82d45077b2a549902b61d65367acecbccba without making any mistakes.
Derive keys from other keys
When interacting with wallets, you may have encountered “paths” like m/44’/60’/0’/0/0. These paths describe a relationship between keys.
According to PEI 2333this relationship takes the form of a tree structure in which a key is determined by an entropy source (the tree seed) and a tree path.
We use the seed to calculate the root of the tree, then build the tree in layers on top of that root. This key tree is defined only by the relationship between the branch followed in the tree and the root of the tree.
Concretely, this allows us to find any key in the tree starting at the root, and calculating the intermediate key at each branch that we follow, until we reach the leaf that interests us.
A wonderful consequence of this is that we can start from a single source of entropy (a mnemonic, for example), and from there construct a virtually unlimited number of keys.
Additionally, by securely storing just the mnemonic, you have a backup of every key used by your validator.
This idea is used in eth2 to allow a single mnemonic to generate as many keys as a validator needs. For example, if you want to run 3 validators, you could use a single mnemonic to generate the withdrawal keys located at
m/0,
m/1,
m/2.
(m / 0) / / (m) - (m / 1) \ \ (m / 2)
Each branch is separated by a / SO m/2 means start with the master key and follow branch 2.
PEI 2334 indicates that the signing key of the validator is 0th child branch of the removal key. In practice, this means that when the standard is met, if you know the withdrawal private key, you can calculate the corresponding signing private key.
Using the example above, the signing keys would be located at:
m/0/0,
m/1/0,
m/2/0.
(m / 0) - (m / 0 / 0) / / (m) - (m / 1) - (m / 1 / 0) \ \ (m / 2) - (m / 2 / 0)
Although we have tried to keep this example as simple as possible, in practice the paths involved are a bit longer (PEI 2334 requires using m/12381/3600/i/0And m/12381/3600/i/0/0 for key collection and signing respectively). However, the logic remains the same.
The important thing to remember is that if you know the mnemonic, you can calculate your withdrawal keys, and from there derive your signing keys.
Key storage
Validator clients use keystores as a method of key exchange.
Key stores are files containing private keys encrypted with a user’s password. They can be stored and transferred securely between computers provided the password is not stored on the same computer.
When you’re ready to begin validation, you can give your client the keystores and the password that encrypts them (they need both pieces of information to import your keys).
Become a validator
The first step to becoming a validator is to generate the appropriate keys. These will be generated once you write down your mnemonic.
Since there are no withdrawals or transfers in phase 0, you don’t need keystores for your withdrawal keys; storing your mnemonic securely is enough.
Since your validator clients need your signing keys, you will receive a keystore for each of your validators to store these keys.
Now it’s filing time! To become a validator, you will need to send 32 ETH per validator in addition to your deposit data containing all your validator public keys.
The deposit data is then saved in the deposit contract on eth1. This contract is monitored by eth2 nodes which are responsible for copying the deposit data. Once your deposit data is copied, you are now officially a validator!
Become a validator easily
We’re happy to announce that we’ve been working hard on a user-friendly interface to guide validators through this process. Stay tuned soon for an update on what the Eth2 Launchpad is and how to use it!
