Author profile
Jim McDonald15 Feb 2023

Understanding Withdrawals

Understanding the process and mechanism of moving rewards from the consensus chain to the execution chain.

Withdrawals are the missing piece of the validator lifecycle, under development since December 2020 when the Ethereum consensus chain1 first launched and now scheduled for the Shanghai upgrade. With Shanghai due to launch in the first half of this year, it is worth looking at withdrawals to understand what they are, how they work, and how to use this new feature of Ethereum.

History

When the consensus chain first launched in December 2020 there was no way to send information from the consensus chain to the execution chain. As such, although balances could accrue on the consensus chain, there was no way to realize these balances on the execution chain as withdrawals simply were not technically possible. Over time the architecture of Ethereum changed to accommodate new research, moving to the layer 2-centric model of scaling that exists today and leaving the execution chain largely unchanged. In September 2022 the execution chain was merged with the consensus chain, and execution blocks became a subset of the data in the consensus blocks. At this point it became possible for information to flow from the consensus to the execution chain, with one example being validator rewards.

Full details of the way in which the consensus and execution chains interact, and how merged blocks are built, can be found in the article "Understanding Post-merge Rewards". The key point is that it is only since the merge that it has been possible for withdrawals to take place.

What Have Validators Been Doing?

Since the genesis of the consensus chain in December 2020, validators have been generating and securing the chain. Specifically, they have been proposing new blocks, and attesting to blocks that they and other validators have proposed2. When carried out correctly, these activities have earned the validators rewards. The consensus chain started with just over 20,000 validators and, as of the time of writing, is now secured by approximately 520,000 active validators. From December 2020 to September 2022 the consensus chain secured nothing other than itself, however this paved the way for the merge3, and since September 2022 the execution chain has been secured by validators alone.

In return for their actions in securing the chain, these validators are granted rewards generated directly by the Ethereum protocol, which are recorded on the consensus chain.

What Happened to Validator Rewards?

As the consensus chain has no execution capabilities itself, Ether accrued on it cannot be transferred from one account to another. Indeed, the consensus chain does not even accommodate the concept of accounts, with the only entities on the chain with a balance being the validators themselves. This means that rewards have been accruing to validators steadily over the past two years with no means of withdrawing them.

Across all validators, the consensus chain has just over 1 million Ξ in accrued rewards. In terms of the individual validators, their reward depends on a number of factors but most obviously on the time they have been active as a validator. There are many validators that have accrued a significant amount of rewards:

The average validator has earned just under 2Ξ of rewards, with some as high as 5Ξ. However, although these rewards are registered on the consensus chain they cannot be instantiated on the execution chain until withdrawal functionality is in place.

Note that since the merge, in addition to the rewards shown above, validators that propose blocks will obtain a portion of the transaction fees. These fees are paid directly on the execution chain and, as such, are not discussed further in this article.

What Changes with Shanghai?

The Shanghai upgrade4 provides a mechanism to move rewards from the consensus chain to the execution chain. Each execution block will contain data about 16 withdrawals5 that move Ether to an execution chain account. Withdrawals have the following structure:

Figure 3Figure 3: A withdrawal

The individual components of a withdrawal are:

  • Withdrawal index a unique identifier for the withdrawal, allowing it to be referenced easily
  • Validator index the consensus chain index of the validator from which the withdrawal came
  • Address the address to which the withdrawal will accrue
  • Amount the amount of Ether to be added to the address, in Gwei6

As the block is imported to the execution chain, the withdrawals are processed and the balances of the relevant addresses are increased by the supplied amounts. Note that withdrawals are not transactions. They cost no gas, and they do not trigger the operation of any smart contract at the withdrawal address. Once the block has been processed the relevant balances will have increased, but no other actions will take place.

Where Does the Withdrawn Ether Come From?

The above information describes what a withdrawal is, but where does the Ether come from when a withdrawal is taking place?

Although a deposit of 32Ξ is made to the Ethereum deposit contract when a validator is created, this Ether cannot be accessed for the purpose of withdrawals as there is no mechanism in the contract to allow for any transfer. Use of these sums would also ultimately lead to a negative balance on the contract, as the sum of the validators' balances on the consensus chain exceeds the sum of the initial deposits.

Instead of moving funds from an existing account, withdrawals are paid for with funds created by the Ethereum protocol (known as new issuance). This ensures that withdrawals can always be paid, even though the total amount coming out of the consensus chain is higher than the total amount that went in to it.

The Withdrawal Clock

Internally, the consensus software holds a simple list of validator information:

IndexStateBalanceWithdrawal credentials
0Active36.4650x00f5…cf71
1Active36.8580x0092…df99
2Exited36.4730x00d6…ad6f
............
519053Pending32.0000x0100…d899

