Ethereum All Core Developers Consensus Call #113 Writeup
On July 13, 2023, Ethereum core developers gathered over Zoom for their 113th All Core Developers Consensus (ACDC) call. Normally 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, the call was chaired by Ethereum Foundation researcher Alex Stokes. Developers discussed a potential decrease to the validator churn limit, that is the rate of validator entries and exits on the Beacon Chain, to slow the growth of the validator set size and do so in time for the Deneb/Cancun (Dencun) upgrade.
Deneb Testing Updates
Parithosh Jayanthi, DevOps engineer at the Ethereum Foundation, shared updates on Dencun testing efforts. Devnet #7, a dedicated test network for EIP 4844, has been active for two weeks. By now, almost every EL and CL client combination has been tested, excluding the Erigon (EL) client. Jayanthi encouraged client teams to look at the Dencun issue tracker to identify outstanding bugs and fixes that need to be made to their software releases. Additionally, the blockchain explorer for Devnet #7 tracking blob data has been updated so Ethereum projects and stakeholders interested in testing out features related to blob transactions or learning more about how blobs are processed are encouraged to check out the site.
In regard to Devnet #8, which will include testing for the full Dencun EIP feature suite, not only EIP 4844, Jayanthi said that client teams should ensure that their releases are passing relevant Hive tests. The full specifications for Devnet #8 are outlined here. Once client releases pass Hive tests, developers will launch a local test network first before launching Devnet #8. In parallel to Dencun testing, developers are continuing to explore different optimizations to Ethereum’s peer-to-peer layer with the introduction of blob transactions. Stokes stressed that these optimizations are not a blocker for the Dencun upgrade but would be helpful to ensuring node performance remains healthy on the network post-EIP 4844. A few specification changes that have already been included in Dencun around networking include PR #3346 and #3338.
E-Star Upgrade Naming
Two discussion threads have been created on Ethereum Magicians to discuss the Ethereum upgrade after Dencun. According to the naming convention for EL upgrades, which goes by the names of major cities around the world, the next EL upgrade after Cancun will be dubbed Prague. The CL naming convention goes by the names of stars. Given that the CL upgrade after Deneb will be the Beacon Chain’s 5th hard fork upgrade, developers are brainstorming different star names that start with the letter “E”. A few star names that have already been proposed on the Ethereum Magicians discussion forum include: Ebla, Edasich, Electra, Elgafar, Elkurud, and Elnath. The most popular so far among developers appears to be Electra. Stokes encouraged participants on this week’s developer call to chime in with their opinion on CL upgrade naming in the discussion forum.
Additionally, there is a separate GitHub issue for tracking the EIPs that will be considered for inclusion in the CL upgrade after Deneb. So far, the EIPs that have been proposed include:
EIP 6110: Appends validator deposits to EL block structure and shifts responsibility of deposit inclusion to the EL.
EIP 7251: Increase the maximum effective balance of validators.
EIP 7002: Create a new precompile to trigger validator exits from the EL.
Verkle trees: Replace use of Merkle Patricia Trees with Verkle trees, which are more efficient to prove.
Big EOF: A bundle of upgrades to the Ethereum Virtual Machine (EVM).
RLP to SSZ: Update Ethereum EL block serialization formatting to reflect the same scheme as the one used by the CL.
BLS signatures: Create a new precompile for BLS signature and SNARK verification.
Over the next few months, developers will start to discuss the above proposed EIPs along with any others that are proposed on the GitHub issue and prioritize a subset for inclusion in the next Ethereum upgrade after Dencun.
Web3Signer Standardization Efforts
Web3Signer is an open-source developer tool built by Consensys for signing transactions across multiple protocols including Ethereum EL, the Beacon Chain, or Filecoin remotely using private keys stored on a separate encrypted device. As appetite for remote signing capabilities grows among Ethereum users and validators, the Web3Signer team is looking to standardize their tools and migrate their code to a new repository under the official Ethereum Github repository. Matt Nelson, a developer for the Besu (EL) client, which is maintained by Consensys, encouraged client teams on the call to provide feedback and comment for the standardization effort so that it will be easier for all clients to integrate remote signing into their releases.
Addressing Validator Set Size Growth in the Short-Term
Lastly, a pseudonymous developer for the Lodestar (CL) client team by the name of “Dapplion” shared a proposal to limit the growth rate of the validator set. A large validator set size is undesirable for Ethereum given the strains that this puts on the peer-to-peer networking layer and the complications this creates for implementing other future code changes such as single slot finality. Dapplion’s proposal is to cap the churn limit at 12 validator entries and exits per epoch. At present, the churn limit increases exponentially as the active validator set size grows. By setting an upper limit on validator churn, developers can effectively reduce the growth rate of the validator set.
Dapplion said that his proposal is a short-term solution meant to buy developers more time to flesh out other ideas for addressing validator set growth over the long-term. One of these longer-term proposals that have already been discussed on ACD calls is Michael Neuder’s proposal to increase the maximum effective balance of validators. Based on Dapplion’s calculations, if the validator entry queue is perpetually at capacity for the next 9 months, the active validator set size will growth to 2mn. As of July 13, 2023, the number of active validators on Ethereum is 663,635.
In response to Dapplion’s proposal, Chair of the ACDC calls Danny Ryan wrote in a comment that setting a limit to the churn rate was “a sensible band aid” to the problem. However, the proposal would exacerbate the time preference on staked ETH capital to stakers that have already passed through the activation queue. The proposal may also trigger second order effects on staking markets such as the value of liquid staking tokens on Ethereum. On the call, Dapplion stressed that his proposal is time sensitive and would need to be implemented in time for the Deneb upgrade to make a material impact on the growth rate of the validator set.
A pseudonymous developer for the Prysm (CL) client by the name of “Potuz” pushed back on Dapplion’s proposal saying that it would be difficult to reach consensus among core developers by Deneb, especially given the controversial nature of the code change. However, Potuz agreed that the proposal was simple enough that the changes could be activated in a separate hard fork shortly after Deneb. Additionally, Potuz stressed the importance of also rigorously evaluating how quickly alternatives to this proposal such as Neuder’s proposal can be prepared for implementation. Stokes agreed with Potuz’s sentiments saying that it felt to him like making a change to Deneb to include this proposal was unnecessary. “If everyone was convinced that the network is going to be in a really bad place soon, then we could have a separate CL-only hard fork soon, but it doesn’t seem like we’re quite there yet or anywhere near it really,” said Stokes.
Mikhail Kalinin, Teku (CL) developer, said that it was unrealistic in his view to expect Neuder’s proposals or any others with a similar level of complexity to be ready for implementation before Ethereum’s validator set size grows to 2mn. Without a countermeasure in place, Kalinin said that the computational load on nodes could increase 3x with the increased volume of messaging on the networking layer. “From what I’ve heard, the [validator attestation] aggregation is almost at its capacity today. If we drop more validators on the network, it can really get worse,” said Kalinin. Dapplion added that if the validator set size does grow to 2mn, solutions to reduce the size after the fact would result in longstanding technical debt that the network would have to carry forever. “ethDreamer”, a pseudonymous developer for the Lighthouse (CL) client, likened the simplicity of Dapplion’s proposal to a difficulty bomb pushback and emphasized that all other proposals for limiting validator set size growth were comparatively less ready for implementation.
“This is a card to keep on the table,” Stokes said, re-emphasizing, “It feels like we don’t need to make a decision right now and certainly I don’t think we need to think about putting it into Deneb. So, we’ll just continue the conversation as things evolve.” Kalinin disagreed saying that developers should be paying more attention to implementing quick countermeasures for the growing validator set size. He said it was not unrealistic to expect the activation queue for validators to remain full for the next 9 months and thereby for the number of validators to grow to 2mn over the next year. Dapplion added that the political controversy around this decision shouldn’t discourage developers from acting. He highlighted that developers during the launch of the Beacon Chain back in December 2020 had to make hard decisions around the issuance rate for validators. Therefore, “this is not such a controversial thing that we haven’t done in the past and we could do again to adjust to market conditions,” Dapplion said.
On the topic of changing the issuance rate of Ethereum, and reducing the security spend, Ethereum Foundation Researcher Dankrad Feist said that in his view adjusting the reward curve for validator was a more equitable way in his view to curb the growth of the validator set size than capping the churn limit. Additionally, such a change to the reward schedule would be equally as easy to implement by client teams as a change to the churn limit. Ansgar Dietrichs, Researcher for the Ethereum Foundation, acknowledged the controversy of this discussion and suggested that a “pragmatic first step” would be to communicate to the broader Ethereum community about the potential for an upcoming change to the way validator rewards are paid out. “Basically, no one should make a decision about staking their ETH relying on basically the payment schedule will still be in place a year from now, five years from now,” said Dietrichs. Stoked agreed with the sentiment that there was value in preparing the Ethereum community in the short-term for a potential change in the future. Stokes encouraged those listening to the developer call to take heed of this week's discussion around Dapplion's proposal.
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.