# Article draft: Beacon Chain Withdrawal ###### tags: `blockchain-research` _Special thanks to Alex Stokes, Danny Ryan, and Vitalik Buterin for their invaluable assistance and insightful feedback during the review process._ [toc] ## What is beacon chain withdrawal With "[the merge](https://ethereum.org/en/upgrades/merge/)", the consensus of Ethereum is changed from [Proof-of-Work](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/) to [Proof-of-Stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/). PoS Ethereum requires you to stake 32 ETH to become a [validator](https://launchpad.ethereum.org/en/faq), which can be randomly assigned as a proposer (responsible for [producing blocks](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/validator.md#block-proposal)) or an attester (responsible for [submitting attestations](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/validator.md#attesting)), then validators will be [rewarded](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) according to their workload. And the architecture of Ethereum has also changed from a monolithic chain to a [modular blockchain with two layers](https://tim.mirror.xyz/sR23jU02we6zXRgsF_oTUkttL83S3vyn05vJWnnp-Lc): the consensus layer and the execution layer, which communicate through the engine API. ![](https://hackmd.io/_uploads/rJYHNZoln.png) ###### <Center>A modular blockchain with two layers</Center> Previously, the validator could only send funds to the beacon chain via a [deposit contract](https://etherscan.io/address/0x00000000219ab540356cbb839cbe05303d7705fa), and these funds would be locked in the consensus layer because there was no mechanism to withdraw the fund. So the goal of withdrawal is to unlock validators' funds, allow them to withdraw their funds (including 32 ETH + earned rewards) from CL to EL, and eventually enable validators' exit function. ![](https://hackmd.io/_uploads/ByPyYRfWh.png) ###### <Center> Withdraw staked ETH from CL to EL</Center> This article will delve into this modest yet indispensable feature and provide an expanded explanation of its design philosophy, workflow, and potential impact. Please enjoy! ## How does withdrawal work in more detail ### Design Philosophy The design goal is to enable the withdrawal function of the consensus layer under the strict premise of ensuring the security and stability of the Ethereum network, and eventually ensure that any validator can exit safely. Besides, we also want no backward-compatible breaks, minimize complexity and engineering workload, and allow many projects can reuse withdrawal's research and code, such as rollups and staking pools. With this goal in mind, there have three critical questions. - When to activate withdrawals? - How to signal? - Where does the withdrawn ETH come from? ### When to activate withdrawals? Withdrawals will always be active, but we will only remove stakes when the economic layer is secure enough. Also, we want to identify the spare stake (i.e., the balance in excess of 32 ETH) and remove it from the protocol. Based on this goal, we want to make withdrawals that can still incentives honest validators. Therefore, we have two different types of withdrawals, namely partial withdrawals and full withdrawals. - **Partial withdrawals**: The processing is automatic and immediate. Only the balance that exceeds 32 ETH (earned rewards) is withdrawn, so the validator will not exit the network and will still take on the corresponding responsibilities. This is to ensure that there are always enough validators in the network. - **Full withdrawals**: Must be done manually. Validator's entire balance (32 ETH + rewards) will be unlocked and withdrawn, and the validator will completely exit and no longer be a part of the beacon chain. However, the rate of full withdrawals is limited by the exit queue, causing it to be lower than partial withdrawals, this is designed to limit the rate of validator exit and to ensure the security of the network (i.e., a slower exit rate makes the [weak subjectivity](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) window larger, making it take longer to get a sufficient quorum for the [long-range attack](https://blog.positive.com/rewriting-history-a-brief-introduction-to-long-range-attacks-54e473acdba9)). All submitted full withdrawals must pass through the exit queue before they become withdrawable, then they can be sent to the EL and exit the network. The rate of exit queue depends on the number of [active validators](https://beaconcha.in/), which is proportional to each other, more specifically, until 327680 active validators, 4 validators can exit to be withdrawable per epoch. After that for every 65536 active validators, the validators' exit rate goes up by one (same as the [validator activation rate](https://kb.beaconcha.in/glossary#validator-lifecycle)). ![](https://hackmd.io/_uploads/By-_oKlW2.png) ###### <Center>The lifecycle of full withdrawals</Center> ![](https://hackmd.io/_uploads/HkA_zDmg3.png) ###### <Center>The rate of exit queue</Center> If we assume that no new validators join the network and there only have full withdrawals. At this rate, the current [556983 validators](https://beaconscan.com/validators#active) need at least 119399 epochs (i.e. **530 days**) to be withdrawable. ![](https://hackmd.io/_uploads/SkZsFwQln.png) ###### <Center>The time for all validators to go through the exit queue</Center> ### How to signal? Because of the modular design of Ethereum (i.e., CL and EL), we need to send the withdrawal information from the consensus layer to the execution layer. This introduces a new question, how to signal the execution layer? In general, there are two solutions. One is "pull"-based solution (i.e., [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788)), and the other is "push"-based solution (i.e., [EIP-4895](https://eips.ethereum.org/EIPS/eip-4895)). - **Pull-based**: Since the beacon chain uses [SSZ](https://ethereum.org/en/developers/docs/data-structures-and-encoding/ssz/) structure, it is easy to [convert the state root into a Merkle tree](https://eth2book.info/altair/part2/building_blocks/merkleization), where all the withdrawal is a sub-tree (i.e., withdrawal list), and we can easily construct a [Merkle proof](https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5) to prove that a certain validator withdrawal exists in the state root. After that, the state root and Merkle proof will be sent to EVM via [engine API](https://github.com/ethereum/execution-apis/tree/main/src/engine), and if it passes the execution layer verification (proof is valid and withdrawal has not been consumed), the balance of the withdrawal address will be increased. - **Push-based**: Push-based withdrawal takes a quite simple approach, it uses a [withdrawal queue](https://github.com/ethereum/consensus-specs/pull/3042) to replace the withdrawal list, which means that it is no longer needed to send the state root and proof to the execution layer. The CL only needs to dequeue and send withdrawals to the EL at a certain rate (via the [engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/shanghai.md#withdrawalv1), in the [payload](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#extended-containers)), and EL processes the payload as usual, taking out the [withdrawal object](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#withdrawal) and adding a certain amount of ETH to the address. These two solutions have different implementations. For the pull-based solution, we need to introduce a new "stateful" [precompiled contract](https://www.evm.codes/precompiled) that handles withdrawal-related operations (i.e., can access the beacon state, but does not store the state data), and a new opcode ([`BEACON_STATE_ROOT`](https://eips.ethereum.org/EIPS/eip-4788#new-opcode)) to read the state data from the "stateful" precompiled contract. For the push-based solution, it reduces some complexity by using a withdrawal queue. However, the EL still needs to be modified accordingly (e.g., [execution payload and header](https://eips.ethereum.org/EIPS/eip-4895#new-field-in-the-execution-payload-withdrawals)). And they also have different trade-offs. The pull-based solution is simpler for protocol development but adds additional complexity (i.e., new concept of "stateful precompiled contract", more testing, etc.) and bad UX. Users have to pay the gas for contract interactions and the withdrawals will take up the block space from other transactions. For the push-based solution, most of the work is defined in the protocol layer rather than on the user end, so it gets better UX. And since there are no precompiled contracts, naturally no additional gas cost and block space take-up. So after all the considerations, **we finally choose the "push"-based solution**. ### Where does the withdrawn ETH come from? After deciding how to send the withdrawal message to the EL, we also need to design how to credit withdrawn ETH (the Ether that the EL sends to the withdrawal address). In general, two options can be chosen. - **Withdrawal contract** (for pull-based withdrawals): As the mirror of the [deposit contract](https://etherscan.io/address/0x00000000219ab540356cBB839Cbe05303d7705Fa), a large amount of ETH is stored in the withdrawal contract and sent to the corresponding withdrawal address. The withdrawal transaction will look exactly the same as [a normal transaction](https://etherscan.io/tx/0x10878d4ffb6e54a0434799c93cc16cf1f228341dbfb3f7e25e63e7c9debe81cc). - **System-level operation**: Completely different from user-level transactions, defining a new type of "[operation](https://eips.ethereum.org/EIPS/eip-4895#system-level-operation-withdrawal)" at the system level. Similar to the coinbase and block reward, it will create new ETH. Withdrawal contract brings too much potential complexity and risks (i.e., if there is a bug in the contract then the entire protocol is borked). Also if large amounts of ETH are stored in the withdrawal contract (either by transferring from the deposit contract or by creating new ETH), it would look very unneutral. Meanwhile, the system-level operation is separated from user-level transactions, which is cleaner and simpler, and does not require EVM execution (meaning no failure and no gas cost). So **we finally chose the system-level operation**. ### How does it exactly work? After we have clarified the goal, the design philosophy, and the critical questions of withdrawal, we can now explain how beacon chain withdrawal actually works. In short, a withdrawal is finished in the following four steps. 1. Validator check and submit 2. CL Processing 3. Engine API 4. EL Processing We show the complete process of withdrawals by expanding these four steps one by one. **1. Validator check and submit** The most important thing for the validator is to **set an Ethereum address** so the funds can be withdrawn from the CL to the corresponding EL recipient address. Validators can check if they set the Ethereum address by a `withdrawal_credentials` field (see it [here](https://beaconcha.in/validator/383838#deposits)). If there is an EL withdrawal address, the field is prefixed with `0x01`, otherwise it defaults to `0x00` (as the example below). ![](https://hackmd.io/_uploads/Sk5dkCSgn.png) ###### <Center>Withdrawal credentials with 0x00 prefix</Center> For partial withdrawals, it will only be initiated after the validator migrates withdrawal credentials from `0x00` to `0x01`. Besides that, the validator does not need to do anything, and the reward over 32 ETH will automatically be sent to the withdrawal address. And for full withdrawals, the validator can exit the network and unassign the duty at any time. But again, the fund (32 ETH + earned reward) will only be sent to the withdrawal address after migration to `0x01`. So validators should first check that if they have migrated the withdrawal credentials prefix from `0x00` to `0x01`. If not, we have two ways to perform the migration. - Initial a deposit: If the validator sets the Ethereum address when sending the deposit, the withdrawal credentials prefix defaults to `0x01`. - Send a BLS message: The only way to migrate to `0x01` besides initiating a new deposit is to send a `BLSToExecutionChange` message to the network. See more details [here](https://notes.ethereum.org/@launchpad/withdrawals-guide#BLS-to-execution-with-ethdo). However, note that the migration from `0x00` to `0x01` is a one-time process, and the Ethereum address cannot be changed after it is set. Also, full withdrawals cannot be canceled once they are submitted. So please operate it carefully! **2. CL Processing** After the validator stage, we move to CL processing. Full withdrawals and partial withdrawals will have separate processing logic. - Full withdrawals first enter the exit queue and "exit" at a defined rate (currently 8 exit/epoch), then run [slashing logic](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#slashings). If validators are not slashed and have a "0x01" prefix, it only takes 256 epochs (~28 h) to become withdrawable. If they are slashed, they need another 36 days of punishment delay to become withdrawable (this is to prevent attackers from [escaping](https://notes.ethereum.org/@hww/lifecycle#431-Step-3a-Get-slashed) and [colluding](https://notes.ethereum.org/@vbuterin/serenity_design_rationale?type=view#Slashing-and-anti-correlation-penalties)). - Partial withdrawals (i.e., balances exceeding 32 ETH) become withdrawable automatically and immediately after validators have the "0x01" prefix, with no waiting time. The complete workflow is like this in the diagram below. ![](https://hackmd.io/_uploads/SJYy2KmWh.png) ###### <Center>Lifecycle of withdrawals</Center> **3. Engine API** After that, the client will run the corresponding functions at each slot to scan all withdrawable validators (i.e., look up to [16384](https://github.com/ethereum/consensus-specs/blob/dev/presets/mainnet/capella.yaml#L17) at once) but only put the first 16 withdrawals (full or partial) into the withdrawal queue. The withdrawal queue is a single channel that processes both partial withdrawals and full withdrawals. It will send the unified [withdrawal objects](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#withdrawal) (withdrawal and validator index, withdrawal amount, and receipt address) to the execution layer. In the end, the withdrawal queue will be added to the [execution payload](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#executionpayload) (i.e., Ethereum block) when blocks are constructed. ![](https://hackmd.io/_uploads/H177ZOOeh.png) ###### <Center>Sending withdrawals to EL</Center> **4. EL Processing** EL processes the execution payload as usual and takes the withdrawal information out (now it has a [`withdrawal` field](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md?plain=1#L160)), adding the corresponding amount to the withdrawal address. Since validators’ balance increase is a "system-level operation" (similar to block reward and coinbase), it will not be executed by EVM and will not be displayed as a normal transaction. ## Upgrade timeline Before enabling withdrawal to the mainnet, a lot of testing was done, including protocol layer testing (e.g., [Zhejiang testnet](https://notes.ethereum.org/@launchpad/zhejiang) and [Hive test sets](https://github.com/ethereum/hive/pull/676)) and application layer testing (e.g., [MEV-boost](https://github.com/flashbots/mev-boost/issues/451)). But the most important time points are Sepolia testnet, Goerli testnet, and mainnet. - Sepolia testnet: [UTC on February 28, 2023](https://blog.ethereum.org/2023/02/21/sepolia-shapella-announcement) - Goerli testnet: [UTC on March 14, 2023](https://blog.ethereum.org/2023/03/08/goerli-shapella-announcement) - Mainnet: [UTC on April 12, 2023](https://blog.ethereum.org/2023/03/28/shapella-mainnet-announcement) So we'll see the mainnet enable beacon chain withdrawal on April 12! ## The potential impact of withdrawals ### Is there going to have a large-scale exit? After two and a half years of growth, the total number of active validators has grown from around 20,000 in December 2020 to around 555,000 in 2023. ![](https://hackmd.io/_uploads/Skbh_kzbn.jpg) ###### <Center>The number of active validators</Center> And the total number of stakes has grown to 17.77 million ETH, which is 14.8% of the total supply (12 million in [the stake pools](https://dune.com/hildobby/eth2-staking)). ![](https://hackmd.io/_uploads/S1Jw2L7Z2.png) ###### <Center>Percentage of staking to supply</Center> ![](https://hackmd.io/_uploads/HkkhXdXW2.png) ###### <Center>Percentage of staking to supply</Center> Also, PoS Ethereum has issued about 0.356 million new ETH through the validator's reward (PoW Ethereum is about 5.94 million), decreasing the average annual issuance from 5.62% to 0.59% (reduced by 89.5% compared to PoW Ethereum's issuance). ![](https://hackmd.io/_uploads/BkCeR_XW3.png) ###### <Center>Issuance</Center> Most people are concerned about whether a large number of users will withdraw their ETH from the network to the market after enabling the withdrawals. We are worried that this will impact the network's stability and ETH's price. But in fact, users may feel safer after enabling withdrawals and prefer to keep their funds in the network. The data shows that there is no large-scale withdrawal event. Only 1179 validators have submitted [voluntary exits](https://lighthouse-book.sigmaprime.io/voluntary-exit.html) so far, and the exited ETH only represents 0.0323% of the total amount of the network, which will not have a significant impact. ![](https://hackmd.io/_uploads/S1nKZY7bh.png) ###### <Center>Voluntary exit count</Center> For staking pools, they already allow users to exchange staked ETH (such as [sETH](https://help.lido.fi/en/articles/5230610-what-is-steth) and [rETH](https://rocketpool.net/)) for real ETH at the rate of 1:1 before they officially activate the withdrawal feature. So users of staking pools will not make large-scale withdrawals either. Even if all validators choose to exit, it would take at least 500 days to be withdrawable (based on [the rate of gradual decrease of the exit queue](https://notes.ethereum.org/@launchpad/withdrawals-faq#Q-How-fast-will-I-be-able-to-make-a-partial-withdrawal-Or-when-will-I-get-access-to-the-excess-rewards-that-are-on-my-validator)). So we don't need to worry about a large-scale withdrawal event or network stability breakdown after activating the withdrawal function. ### What can we learn from withdrawals? Besides the consensus-related software upgrades (such as [flashbot MEV-boost](https://collective.flashbots.net/t/mev-boost-community-call-1-9-mar-2023/1367/2#capella-hardfork-readiness-1), [Lido upgrade](https://hackmd.io/@lido/SyaJQsZoj), [Rocket Pool upgrade](https://docs.rocketpool.net/guides/atlas/whats-new.html#lodestar-support), etc.), rollups can benefit from existing withdrawal research and codebase. For instance, to guarantee credible neutrality and prevent malicious activity, rollups must ensure [users can withdraw their funds from L2 to L1 at any time](https://ethresear.ch/t/mass-migration-to-prevent-user-lockin-in-rollup/7701). So when rollups design a forced withdrawal mechanism, they can reuse engine API and withdrawal queue. Users can easily push their money from the rollup sequencer to the Ethereum execution layer. Also, if Ethereum client-based rollups have a staking layer (users may need to deposit a certain amount of tokens to become a sequencer/prover), they can reuse the engine API and withdrawal queue to safely withdraw funds from the staking layer to the L2 sequencer too. ![](https://hackmd.io/_uploads/ryIpZq7-n.png) ###### <Center>Rollups can reuse the Engine API</Center> ## Conclusions This comprehensive article delves into the concept of withdrawal, its mechanics, and its broader implications. I hope that it assists the wider community in gaining a deeper understanding of the withdrawal function. In addition, I eagerly anticipate the Shapella upgrade. Following this update, the consensus R&D team will forge ahead with numerous developments, such as [EIP-4844](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#introduction), [in-protocol PBS](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance), [verkle tree](https://vitalik.ca/general/2021/06/18/verkle.html)/[statelessness](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal), [fork-choice rule enhancements](https://arxiv.org/abs/2302.11326), and the ultimate aim of achieving [single-slot finality](https://notes.ethereum.org/@vbuterin/single_slot_finality). A wealth of exciting developments lies ahead, and I look forward to sharing these stories with you in upcoming articles!
Last changed by  
 
