Keys in proof-of-stake Ethereum
Ethereum secures user assets using public-private key cryptography. The public key is used as the basis for an Ethereum address—that is, it is visible to the general public and used as a unique identifier. The private (or 'secret') key should only ever be accessible to an account owner. The private key is used to 'sign' transactions and data so that cryptography can prove that the holder approves some action of a specific private key.
Ethereum's keys are generated using elliptic-curve cryptography (opens in a new tab).
However, when Ethereum switched from proof-of-work to proof-of-stake a new type of key was added to Ethereum. The original keys still work exactly the same as before—there were no changes to the elliptic-curve-based keys securing accounts. However, users needed a new type of key for participating in proof-of-stake by staking ETH and running validators. This need arose from scalability challenges associated with many messages passing between large numbers of validators that required a cryptographic method that could easily be aggregated to reduce the amount of communication required for the network to come to consensus.
This new type of key uses the Boneh-Lynn-Shacham (BLS) signature scheme (opens in a new tab). BLS signatures from many validators can be aggregated into one signature that is verified in a single check, which keeps consensus messages small. BLS is not quantum-safe, so the post-quantum roadmap plans to replace validator BLS keys with hash-based keys.
The two types of validator keys
Before the switch to proof-of-stake, Ethereum users only had a single elliptic-curve-based private key to access their funds. With the introduction of proof-of-stake, users that wished to be solo stakers also required a validator key and a withdrawal key.
The validator key
The validator signing key consists of two elements:
- Validator private key
- Validator public key
The purpose of the validator private key is to sign onchain operations such as block proposals and attestations. Because of this, these keys must be held in a hot wallet.
This flexibility has the advantage of moving validator signing keys very quickly from one device to another, however, if they have gotten lost or stolen, a thief may be able to act maliciously in a few ways:
- Get the validator slashed by:
- Being a proposer and signing two different beacon blocks for the same slot
- Being an attester and signing an attestation that "surrounds" another one
- Being an attester and signing two different attestations having the same target
- 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 transaction data when a user deposits ETH to the staking deposit contract. This is known as the deposit data and it allows Ethereum to identify the validator.
Withdrawal credentials
Every validator has a property known as withdrawal credentials. The first byte of this 32-byte field identifies the account type: 0x00 represents legacy BLS (pre-Shapella, non-withdrawable) credentials, 0x01 represents legacy credentials that point to an execution address, and 0x02 represents the modern compounding credential type.
Validators with 0x00 BLS keys must update these credentials to point to an execution address in order to activate excess balance payments or full withdrawal from staking. This can be done by providing an execution address in the deposit data during initial key generation, OR by using the withdrawal key at a later time to sign and broadcast a BLSToExecutionChange message. Proposals to phase out 0x00 credentials ahead of the post-quantum transition are under discussion, so validators still on 0x00 should convert now.
More on validator withdrawal credentials
The withdrawal key
The withdrawal key will be required to update withdrawal credentials to point to an execution address, if not set during initial deposit. This will enable excess balance payments to begin being processed, and will also allow users to fully withdraw their staked ETH.
Just like the validator keys, the withdrawal keys also consist of two components:
- Withdrawal private key
- Withdrawal public key
Losing this key before updating withdrawal credentials to 0x01 type means losing access to the validator balance. The validator can still sign attestations and blocks since these actions require the validator's private key, however there is little to no incentive if the withdrawal keys are lost.
Separating the validator keys from the Ethereum account keys enables multiple validators to be run by a single user. With 0x02 credentials, one validator can hold up to 2,048 ETH, so a larger stake no longer needs to be split across many validators.
One plate carries the staker's wallet at the back left, the deposit contract in the middle and the validators along the front. Each validator carries its signing key, a cube; with 0x00 credentials each also has a withdrawal key, a flat slab on the plate in front of it, joined to it by a short pipe. Once a withdrawal address is set, it appears as its own block along the back of the plate, linked to the validators: it can be the wallet that made the deposits or any other address. With 0x00 or 0x01 credentials the wallet stakes 96 ETH as 3 validators of 32 ETH each; with 0x02 it stakes the same 96 ETH in one validator, since one 0x02 validator can hold up to 2,048 ETH. Step 1: the wallet sends one deposit per validator to the deposit contract. Each carries deposit data: one validator's public signing key and its withdrawal credentials. Step 2: the beacon chain processes the deposits and activates the validators, each identified by its public signing key. Step 3: each validator signs blocks and attestations with its signing private key. Step 4 depends on the withdrawal credentials. With 0x00, no withdrawal address is set until the withdrawal key signs a BLSToExecutionChange message for the beacon chain pointing the validator at an execution address, which changes its credentials to 0x01. With 0x01, the validators have no BLS withdrawal key, the balance above 32 ETH is swept to the withdrawal address automatically, and the withdrawal address's key can request their exit. With 0x02, rewards compound in the validator's balance, a block that grows on top of it, up to 2,048 ETH, only the balance above that is swept, and the withdrawal address's key requests exits and partial withdrawals.
Note: A validator can exit by signing a voluntary exit message (VEM) (opens in a new tab) with the validator key. Since the Pectra upgrade, EIP-7002 (opens in a new tab) also lets the withdrawal address trigger a validator's exit, and partial withdrawals for 0x02 validators. This reduces trust assumptions by letting stakers who delegate ETH to staking-as-a-service providers remain in control of their funds.
Deriving keys from a seed phrase
If every 32 ETH staked required a new set of 2 completely independent keys, key management would quickly become unwieldy, especially for users running multiple validators. Instead, multiple validator keys can be derived from a single common secret and storing that single secret allows access to multiple validator keys.
Mnemonics (opens in a new tab) and paths are prominent features that users often encounter when they access (opens in a new tab) their wallets. The mnemonic is a sequence of words that act as an initial seed for a private key. When combined with additional data, the mnemonic generates a hash known as the 'master key'. This can be thought of as the root of a tree. Branches from this root can then be derived using a hierarchical path so that child nodes can exist as combinations of their parent node's hash and their index in the tree. Read about BIP-32 (opens in a new tab) and BIP-39 (opens in a new tab) standards for mnemonic-based key generation.
These paths have the following structure, which will be familiar to users who have interacted with hardware wallets:
m/44'/60'/0'/0
The slashes in this path separate components of the private key as follows:
master_key / purpose / coin_type / account / change / address_index
This logic enables users to attach as many validators as possible to a single mnemonic phrase because the tree root can be common, and differentiation can happen at the branches. The user can derive any number of keys from the mnemonic phrase.
[m / 0]
/
/
[m] - [m / 1]
\
\
[m / 2]
Each branch is separated by a / so m/2 means start with the master key and follow branch 2. Validator keys follow EIP-2334 (opens in a new tab): validator i gets its withdrawal key at m/12381/3600/i/0 and its signing key at m/12381/3600/i/0/0 (12381 identifies the BLS12-381 curve, 3600 the coin type for consensus-layer keys).
One plate carries a mnemonic at the back and 3 validators along the front, each with a flat slab on the plate in front of it for its withdrawal key. Step 1: the mnemonic becomes a seed, and the seed the master key m, a small block where the paths branch. Step 2: following the path m/12381/3600/i/0, where i is each validator's index, derives one withdrawal key per validator, along a path from m to each slab. Step 3: one level further down, m/12381/3600/i/0/0 derives each validator's signing key from its withdrawal key's branch: a short pipe joins each slab to the cube on its validator. Step 4: each public signing key goes into one validator's deposit data; another validator would take the next index, so the one mnemonic backs up every key.