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.
Miscellaneous Items
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.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsementof any of the digital assets or companies mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned or may own investments in some of the digital assets and protocols discussed in this document. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email [email protected]. ©Copyright Galaxy Digital Holdings LP 2022. All rights reserved.