Luozhu
1183

Read more

Account Abstraction: challenges and solutions

Motivation This document is about a discussion between the Ethereum team and AA wallet teams that were initiated by Vitalik. The AA team highlighted several issues they were currently facing. I have collected the topics and content of our discussions for internal review and learning (especially for zkEVM rollup-related parts). Critical Issues Multichain implementation The design goal of multichain AA wallet is to achieve address consistency and state (e.g. signing key, settings) consistency across multichain. 1. Address consistency across multichain

5/6/2023
Article draft: What it's like to be a homeless

Gratitude to Chee, Kim, Chen Wen Kang, Jason, Haichen, Andy, Mason, Aiko, Chris, Anthony, Cathy, Vitalik, and every incredible person encountered on this journey! Over the past year, I've embarked on a journey across various countries for work-related reasons and to satisfy my innate curiosity. While some might refer to this lifestyle as that of a "digital nomad" or "world citizen," I prefer a more understated term - "homeless." This inspired the title of today's article, in which I will discuss my experiences living without a fixed abode. My travels took me to three continents and six countries, each exciting and enlightening adventure. I shared some of these journeys with friends, while others I undertook alone, constantly forging connections with locals. These unique experiences gave me fresh perspectives and allowed me to witness people and places I would never have encountered. These extraordinary moments broadened my horizons and revealed our world's boundless diversity and possibilities. I am eager to share these experiences in this article, which also marks the beginning of my next great adventure. Starting from Vietnam ETH Vietnam

4/15/2023
Article draft: Current Ethereum

The background I was inspired to write this article by two people, CC and Vitalik. They agreed that the best way to learn Ethereum is to watch all core dev meetings and read the relevant meeting notes, hackmd docs, issues & PRs, and EIPs until you are clear on Ethereum's current roadmap, what are the concerns and worries of core devs, what is the role of each upgrade/EIP, etc. Besides that, I was inspired by the community. Ethereum has an excellent open source culture, you can see all the meeting videos on EF YouTube, and the agenda for future discussions in ethereum/pm (more, Tim and Kim's notes). The ethereum developers are doing their best to make the community understand the current upgrades and improvements to ethereum. So I think writing articles like this is valuable to the community!

4/13/2023
Outline: Ethereum's Consensus Protocol

What is Consensus Background The Byzantine Generals ProblemBackgroundBasic idea: abstract The background of consensus knowledge In a 1982 paper, Leslie Lamport What is it The army are divided into several generals Generals communicate only through messenger

4/11/2023
Read more from Luozhu
Published on HackMD