Special thanks to Sacha Yves Saint-Léger and Danny Ryan for their reviews.
At the core of every Proof of Stake system is a signature scheme. Signatures are used to verify the identity of each verifier, allowing their actions, both good and bad, to be attributed to them.
We can verify integrity by looking at signed messages from a validator, and we can prove maliciousness by showing messages that violate consensus rules.
In fact, in eth2, the identity of a validator Is their public key. Specifically, each validator has two sets of keys: a signing key and a withdrawal key.
a signing key The validator needs the key to sign the verification and propose the block. Since a verifier is required to sign a message at least once per epoch, client software must have custody of the key.
Because the client software is always connected to the Internet, there is a possibility that someone’s signing key may have been tampered with. To reduce the impact of such a breach, the actions a validator can take are divided between the two keys.
The signing key, as mentioned above, is used for the verifier to perform its duties. On the other hand, withdrawal key A validator has the power to control funds (transfer*, and withdraw* ETH).
A validator needs to use his withdrawal key only a few times in his lifetime of being a validator. This means that they can be kept in cold storage and stored with a high degree of security (offline).
* Transfers and withdrawals are not enabled until at least step 1
That’s a lot of keys!
If for every 32ETH bet, one needs to save and use 2 unrelated keys to make a deposit, it will get out of hand very quickly.
Luckily, we have a solution. The solution is to make the keys use a common secret, so that storing the same secret allows access to multiple keys.
Mnemonics are another way of encrypting secrets and a very simple tool for people to store and back up their private keys.
The idea is that it is easier to remember or write Sausage Solution Loud Isolated Focus Glide Frame Door Clown Million Shuffle Impulse rather than 0x1e9f2afcc0737f4502e8d4238e4fe82d45077b2a549902b61d65367acecbccba without making any mistake.
getting keys from other keys
When interacting with a wallet, you may encounter a “path” of the form m/44’/60’/0’/0/0, These paths describe the relationship between the keys.
According to EIP 2333This relationship takes the form of a tree structure in which a key is determined by a source of entropy (the seed of the tree) and a tree path.
We use the seed to calculate the root of the tree and then build the tree in layers on top of this root. This tree of keys is defined purely through the relationship between the tree branch and the tree root.
In practice, this allows us to find any key in the tree, starting at the root, and computing the intermediate key in each branch we follow, until we reach that leaf, in which we are interested.
A wonderful consequence of this is that we can start with a single source of entropy (a mnemonic, for example), and create a practically infinite number of keys from there.
In addition, by only storing the mnemonic securely, you have a backup of every key used by your validator.
This idea is used in eth2 to allow a mnemonic to generate as many keys as a validator requires. For example, if you want to run 3 validators, you can use a single mnemonic to generate the withdrawal key.
[m / 0] / / [m] - [m / 1] [m / 2]
To each branch a. is separated by , So m/2 Meaning start with master key and follow branch 2.
EIP 2334 Indicates that the verifier has a signing key 0Child branch of the withdrawal key. This means in practice that, when the standard is followed, if you know the private key for withdrawal, you can calculate the corresponding private key for signing.
Continuing the example above, the signing keys would be found at:
[m / 0] - [m / 0 / 0] / / [m] - [m / 1] - [m / 1 / 0] [m / 2] - [m / 2 / 0]
While we tried to keep this example as simple as possible, in practice the paths involved are a bit long (EIP 2334 need to use m/12381/3600/i/0And m/12381/3600/i/0/0 for withdrawal and signing keys respectively). Nevertheless, the logic remains the same.
The important thing to remember is that if you know the mnemonic, you can calculate your withdrawal key, and derive your signing key from there.
Verifiers use the keystore as a method for exchanging client keys.
keystores They are files that contain private keys encrypted with the 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 start verification, you can give your client keystores and a password encrypting them (it requires both pieces of information to import your keys).
becoming a validator
The first step in becoming a validator is to generate the appropriate key. Once you write your mnemonic these will be generated.
Since there are no withdrawals or transfers in step 0, you do not need to have a keystore for your withdrawal keys; It is enough to store your mnemonic safely.
Since your validator clients require your signing keys, you will receive a keystore for each of your validators to store these keys.
Now is the time to submit! To become a validator, you will need to send your additional 32 ETH per validator stored data All your validator public keys are included.
The deposit data is then entered into the deposit contract on eth1. This contract is observed by the eth2 nodes which are responsible for copying the deposited data. Once your submitted data is copied, you are now officially a validator!
The easy way to become a validator
We are pleased to announce that we are working hard on a friendly interface to walk validators through this process. Stay tuned soon for updates on what Eth2 Launchpad is and how to use it!