Special Thanks to Sacha Yves Saint-Leger And Danny Ryan for their insights.
At the core of every proof-of-stake system lies a signature schema. These signatures are used to authenticate validator identities, allowing good or bad actions to be attributed to them.
By verifying the messages signed by validators, we can confirm integrity and weed out messages that do not adhere to consensus rules.
In Ethereum 2.0, each validator is identified by a public key. Specifically, two sets of keys are available for each validator: a signature key and a withdrawal key.
This key is necessary for a validator to propose blocks and sign attestations. At least once an epoch, a validator must sign a message. The client software must be in possession of the key.
As the client software is always connected to the Internet, there is always the chance that the signature keys could be compromised. To mitigate the consequences of such an event, two keys can be used.
For the validation functions outlined above, a signature key is required. On the other hand, a withdrawal key has the power to control a validator’s funds (transfer and withdraw ETH).
Validators should not have to use their withdrawal key more than once in their lifetime, and it can be kept secure and stored offline.
That’s A Lot of Keys!
In order to get started with validating, one would need 32 ETH in funds, and two keys for deposits. This would be a lot of work.
Fortunately, there is a solution. EIPs 2333 and 2334 provide a set of standards that describe how withdrawal and signature keys are related, and how they can be derived from a single mnemonic.
Mnemonics are an effective way to scramble secret information, making it easier to store and protect keys.
It’s easier to remember what you are writing and how it looks. For example, the mnemonic “sausage problem noisy isolate focus slide frame door clown million Shuffle Impulse” generates the key 0x1e9f2afcc0737f4502e8d4238e4fe82d45077b2a549902b61d65367acecbccba without any errors.
Deriving Keys From Other Keys
You may have encountered paths when you interact with wallets. For example, m/44’/60’/0’/0/0. These paths are in a relationship with each other.
According to EIP 2333, this relationship can be represented as a tree structure. With a seed determining the root of the tree and layers of branches on top. The key tree can only be defined by the relationship between each branch and its root.
In simple terms, it allows one to locate any key in a tree by starting at the root and then working backwards until the desired branch is reached.
The amazing thing about this is that you can build an unlimited number of keys from one source (a mnemonic). Securely storing the mnemonic and ensuring a backup copy of each key used by the validator is essential.
This concept is used to enable one mnemonic to generate as many keys as a validator needs in the Ethereum 2.0 network.
To become a part of the eth2 network, it is necessary to generate keys. Withdrawal keys are created by running three validators and using one mnemonic. Each branch can be divided by a slash, beginning with the master key and working your way down. EIP 2334 is the validator sign code which has to be used to calculate the private key. The signing keys can be found in m/0/0, m/1/0, and m/2/0. The paths are very long, and the internet is required to sign and resign the keys. It is important to remember that once the mnemonic is mastered, the withdrawal keys can be calculated and the signing keys can be deduced.
Keystores are used to store and transfer passwords between computers, not on the same computer. Now, you are ready to validate. 32 ETH is necessary to become a validator. The deposit details are then saved to the eth1 contract, and managed by eth2 nodes who are responsible for copying the repository data. After the deposit details have been copied, you are officially a validator.
Our team has been busy creating a friendly interface for validators to navigate the process, and it will be available within the next few weeks. Use it to easily locate a validator.