Special thanks to Sacha Yves Saint-Leger and Danny Ryan for their reviews.
At the core of all proof-of-stake systems is a signature scheme. The signature is used to verify the identity of each validator and is therefore attributed to both good and bad behavior.
Verifiers can verify honesty by looking at the signed messages, and can prove malice by marking messages that violate consensus rules.
In fact, in eth2, the identity of the validator is is Their public key. Specifically, each validator has two sets of keys: a signing key and a withdrawal key.
signing key
all signing key This is the key that verifiers need to sign proofs and propose blocks. The validator must sign the message at least once per epoch, so the client software must manage the keys.
Withdrawal key
Because the client software is always connected to the Internet, there is a possibility that the signing key may be compromised. To reduce the impact of such a violation, what a validator can do is split the key into two.
As described above, the signing key is used by the verifier to perform its duties. On the other hand, Withdrawal key Has control over the validator’s funds (ETH transfers* and withdrawals*).
A validator will only need to use their withdrawal key a few times during their time as a validator. This means they can be refrigerated and stored at a high level of security (offline).
* Transfers and withdrawals are not possible until at least step 1.
There are too many keys!
If you had to store and use two unrelated keys to deposit for every 32 ETH staked, this would very quickly become impossible.
Fortunately, there is a solution. The solution is to have the keys use a common secret, so that storing a single secret allows access to multiple keys.
In eth2 this is achieved through EIP. 2333 and 2334: A standard set that describes how retrieval keys and signing keys are related and how they can be derived from a single mnemonic.
mnemonics
Mnemonics are another way to encode secrets and a much simpler means for people to store and back up their private keys.
the idea that it is simpler to remember or write down sausage solution loud isolate focus glide frame door clown million shuffle impulse see 0x1e9f2afcc0737f4502e8d4238e4fe82d45077b2a549902b61d65367acecbccba Without making any mistakes.
Derive a key from another key
When interacting with your wallet, you may have encountered “paths” of the following format: m/44’/60’/0’/0/0. These paths describe relationships between keys.
According to EIP 2333This relationship takes the form of a tree structure whose keys are determined by the entropy source (the seed of the tree) and the tree path.
We use the seed to compute the root of the tree and then build the tree as a layer on top of this root. This key tree is defined purely by the relationships between the branches that follow in the tree and the tree root.
Practically, you can find a key in a tree by starting from the root and calculating intermediate keys on each branch you follow until you reach the leaf of interest.
The surprising consequence of this is that you can start with a single entropy source (e.g. a mnemonic) and build a virtually unlimited number of keys from there.
Additionally, simply storing the mnemonics securely allows you to back up all the keys used by the validator.
This idea is used in eth2 to allow a single mnemonic to generate as many keys as the validator needs. For example, if you want to run three validators, you can use a single mnemonic to generate withdrawal keys located at:
m/0,
m/1,
m/2.
(m / 0) / / (m) - (m / 1) \ \ (m / 2)
Each branch is divided as follows: / so m/2 This means it starts with the master key and follows branch 2.
EIP 2334 The validator’s signing key is: 0The second subbranch of the withdrawal key. In practice, this means that if you follow the standard and know the private key for the withdrawal, you can calculate the corresponding private key for the signature.
Continuing with the example above, the signing key can be found 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)
I’ve tried to keep this example as simple as possible, but the actual paths involved are a bit longer (EIP 2334 need to use m/12381/3600/i/0and m/12381/3600/i/0/0 for withdrawal and signing keys respectively). Nonetheless, the logic remains the same.
The important thing to remember is that if you know the mnemonic, you can calculate the withdrawal key and derive the signing key from there.
save key
The validator client uses key storage as its key exchange method.
keystore A file containing the private key encrypted with the user’s password. If your passwords aren’t stored on the same computer, you can safely store them and transfer them between computers.
When you’re ready to start validation, you can provide the client with your keystore and the password to encrypt it (you’ll need both pieces of information to get the key).
Become a validator
The first step to becoming a validator is to generate the appropriate keys. You can create mnemonics by writing them down.
In stage 0, there are no withdrawals or transfers, so there is no need for a keystore for withdrawal keys. Simply storing your mnemonic safely is enough.
Validator clients require signing keys, so each validator receives a keystore where they can store these keys.
Now it’s deposit time! To become a validator you will need to send an additional 32 ETH per validator. data deposit Contains all validator public keys.
The deposit data is then written to the deposit contract on eth1. This contract is monitored by eth2 nodes, which are responsible for copying deposit data. Once your deposit data has been copied, you are now officially a validator!
Easy way to become a validator
We’re happy to share that we’ve worked hard to create a friendly interface to guide validators through this process. Stay tuned for updates on what Eth2 Launchpad is and how to use it soon!