The individual components for each validator are :

  • Index a unique index for the validator, and also its position in the list
  • State the current state of the validator, such as "active" or "exiting"7
  • Balance the current balance of the validator, in Gwei
  • Withdrawal credentials the withdrawal credentials for the validator

Most of these items are self-explanatory, however the withdrawal credentials require some clarification. Every validator has a single set of withdrawal credentials. These control the flow of consensus funds, both the initial deposit and subsequent rewards. At current there are two broad types of withdrawal credentials:

  • those derived from a BLS public key, known as "type 0" withdrawal credentials
  • those derived from an execution address, known as "type 1" withdrawal credentials

These will be explored in more detail later, however, for now the important difference is that type 1 withdrawal credentials will allow withdrawal of consensus funds to the execution chain, whereas type 0 withdrawal credentials will not.

The consensus chain processes withdrawals in order, starting at index 0 and working up to the highest index in the set before starting again. One way of thinking about the withdrawal process is to compare it to an analogue clock with a single hand. Each mark on the clock face is a validator, starting with validator index 0 and going up to the highest index (currently around 520,000).

Figure 4Figure 4: The withdrawals clock

Once Shanghai is live, blocks will contain withdrawal information. To select which validators will be withdrawn, the clock hand ticks around the validators, and every time it points to an eligible validator some or all of that validator's balance is withdrawn according to the following rules:

  • if the validator has type 1 withdrawal credentials, is in the "active" state8 and has more than 32Ξ in its balance, then the excess above 32Ξ is withdrawn
  • if the validator has type 1 withdrawal credentials, is in the "withdrawable" state, and has any balance, then the full balance is withdrawn

If either of these rules apply, a withdrawal is generated and added to the block. If neither of these rules apply, then the validator is not considered eligible, and the hand ticks on. It carries on ticking until it has found 16 eligible validators9, at which point the withdrawals for the block are considered complete and added to the block.

The time taken for the clock hand to go through an entire sweep of the clock's face depends on the number of eligible validators.

At time of writing, there are approximately 520,000 active validators. With 16 withdrawals per block, and with 7,200 blocks per day10 the entire eligible validator set will be processed approximately every 4.5 days. As the size of the eligible validator set changes this number will also change, as shown above.

The Process to Change Withdrawal Credentials

As seen above, for a validator to be eligible for withdrawal it must have type 1 withdrawal credentials. At time of writing approximately 40% of the validators have type 1 credentials, with the remainder on type 0 credentials. The shanghai upgrade will also bring the ability to change type 0 to type 1 withdrawal credentials so that all validators can receive rewards. Changing withdrawal credentials requires the creation of a signed operation that is broadcast on the consensus chain. The structure of the operation is as follows:

Figure 6Figure 6: Change withdrawal credentials operation

The individual components of this operation are:

  • Validator index the index of the validator to which the operation applies
  • Withdrawal BLS public key the public key of the current BLS withdrawal credentials
  • Execution address the execution address to use for the new withdrawal credentials
  • Signature a signature by the private key of the current BLS withdrawal credentials over the other fields of the operation

The action of the operation on the beacon chain is as follows:

"For the validator defined by the given validator index, check that the given BLS public key can be turned in to type 0 withdrawal credentials that match those currently listed for the validator. If so, turn the given execution address in to type 1 withdrawal credentials and update the validator with them."

Thus, the credentials change operation can only take place once. Once a credentials change operation is processed the on-chain validator definition will contain type 1 withdrawal credentials, so there are no type 0 withdrawal credentials to match according to the rule above. As such, once set the type 1 credentials will remain with it for its lifetime11.

Selecting the Execution Address

The first step in the process to change withdrawal credentials is to select the Ethereum execution address that will be used for withdrawals. As outlined above, you can only make the change once so you must ensure you have control of the private keys for the address before setting it. If you have multiple validators then you need to consider if you want to have a different withdrawal address for each validator, or if you want to use the same address for some or all of your validators:

  • setting the same address increases your ease of use, as rewards will accrue more quickly to that address and so any transfers will use less gas as a proportion of the value of the Ether at the address
  • setting a different address potentially increases the security of your validators by keeping them unrelated, if the validators are already unrelated (different deposit addresses, different/no graffiti on block proposals, etc.)

Creating the Operation

Once the execution address is selected an operation needs to be created and signed for each validator. Because of the sensitivity of exposing private information related to the withdrawal credentials (either the private key or the seed phrase), it is recommended that creation occurs offline. Full details of how to do this is outside of the scope of this article, however there are detailed instructions available for carrying this out this with the ethdo tool, and other tools and guides are likely to become available over time.

Broadcasting the Operation

After creating the operations they need to be broadcast to the consensus network. If the operation is provided to the consensus node after the Shanghai upgrade, the operation will be broadcast to the network for inclusion at the next opportunity. If the operation is provided to the consensus node before the Shanghai upgrade, the operation will be stored and broadcast once the upgrade has taken place. Note that this requires a connection to a consensus node that understands the Shanghai upgrade; at time of writing these are expected to be made available some time in February, in good time for the mainnet upgrade.

