Original title: “Popular Science | Eth2 Staking Guide # 4: Key”
Author: Carl Beekhuizen
Translation: A Jian
Thanks to Sacha Yves Saint-Leger and Danny Ryan for reviewing this article.
The core of the equity certification system is its signature scheme. The signature is used to verify the identity of the verifier who issued the operation, that is, to determine which operation was issued by which verifier (whether it is a “good” operation or a “bad” operation).
We can confirm that TA has complied with the agreement based on the message signed by a validator, or prove the maliciousness of a validator by displaying a message that violates the consensus rules.
In fact, in the Eth2 system, the identity of the verifier is determined based on its public key. Each verifier has two sets of keys: a signing key pair and a withdrawal key pair.
Signing key pair
The so-called “signing key” refers to the key used by a verifier when signing the witness message and the proposed block. Because the verifier signs at least one message every epoch, the client software must host the signing key.
Withdrawal key pair
Because the client software is always connected to the network, there is a possibility that the signature key will be lost or stolen. In order to reduce the impact of such events, the operations that the verifier can perform are divided into two different keys to initiate.
The signing key, as described above, is used to fulfill the responsibility of the verifier. On the other side, the “withdrawal key” is used to control the verifier’s funds.
In the entire life cycle of the verifier, the verifier only needs to use the withdrawal key in a very few times. This means that the withdrawal key can be placed in a cold wallet and stored (offline) in a sufficiently secure place.
Note: The fund transfer and withdrawal functions of the validator will not go online until Phase 1.
Translator’s Note: The signing key and withdrawal key here are commonly used by the author in the singular form “a signing key” “a withdrawal key”, but here I turn into “signing key pair” and “withdrawal key pair” “. Because according to our understanding of cryptography, to ensure identity identity, public key cryptography (public-private key pair) is indispensable: the verifier uses the two public keys corresponding to the signed private key and the withdrawal private key in the registry Register, and then use its private key to sign a message in its life cycle, its identity can be confirmed. The withdrawal process is the same, and it is the same as our current method of using Ethereum accounts.
Why are there so many keys!
If every time you want to pledge 32 ETH, users have to save and use two sets of unrelated keys, which is too troublesome.
In Eth2, we can use EIP-2333 and EIP-2334 to solve this problem: these two EIPs propose a set of standards that describe how the signing key and withdrawal key can be related, and how these two sets of keys It can be derived from the same Mnemonic (mnemonic).
Mnemonics are another way to protect passwords with codes, and are the simplest way for ordinary users to store and back up private keys. In short, just put
This private key is transformed into
sausage solution loud isolate focus glide frame door clown million shuffle impulse
Such readable words, and then write down or write down, so that it is easier to save and less prone to errors.
Derive other keys from one key
When using a wallet, you may encounter
m/44'/60'/0'/0/0 something that looks like a path like this. This path is used to describe the relationship between keys.
According to EIP 2333, the system formed by deriving other keys from a key (that is, a set of mnemonics) is like a tree, and the derived key is based on the “seed” of the tree ( That is the initial key) and the path of the tree.
We use seeds to calculate the root of the tree, derive keys from the roots and branches of the tree, and construct the entire key tree layer by layer. Therefore, it can be considered that the entire key tree is entirely determined based on the relationship between the branches and roots of the tree. (Translator’s Note: It can also be seen from this description that the entire key tree is infinitely large, because it can be derived indefinitely. When using it, just remember which branches of the keys are used and have funds Just fine.)
In use, this method of deriving keys allows us to find any key we want to use: just start from the root of the tree and calculate the intermediate key by branch, and finally calculate the key we want to use ).
An interesting result is that we can start with a single random number (such as a set of mnemonics) and derive an infinite number of keys. Used in Eth2, a set of mnemonics can generate as many keys as the verifier needs. For example, if you need to use a set of mnemonics to generate three private keys for withdrawal, you can derive it like this:
Each branch is marked with “/”, so “m / 2” indicates the second branch derived from the master key.
EIP 2334 points out that the verifier’s signature key can use the 0th sub-branch of the withdrawal private key. In practice, this means that as long as you follow this standard, as long as you know the withdrawal private key, you can calculate the corresponding private key for signing. The calculation process is also shown in the above example:
We are here to simplify as much as possible before cite such examples, in fact, the path will be a little longer (for example, EIP 2334 requires the use of
m/12381/3600/i/0/0 for such a long path Cash used to derive the private key and a private key signature). However, the logic is exactly the same.
Remember: If you know your mnemonic, you can derive the withdrawal private key, and then derive the signature private key.
The authenticator client uses the Keystore file to exchange keys.
Keystore is a file format that contains the user’s private key crypto with a password (password), so it can be safely stored and spread securely between computers (as long as the password does not exist on the same computer).
If you are ready to start verification, you can import the keystore into the client (of course, you also need to enter the password so that the client can export the private key).
Become a verifier
The first step in becoming a verifier is to generate a key. Please make sure to use secure software to generate the private key in a secure environment. Please write it down after generation.
Because there is no withdrawal function in Phase 0 stage and you can’t transfer the account, you don’t need to use Keystore to store the withdrawal private key. It is enough to ensure that your mnemonic is safe.
If your verifier client needs your signed private key, then after you enter the private key, you can get a corresponding Keystore file (the crypto password is also entered by yourself). As many validators as you run, you will get as many keystores as possible.
In order to register as a verifier, you need to prepare a deposit of 32 ETH for each verifier, plus your margin data (containing your verifier’s public key), and send it to the margin contract on the Eth1 chain.
Margin data will be recorded in the margin contract. Eth2 nodes can observe this contract, so they can obtain the margin data. After your margin data is accepted by the Eth2 chain, you will officially become a validator.
The easiest way
We have been developing a friendly interface to help validators complete the registration process. Our next update will introduce Eth2 Lauchpad and how to use it.