Ethereum All Core Developers Consensus Call #111 Writeup
On June 15, 2023, Ethereum core developers gathered over Zoom for their 111th All Core Developers Consensus (ACDC) call. Chaired by Ethereum Foundation Researcher Danny Ryan, the ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum. This week, Ethereum Foundation Researcher Alex Stokes chaired the meeting in place of Danny Ryan. CL client teams discussed the final scope of the Deneb upgrade, potential changes to validator attestation and aggregation deadlines, as well as a proposal to increase the maximum effective validator balance from 32 ETH to 2,048 ETH.
Deneb Scope Planning
Last week, client teams finalized the scope of Cancun, which is the name of the next EL upgrade on Ethereum. The scope of Cancun includes EIPs that impact both the EL and CL, such as EIP 4844 (proto-danksharding) and EIP 4788 (beacon block root in the EVM). On ACDC #111, developers discussed what CL-focused EIPs to include in Deneb. Deneb is the name of the CL upgrade that will occur simultaneously with the Cancun upgrade.
First, Teku (CL) developer Mikhail Kalinin gave updates around EIP 6988, which proposes a code change to prevent slashed validators that are being forcefully ejected from the network to be selected by the protocol as a block proposer. As discussed on ACDC #110, the EIP presents some challenges to the existing logic for shuffling the active validator set post-slashing event. Kalinin explained that he created an updated proposal for the EIP that fixes the in-state shuffling complexity, which can be examined here. Alex Stokes said that he was wary about including a complex code change like EIP 6988 so late into the preparation process for Deneb and suggested the conversation be tabled for a future date. “I think we should stay focused on essentially what’s going to go into the final TM Deneb release and it sounds like there’s a few design questions and we have some more research we want to do around this particular feature which suggests to me that we table it for now,” said Stokes.
Before moving on to the other EIPs being considered for Deneb, Mikhail Kalinin brought up a change to the Engine API that would break unnecessary dependencies between the EL and CL when processing blob transactions. Kalinin said the next step is for EL client teams to start removing certain error messages in preparation for Cancun. Developers agreed to raise this issue again on next week’s ACDE call. Kalinin’s Engine API change is specified in more detail here.
Outside of EIP 6988, developers discussed the following three EIPs for inclusion in Deneb:
EIP 7044: A code change to improve the staking user experience. The EIP would ensure that signed validator exits are valid in perpetuity. The EIP proposed by Lodestar (CL) developer “Dapplion” has already been merged into Deneb specifications.
EIP 7045: A code change to enhance chain security. The EIP would expand the attestation slot inclusion range from a rolling window of one epoch to two epochs. The EIP proposed by Ethereum Foundation researcher Danny Ryan is undergoing more discussion and a final review.
EIP 4788: A code change to improve the staking user experience. The EIP would expose roots of Beacon Chain blocks containing information about chain state inside of the Ethereum Virtual Machine (EVM) for trust-minimized access by decentralized application (dapp) developers. The EIP proposed by Ethereum Foundation researcher Alex Stokes was greenlit for inclusion in Cancun and Deneb during ACDE #163.
Stokes said the plan was to merge the above three EIPs into Deneb specifications over the coming weeks and encouraged CL client teams to review them as soon as possible.
Validator Attestation and Aggregation Deadlines
As discussed on ACDC#110 and ACDE #163, developers are considering increasing the maximum blob count per block from 4 to 6 as per the recommendation of Ethereum Foundation researcher Dankrad Feist. Client teams have agreed to test out the increased blob count on the next EIP 4844 test network, Devnet 6, and make a final decision on the matter in two weeks’ time. On ACDC #111, Feist said that he conducted more tests on Ethereum mainnet by sending blocks with an additional data load of 768 kB. (As background, one blob would theoretically contain up to 128kB of data.) Feist did not record any irregularities or issues with validators processing large blocks on Ethereum.
Related to this discussion around the maximum blob count, Nimbus (CL) developer “arnetheduck” raised the issue of increasing block reorganizations on mainnet post-Shanghai upgrade. “What’s been happening over the past six months is that we’ve gone from practically no reorgs at all to a few per hour. There’s no great answer as to why this is happening, just a couple of theories. It looks like it’s growing with the number of validators. It definitely become worse after the complexity of [Shanghai] Capella,” said arnetheduck. Based on these observations, arnetheduck proposed considering changes to the four second deadline for aggregating validator attestations and sending them through the network. Michael Neuder, Researcher for the Ethereum Foundation, was in favor of this idea, saying that a change could also improve MEV relay stability.
Developers debated the merits of simply increasing the four second deadline to 5 or 6 versus other more pointed changes to improving the computational load on validators from aggregating an increasing number of attestations. Ultimately, arnetheduck and other client teams agreed that more investigation would be needed to further the conversation and to create a concrete proposal around a change to the attestation deadline.
Validator Maximum Effective Balance
The effective balance of Ethereum validators is capped at 32 ETH, meaning that validators are not earning interest on any staked balance accrued beyond 32 ETH. To increase validator yield, stakers must redeploy capital of at least 32 ETH and run additional validators. Ethereum Foundation Researcher Michael Neuder has drawn up a proposal to remove the 32 ETH cap on effective balances to help reduce the growth of the active validator set. The benefits of slowing the growth of the number of validators include:
Easier implementation of future roadmap upgrades such as single slot finality.
Reducing unnecessary bloat on the peer-to-peer layer from high volumes of messages.
Improve the appeal of solo staking by empowering independent validators to auto compound staking earnings.
Reduce infrastructure complexity of large staking service provider by removing the need to constantly spin-up new validators to compound returns.
The biggest question, according to Neuder, around the implementation of the proposal is how to make the right tradeoffs between user experience and increasing specification complexity. The simplest way to implement a change in the effective balance of validators is to require individuals and entities to redeploy their stake through a new process and thereby take advantage of auto-compounding returns. However, this would require a large quantity of staking service providers to fully withdraw their staked ETH and redeploy capital. A more complex way to implement Neuder’s proposal would be to automatically update the behavior of existing validator balances.
Developers debated the potential pitfalls of this change and the possibility of combining the proposal with the proposal to enable initiations of partial and full withdrawals directly from the EL, initiated by smart contracts. Developers agreed to continue discuss the implementation details of a change to the effective balances of Ethereum validators asynchronously on ETHMagicians and Discord.
Holesky Testnet Coordination Call
Before ACDC #111, Ethereum core developers met for their first coordination call on the launch of the Holesky test network. As background, Holesky is envisioned to replace the existing Goerli testnet by the end of the year. It is also envisioned to be double the size in terms of active validators than Ethereum mainnet. Parithosh Jayanthi, DevOps Engineer at Ethereum Foundation, said that his team was looking to get confirmations from client teams, Layer-2 protocols, and other Ethereum stakeholders on their commitment to put up infrastructure and run validators for the genesis of Holesky. The plan is to gather these commitments by the next Holesky Coordination Call on June 29. Developers are aiming to prepare a final configuration release for Holesky in August and launch the testnet by September 15. Full summary of Holesky Coordination Call #0 can be found here.
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 2023. All rights reserved.