Online/Offline Process

As mentioned above, creating credentials change operations should be carried out offline. This avoids the situation where the withdrawal private keys are exposed to a computer that could be infected with malware or otherwise susceptible to having the keys stolen. However, access to an online computer is required to obtain information from the beacon node, and ultimately to broadcast the credentials change operation(s). As such, a hybrid online/offline process to create and broadcast change operations is recommended.

Figure 7Figure 7: Creation and broadcast of change operations in an online/offline configuration

There are various tools that follow this process, such as ethdo, that will have their own documentation with specifics about how to carry out the process, but set out below is a general overview of each step, what it does, and why it is required:

1. Obtain Chain Information

Various information is required from the chain to create valid signed credential change operations, which should be obtained from the chain itself to ensure that the correct information is present. It is also useful to obtain a list of all current validators, as this allows for easier creation of the operations along with verification that the operations created are suitable for the validators.

The information comes from an active consensus node, hence the requirement for this data to be obtained from an online computer. Most entities that run validators would be expected to have access to a consensus node, however if they have delegated their staking to a service they should approach that service to obtain the required information.

This will result in a file that contains information about the chain. The file itself will not contain private keys or other sensitive information.

2. Transfer Chain Information

Once the chain information has been gathered it needs to be moved from the online to the offline computer. The common way of doing this is via USB storage, which allows the transfer to take place without requiring the two computers to be in direct contact with each other. This means that the offline computer can stay disconnected from the internet entirely, significantly increasing the security of the private keys or seed phrase.

3. Create Change Credentials Operations

With the chain information on the offline computer it can now generate the change credentials operations. This requires access to the seed phrase or private keys that created the current withdrawal credentials on the validators of interest, which is why it is safest to run this process on the offline computer.

It is possible that the private key or seed phrase previously created the credentials for multiple validators, in which case the creation process can create multiple change operations.

This will result in a file that contains the change credentials operations. The file itself will not contain private keys or other sensitive information.

4. Transfer Change Credentials Operations

Once the change credentials operations file has been created it needs to be moved from the offline to the online computer. Again, use of USB storage or similar is commonly the best solution.

5. Broadcast Change Credentials Operations

With the change credentials operations file on the online computer it is now possible to broadcast these operations to the Ethereum network by sending them to a consensus node, most obviously the one from which the chain information was originally obtained.

Once the operations have been submitted to the consensus node it will broadcast it around the network, and the change will take effect when the operations are included in to consensus blocks. There is space for 16 change credentials operations per block, so it could take up to 4 days for the operation to be included in a block. However, it is more likely that inclusion will occur within an hour or two12.

Summary

Withdrawals are coming with the Ethereum Shanghai upgrade, making consensus rewards available to users for the first time since the consensus chain was launched. Once configured, they will be automatic for any validator, and the upgrade also brings a mechanism to configure those validators not yet ready for withdrawal.

With the completion of the validator lifecycle the consensus chain fulfils its promise to stakers made in December 2020, and opens the door to stakers who were perhaps unsure of joining a system they could not leave. Additional validators will result in higher security for Ethereum, and a stronger chain.

  1. Ethereum has multiple chains, commonly known as the consensus (or beacon) chain and the execution chain. For more details, please see the article "Understanding Post-merge Rewards". ↩

  2. They also participate in sync committees, but these are just another form of attestation. ↩

  3. The colloquial term for the migration of Ethereum from using the proof of work consensus mechanism to using the proof of stake consensus mechanism. ↩

  4. Along with the Capella upgrade on the consensus chain. ↩

  5. Officially it is up to 16 withdrawals, but it is expected that all withdrawal slots will be occupied in all but the most extreme circumstances. ↩

  6. All values on the consensus chain are in Gwei, hence any transfer from the consensus chain to the execution chain will be a whole number of Gwei. ↩

  7. State is actually derived from other fields in the validator information so is not present in the validator definition, but is displayed here as it is referenced elsewhere in the article. ↩

  8. Definitions of the states "active" and "withdrawable" can be found in the article "Understanding the validator lifecycle". ↩

  9. The hand will also stop ticking after 16,384 validators even if it has not found 16 eligible validators, although this is not a situation that is likely to occur outside of test networks. ↩

  10. At time of writing this number is approximately 7,160 in reality, due to some blocks either not bring proposed or being orphaned after proposal. ↩

  11. This could change in the future with the introduction of new operations, however there are no plans for this to happen at time of writing. ↩

  12. There is expected to be an initial rush of validators changing their withdrawal credentials in the first couple of days following the upgrade, after which the majority of validators that can change will have changed and the queue will be minimal. ↩

  • Ethereum consensus layer
  • Ethereum execution layer
  • Financials