Ethereum All Core Developers Consensus Call #112 Writeup
On June 29, 2023, Ethereum core developers gathered over Zoom for their 112th 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, developers discussed the inclusion of a builder override flag in the Engine API, an increase to the target and maximum blob limit to 3/6 from 2/4 under EIP 4844, and ongoing research around changing the maximum effective balance of validators.
Deneb-Related Discussions
To start the call, Teku (CL) developer Mikhail Kalinin raised two changes to the Engine API for consideration in the Deneb upgrade. As background, the Engine API is an internal API used for facilitating communication between the CL and EL software clients within an Ethereum node.
As raised on ACDE #164, Kalinin has proposed a deprecation schedule for the “engine_exchangeTransitionConfiguration” method, which was a method used for transitioning Ethereum nodes through the Merge upgrade. All EL clients have already ceased to log error messages for this method and to remove it completely from EL clients, Kalinin asked CL client teams to either stop calling this method or remove it entirely from their code base. Doing so by the Cancun/Deneb upgrade would ensure a smooth deprecation schedule and a clear deadline after which EL client teams can then start to remove the method safely from their codebases. There was no opposition to Kalinin’s proposal. Kalinin agreed to check-in with the progress of CL client teams on this matter when developers start coordinating the launch of public Deneb test networks.
The second change to the Engine API proposed by Kalinin for inclusion in Deneb is the builder override flag. It is a new Boolean field that the EL can use to indicate to the CL node that it should consider falling back on local block production instead of relying on a third-party builder. According to Prysm (CL) developer Terence Tsao, this field is meant to give validators “more control” over block production and in the event of censoring activity by third-party block builders, give validators an easy way to pick up and react to this activity. The field was originally proposed for inclusion in the Shanghai upgrade. However, developers agreed to continue prototyping the flag and allow CL client teams to implement it asynchronously without a hard fork. On ACDC #112, Kalinin proposed using the upcoming Deneb hard fork as a rallying point for requiring all CL client teams to implement this field. Danny Ryan was supportive of the idea. Ryan asked whether the idea to make the builder override flag a breaking change in the Engine API for Deneb had been raised with EL client teams. Kalinin agreed to circulate the proposal and get the conversation going with the relevant EL developers.
After discussions around the Engine API, developers discussed testing efforts around EIP 4844, proto-danksharding, which is the main code change being implemented in the next Ethereum hard fork. For more information about proto-danksharding, read this Galaxy Research report. Parithosh Jayanthi from the DevOps team at the Ethereum Foundation said that all EL and CL client teams were passing the relevant Hive tests for Devnet #7. Therefore, Jayanthi said that his team plans on launching Devnet #7 as early as Friday, June 30 or Monday, July 3. As background, Devnet #7 is a dedicated short-lived test network for EIP 4844. It will not test other code changes, that is EIPs, that have been approved for the Cancun/Deneb upgrade. Additionally, Devnet #7 is launching with a target blob limit of 3 instead of 2, and a maximum blob limit of 6 instead of 4. The increase in blob capacity was proposed by Ethereum Foundation Research Dankrad Feist after he conducted a data experiment testing network capacity for processing large blocks.
Developers remain on the fence about the change to the target and maximum blob limit. On ACDC #112, developers agreed to see how Devnet #7 handles the additional data load. They also agreed to further investigate changes to the attestation propagation deadlines for validators as the size of validator messages sent through the network becomes larger and heavier. Ryan suggested that developers on the call be ready for more discussion on these matters for the next EIP 4844 Coordination Call, scheduled for Monday, July 10.
Holesky Testnet Update
Developers are preparing to deprecate the public Goerli test network by the end of this year. To replace Goerli, Ethereum client teams are working on spinning up a new testnet known as Holesky that will host an active validator set size larger than Goerli and Ethereum mainnet. During Holesky Coordination Call #1, representatives from Ethereum client teams committed to collectively spinning up roughly 800,000 validators. Other Ethereum stakeholders likely blockchain infrastructure companies and teams will be standing up roughly 900,000 validators. In total, Parithosh Jayanthi said that he has received enough commitments for the validator set size on Holesky to be 1.7mn. Each participating institution will receive roughly 100mn Holesky testnet ETH at network genesis. The goal is to complete testing to ensure that CL client software can handle the large active validator set size by the end of July and launch Holesky in September.
As an aside, Danny Ryan mentioned that a new CL specifications release has been put out including all the relevant EIPs going into the Deneb upgrade. Though Devnet #7 only tests EIP 4844, Ryan said he was hopeful that the next dedicated, short-lived testnet would test the full features of the Cancun/Deneb upgrade. For the Cancun/Deneb upgrade, Nimbus (CL) developer “Arnetheduck” asked when subscribing to revamped attestation subnets would become enforced among CL nodes. The revamp to attestation subnets was rolled out in a backwards-compatible manner on May 4. Danny Ryan said that developers should reconvene on this topic and decide whether to make the deadline for CL clients the upcoming Cancun/Deneb hard fork, or the upgrade thereafter.
Research Discussion
Developers revisited a proposal from Ethereum Foundation Research Michael Neuder to increase the effective balance of Ethereum validators such that yields from staking would auto-compound. One of the main benefits for increasing the maximum effective balance is to slow the growth of the active validator set and prevent unnecessary messaging bloat on Ethereum’s peer-to-peer layer. Neuder summarized the ongoing discussion points around his proposal.
Making EL triggered partial withdrawals a prerequisite for increasing the maximum effective balances of validators: This would ensure that independent validators that want to withdraw some portions of their accrued ETH rewards do not have to fully exit their validator and opt out of auto-compounding their rewards.
Bundling this proposal with EIP 7002 which has already been proposed by Danny Ryan to enable EL triggered validator exits: This would be to create synergies and parallel workflows with other ongoing EIP initiatives.
Changing slashing penalties for validators chosen to propose blocks based on their balance of 32 ETH, not their increasing effective balance: The change would be to help de-risk validator consolidation, especially for large staking institutions, after the increase to validator effective balances is implemented.
Removing the partial withdrawals sweep all together: There is an automatic and recurring sweep of validator reward balances. Removing this sweep and making auto-compounding the default behavior for accrued staking rewards may make the implementation of this proposal much simpler.
Changing the minimum balance before validator ejection: Validators are automatically ejected from the network if their effective balance drops to 16 ETH. Given that an increasing effective balance beyond 32 ETH might mean that some validators have an extremely long runway before being automatically ejected from the network, there is discussion around changing the minimum ejection balance to a more dynamic number based on a validator’s highest effective balance. The change is meant to address the issue of validator node operators losing their validator keys and being forced to wait for the inactivity penalty leak to automatically eject their validator from the network.
A Prysm (CL) developer by the name of “Potuz” discouraged bundling the proposal to increase the effective balance with EIP 7002, saying the latter code change was much simpler and combining it with a comparatively more complex EIP could delay the implementation of EIP 7002. Potuz also recommended considering implementation of Neuder’s proposal in stages, that is multiple hard forks. Ryan emphasized that Neuder’s proposal and EIP 7002 is not up for consideration in the Deneb upgrade, but potentially a hard fork thereafter. To that end, Danny Ryan encouraged CL client teams to start thinking about what potential code changes to include in the upgrade after Deneb. “For the theoretical fork after Deneb that will be [named] a star name starting with ‘E’, we will start a tracking issue [on GitHub] and people can toss potential stuff into it. We’re a bit early but the beginning of that conversation start today,” said Ryan.
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.