Ethereum 21 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.
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:
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.
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:
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’).
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 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:
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:
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.
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:
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.
This post uses the term “Ethereum 1” to mean the Ethereum mainnet and “Ethereum 2” to mean the beacon chain.↩
Staking in Ethereum 2 is a complex task. Attestant is building an institutional-grade staking service that manages the entire business of staking for you. If you are interested in staying up-to-date with Attestant's services, please sign up to our mailing list.