Ethereum Validator Keys
An overview of ethereum staking keys
Last updated
An overview of ethereum staking keys
Last updated
Both of these keys (Keys for EOA-wallets and validator-keys) are based on the same idea and use elliptic-curve cryptography to create keys. However, validator keys have additional functionality, and its keys require different parameters when creating them, and use the Boneh-Lynn-Shacham (=BLS) signature scheme.
Compared to EOA-keys, where users only have a single private key to access their funds, validator-keys offers two different keys. The validator private key and the withdrawal private key.
As seen in the cutout below the validator signing key consists of two elements:
Validator private key
Validator public key
The purpose of the validator private key is to actively sign on-chain operations such as block proposals and attestations. Therefore these keys have to be held in a hot wallet.
This flexibility has the advantage to move validator signing keys very quickly from one device to another, however, if they have gotten lost or stolen, the thief has the ability to act maliciously in two ways:
Force a voluntary exit, which stops the validator from "staking", and grants access to its ETH balance to the withdrawal key owner.
The validator public key is included in the deposit data which allows the consensus layer to identify the validator.
Just like the validator keys, the withdrawal keys also consist of two components:
Withdrawal private key
Withdrawal public key
Losing this key means losing access to the validator balance. However, the validator can still sign attestations and blocks since these actions require the validator private key, but there is little to no incentive to do so if the keys are lost.
To withdraw, the validator status needs to be "exited".
Each validator has their own unique deposit data by which they are identified by the beaconchain. Four keys for one validator.
Q: How can I re-deposit to my validator balance? (e.g. Effective balance has dropped)
A: Send another transaction (>=1ETH) to the deposit contract with the validator specific deposit data as the transaction input. After the first deposit-transaction, the unique deposit data is stored on the blockchain and can be found on various explorers.
Note: The deposit contract requires about 150,000 gas limit.
Over the last few years, we have become so accustomed to the 12 or 24 word-system. Why do we take steps back again and make our lives more complicated and more insecure with locally stored keys?
Known hardware wallets will not be able to support validator key generation until the BLS library gets audited. EIP-2333 and EIP-2334 offer a solution but yet need to be implemented.
Mnemonics and paths are a known feature and usually found when users try to access their hardware wallets.
"Old ETH 1.0" path structure and example:
m/44'/60'/0'/0
m / purpose' / coin_type' / account' / change / address_index
The same logic applies to validator Keys, just with different parameters. There is a single "master key" (=Mnemonic phrase) which allows the user to attach as many validators to a single withdrawal key as they want. This way the user can derive all keys from the Mnemonic phrase.
A simplified overview would look like the following:
Credits: Nishant Das for fact-checking
