Ethereum Consensus Layer Call #97 Writeup
Ethereum core developers gathered for their 97th Consensus Layer (CL) meeting on November 3, 2022. This week, the meeting was chaired by the Ethereum Foundation’s Tim Beiko. Developers discuss three main topics; staked ETH withdrawals, Engine API code changes, and solutions to the Goerli testnet’s supply issues. The CL calls are one of two bi-weekly meetings series where Ethereum developers discuss and coordinate upgrades to the protocol of Ethereum. Last week, developers concluded their 148th All Core Developers meeting. For a refresher on what was discussed during last Thursday’s call, click here.
Staked ETH Withdrawals
Developers agreed during ACD call #148 to activate staked ETH withdrawals in the next upgrade known as Shanghai. During this week’s call, developers debated the merits of combining partial and full withdrawals into separate or combined queues. As explained by Prysm developer Terence Tsao, the benefits of separating the processing loops between full and partial withdrawals is for easy testing and preventing unnecessary delays to full withdrawals because of partial withdrawals. The benefits of combining these queues on the other hand is a slightly simper implementation and cleaner Beacon Chain state management at the expense of poorer testing capabilities and potential delays to full withdrawals.
As background, full withdrawals refer to a validator node operator withdrawing their full balance of staked ether. Partial withdrawals refer to a validator node operator withdrawing any amount of ETH that is in excess to their effective balance. The effective balance, which is the balance staked by validators to attest to the blockchain, is usually 32 ETH. However, the effective balance can decline to below 32 ETH due to penalties and slashings. The Beacon Chain protocol, which is now defines the consensus mechanism of Ethereum, limits the number of validators than can be activated and exited within a given epoch. This is known as the “churn limit” and fluctuates in accordance with the number of active validators.
When discussing the merits of separating full versus partial withdrawals, developers discussed removing the need for a queue to process withdrawals all together. This does not refer to a removal of the churn limit but rather the removal of a logic to order full and partial withdrawals within a block. Originally proposed by a Prysm developer who goes by the pseudonym of “Potuz,” the proposal labelled on GitHub as pull request #3068 suggests working through withdrawals by the validator index. Every validator on Ethereum is associated with a number, which is assigned according to when the validator was activated on the Beacon Chain. Instead of a queue, the Beacon Chain would scan through all active validators in ascending order from their assigned index number and process the withdrawals requested by each until the maximum number of withdrawals is reached within a block.
Potuz’s solution would add a single field to the Beacon Chain state called “last_withdrawal_validator_index,” which would keep track of the last validator that has performed a withdrawal within a block so that the next block can pick up where the former block left off and run through remaining withdrawals if any that hadn’t been processed. This would allow for other constants in the Beacon Chain state such as “max_withdrawals_per_peoch” and “withdrawal_queue_limit” to be retired as Beacon Chain software clients, also called CL clients, would no longer need to keep record of a queue of validators for processing withdrawals. Many developers on the call were in favor of Potuz’s solution.
Potuz did mention on the call that his solution may create a “nasty case” where the CL clients run through the entire index of 450,000 active validators without picking up a single withdrawal request, but mentioned that even in this edge case, the burden of doing a full scan in a single block remains trivial for clients. Even so, developers agreed to scope out the potential for adding a range bound for the withdrawal scan so that only up to say 100,000 validator index are inspected for withdrawals per block. A developer for the Lodestar (CL) client who goes by the pseudonym “Dapplion” mentioned on the call that it may be useful to still add the separation of partial from full withdrawals to Potuz’s proposal.
Dapplion argued that Potuz’s proposal could be extended by creating a scan for full withdrawals and creating a separate scan for partial withdrawals which would have the added benefits of preventing delays to full withdrawals in the event of a large volume of partial withdrawals filling up blocks. Ethereum Foundation researcher Alex Stokes pushed back on Dapplion’s suggestion saying that it was adding unnecessary complexity to the Beacon Chain state. Independent developer Micah Zoltu suggested that the separation of partial from full withdrawals could be added for a later upgrade after Shanghai if necessary.
Developers wrapped up their conversation around enabling staked ETH withdrawals in Shanghai with a final call for comments on Stokes pull request for adding withdrawal operations to Ethereum’s Engine API. The Engine API is a core piece of software designed for facilitating communication between the EL and CL client of an Ethereum full node. Developers were all in agreement to merge Stokes’ PR and continue to scope out Potuz’s PR for removing withdrawal queues. For an overview on the progress of staked ETH withdrawals, click here. For a more detailed explanation of the design specification for enabling staked ETH withdrawals on Ethereum, click here.
Adding Block Value in Response to Engine API’s Get Payload Request
On Thursday, October 27, Tim Beiko made a call for client teams to review a change to Ethereum’s Engine API which would enable validators to easily compare the value of a locally built block with the value of a block built by a third-party block builder. As explained by Terence Tsao during this week’s CL meeting, the change would be helpful for supporting Ethereum’s censorship resistance. According to Tsao, a mechanism could be built atop this feature to compare the bids between a block from a censoring relay to a locally built block and automatically choose the locally built block if it is more valuable, that contains higher block rewards. While the likelihood of a block from a third-party build to be of lower value than a locally built block is low, the addition of block value to a get payload request would at the very least help provide greater transparency around the selection process and open the design field for creating other defensive mechanisms.
During this week’s call, developers discussed how to best calculate the value of a locally built block. Alex Stokes was in favor of calculating the difference between the validator’s balance before and after a block. Chris Hager, a developer from Flashbots, was in favor of calculating the fee balance of a locally built block. Hager also mentioned that the conversation around how to calculate block value in a get payload request overlaps with the discussion around block scoring by MEV-Boost relays. Geth developer Marius van der Wijden mentioned that the value of a block could be skewed slightly if it is calculated as the difference in a validator’s balance if the validator is including his or her own transactions within the same block. Because of this potential to skew block value, Micah Zoltu raised the concern that the comparison of a locally built block with that of a block built by a third-party builder may end up becoming an apples to oranges comparison.
There is a prototype of calculating the value of locally built blocks created by the Geth (EL) and Prysm (CL) client teams. Developers agreed to push forward with the addition of block value to the get payload request in the Engine API as soon as possible and resolve disagreements about the calculation methodology on GitHub.
On the topic of MEV, Chris Hager from the Flashbots team gave a quick update about the status of MEV-Boost software during the call. Notably, a new release of MEV-Boost will enable the ability for validators to set a minimum bid value for accepting blocks from a relay. In addition, Hager mentioned that research is ongoing for the addition of transaction inclusion lists both outside and inside of MEV-Boost to support Ethereum’s censorship resistance. Finally, in the last couple weeks, a new permissionless MEV-Relay has been launched called “relayooor.wtf.” Though the Flashbots MEV-Relay commands more than 80% of MEV-Boost block production, there is now an equal number of censoring and non-censoring relays live on Ethereum. To read Hager’s full MEV-Boost update, click here.
Addressing Goerli’s Supply Issue
On Tuesday, November 1, Afri Schoeden, one of the developers maintaining the Ethereum test network Goerli, hosted a community call to address the issues around Goerli testnet ETH supply. The issue as explained by Shoeden in this EthMagicians post is a lack of testnet ETH supply for decentralized application (dapp) developers wanting to test their code and for stakers wanting to test their validator setups on Goerli. The lack of supply has created a marketplace where users are reportedly buying testnet ETH. The issue is exasperated by the fact that Goerli is one of the only permissionless testnets at present that is not deprecated on which users can test out their validator setups.
In response to the Goerli testnet ETH supply crisis, Schoeden offered several solutions. One of the solutions discussed on the CL call this week was the creation of a new constant to CL client specification called the “withdrawal_boost_factor.” The constant would always have a value of 1 for Ethereum mainnet but the value could be tweaked and increased for testnets to artificially inflate supply through validator withdrawals. Paul Hauner from the Lighthouse (CL) team raised concerns about users on Goerli potentially taking advantage of this feature and creating an unstable validator set on Goerli. Other developers were in favor of leaving Goerli untouched and incentivizing the use of alternative testnets such as Sepolia.
Beiko mentioned that even if developers are on board with shutting down the Goerli testnet, the deprecation of Goerli should happen gradually to give stakers and dapp developers on Goerli time to migrate to a different network. Ultimately, developers did not come to a consensus about how to address the supply issue on Goerli. Beiko encouraged more discussion in the #testnets channel on the Ethereum Research and Development Discord channel. Following the call, Schoeden closed his Github pull request for adding a withdrawal boost factor to CL client specification. He wrote, “Focus should be now to prepare application teams for sepolia and holesovice.” Holesovice refers to the idea of a new ephemeral testnet for stakers and dapp developers to use in lieu of Goerli.
Jacek Sieka, research lead at Ethereum crypto wallet company Status, proposed a simplification of CL client specifications. His PR on GitHub suggests replacing certain fields for historical block data to improve the syncing speed of Ethereum archival nodes. Paul Hauner from the Lighthouse (CL) client team expressed his support for Sieka’s PR and Tim Beiko encouraged other client teams to review the PR in the coming weeks.