BY Jim McDonald ON Dec 12, 2019

Ethereum 2 uses proof of stake to secure its network, but to do so requires each active participant (known individually as a validator) to have funds to stake. Ethereum 1 accounts hold funds, and these funds needs to move to Ethereum 2 validators, where they can be staked.

The validator carries out the work of proposing blocks and attesting to others’ blocks (hereafter just called “attesting” for brevity), whereas the staker provides the funds to stake. They may be the same or different entities; best practice recommends that these roles are separated for highest security of funds.

The process of sending funds from Ethereum 1 to Ethereum 2, along with defining the staker and validator, is known as staking and the first step of staking is to send a staking deposit transaction on Ethereum 1. The staking deposit transaction contains the details of who is staking, who is validating, how much is being validated etc. and is cumulatively known as a deposit agreement. This article looks at staking deposits in detail, and explains the process of using Ether on Ethereum 1 to fund a validator on Ethereum 2.

Creating the deposit agreement

The deposit agreement defines the roles of the staker and validator, and forms the basis of the transaction sent to start the deposit process.

Figure 1: The deposit agreement and its participants

Validator identification

Validator identification is required to ensure the deposit is credited to the correct validator. The validator identifies themself by adding their public key to the agreement:

Figure 2: Validator identification

Note that the validation identification uses an Ethereum 2 public key rather than Ethereum 1 public key, as it is used in Ethereum 2 to identify the validator.

Amount staked

The amount staked needs to be included to ensure that both parties (and both networks) agree on the amount to be staked. The staker adds the amount they wish to stake to the agreement:

Figure 3: Amount staked

Withdrawal identification

Withdrawal identification is required to provide the account to which withdrawals from the validator are sent. The staker identifies the withdrawal account by adding a manipulated public key to the agreement:

the public key is hashed to reduce its size; and the first byte of the hash is replaced with a type identifier (currently just ‘0’).

Figure 4: Withdrawal identification

Note that the withdrawal identification uses an Ethereum 2 public key rather than Ethereum 1 public key, as it is used in Ethereum 2 when it comes time to withdraw the stake. As such, it must be supplied directly by the staker rather than recovered from the transaction signature as is commonly the case with Ethereum 1 smart contracts.

Also note that if the validator and staker are the same entity different keys should be used for validator identification and withdrawal identification. This allows the withdrawal key to be held safely offline until the staker is ready to withdraw their funds.

Validator authorization

Validator authorization is required to show that the validator agrees to validate within the terms of the agreement. The validator provides their authorization by signing the agreed terms with the same key as used to provide the validator identification, and adding that signature to the agreement:

Figure 5: Validator authorization

Submitting the deposit agreement

At this point the deposit agreement has four pieces of information in it: the validator identification, the amount to be staked, the withdrawal identification and the validator authorization. If the staker wishes to proceed with the deposit they send a transaction to the Ethereum 1 deposit contract containing the agreement and the funds:

Figure 6: Submission of deposit agreement

There are two important points that need to be made here:

there is no explicit authorization in the deposit agreement by the staker. Instead, the staker adds their signature to the transaction prior to broadcast, providing the required authorization; and the transaction must be accompanied by the exact amount of Ether stated in the deposit agreement; any other amount will cause the transaction to be rejected by the deposit contract.

The transaction is received and processed by the Ethereum deposit contract; if all is in order the deposit contract creates a deposit receipt event. This deposit receipt event contains all of the data in the deposit agreement, and acts as notification that the deposit contract has accepted the deposit agreement and received the appropriate funds.

Activating the deposit agreement

Activating the contract moves the focus from Ethereum 1 to Ethereum 2.

Ethereum 2 listens to updates on Ethereum 1 for deposit receipts. Each Ethereum 2 node includes the latest deposit receipts in its proposed blocks; as these blocks are finalized the deposit becomes part of the overall state of Ethereum 2. Deposit receipts are stored on Ethereum 2 as validator state.

The validator, in turn, listens to updates on Ethereum 2 for changes in validator state. When it sees an entry in the validator state with its public key it knows the deposit has occurred on Ethereum 1 and been recognized by Ethereum 2, and it is time to start its work of attesting.

Figure 7: Activation of deposit agreement

The full process

Putting the submission and activation pieces together provides the full process of staking Ethereum 1 network funds on Ethereum 2, with information from the validator and staker passing from Ethereum 1 to Ethereum 2 and allowing secure activation of the validator with the appropriate funds:

Figure 8: Staking deposit process

Nuances

Although they are not shown, this process involves a number of delays for added security. For example, there is a delay between Ethereum 2 finding a deposit receipt event and adding its information to the validator state, to ensure there is effectively no chance of an Ethereum 1 network chain reorganization that would invalidate the deposit.