Ethereum All Core Developers Consensus Call #117 Writeup
On September 7, 2023, Ethereum core developers gathered over Zoom for their 117th All Core Developers Consensus (ACDC) call. The ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum. Chaired by Ethereum Foundation Researcher Danny Ryan, ACDC #117 featured discussions on the following topics:
Dencun testing
EIP 4844 blob parametrization
SSZ StableContainer proposal
Limiting validator churn.
Dencun Testing
Developers are continuing to test the Cancun/Deneb (Dencun) upgrade on Devnet #8. Barnabas Busa, a DevOps Engineer for the Ethereum Foundation, said Devnet #8 remains healthy and stable. “We have 100% block proposals. All the nodes are [syncing] up to the head [of the chain]. I just deposited some more validators for Erigon, so we are going to be able to check if Erigon is also able to make block proposals. We indeed have all the clients,” said Busa.
Terence Tsao from the Prysm (CL) client team gave a short update on the issues their software was having on Devnet #8. Tsao said the issues were related to their strategy around blob retention, blob subnet count, and blob hashing. All these issues have since been fixed. Justin Florentine from the Besu (EL) client team also highlighted an issue with their software and its interactions with the Lighthouse (CL) client. A developer by the screenname “sean” from the Lighthouse (CL) team acknowledged the issue, and said a fix was in the works.
Then, developers discussed the launch of Devnet #9. On Monday, September 4, on Dencun Interop Testing Call #30, developers agreed to launch Devnet #9 on Tuesday, September 12. However, on ACDC #117, Mario Vega, who is on the testing team at the Ethereum Foundation, said that he would appreciate more time to update Dencun-related tests for the next Devnet. Developers agreed to push out the launch of Devnet #9 one week to the following Tuesday, September 19.
Busa gave a quick reminder that there is an open pull request on Devnet #8 code specifications that should be reviewed by developers and resolved before the launch of Devnet #9. Also, Ryan gave a reminder to client teams to consider the Dencun testing overview document that Parithosh Jayanthi, a DevOps Engineer at the Ethereum Foundation presented during the prior ACDC call and drop in suggestions for any missing areas of testing for the Dencun upgrade. Jayanthi said that he was already working with the Nethermind (EL) client team on sync tests and that the chaos tests designed to simulate several varying chaotic network situations were a “work-in-progress,” likely to be finalized by the end of the month.
EIP 4844 Blob Parametrization
To better understand the impact of blobs on block propagation on Ethereum mainnet, smart contract auditing firm CodeX has been working with the Ethereum Foundation and the Nimbus (CL) team on a series of experiments. Leonardo A. Bautista Gomez, a senior researcher at Status, the company building the Nimbus client, gave an overview of the experiments in a comment. He wrote, “During May 28th and June 11th, there was an experiment performed to inject large blocks on Mainnet and study their propagation. Multiple ‘sentry’ nodes were deployed before the injection, in 3 locations around the world, to study the latency in different geographies. We studied the block diffusion latency for different block sizes, as well as the attestation latency.”
Csaba Kiraly, also a senior researcher at Status, presented the findings of the experiments on ACDC #117. “What you see here is what you expect. The bigger the block, the bigger the delay [in block propagation,” said Kiraly, noting that for blocks between 64 and 128 KB, 80% arrives within 2 seconds from the slot start time. On average, Ethereum blocks are 100kB. Slots are a duration of time lasting 12 seconds during which a validator can propose a block. The following is a chart illustrating the analysis on block propagation latency on Ethereum mainnet:
Source: YouTube, Consensus Layer Meeting #117
Kiraly noted that the above analysis did vary depending on the CL client that was used to propagate blocks. However, he highlighted that the reason for this may not be due to differences in client performance but rather differences in timestamp semantics. Some clients use timestamps for blocks that have been received, while others timestamp blocks that they have already processed. Kiraly recommended standardization around timestamp semantics between clients for more accurate data analysis.
Aside from the experiments, Gomez highlighted that his team also did analysis on natural on-chain occurrences of large-sized Ethereum blocks. From March to August 2023, Gomez said 8.2% of mainnet blocks were larger than 250KB. One particularly large block propagated on August 22, 2023, was a whopping 2.3 MB in size. For blocks larger than 250 KB on Ethereum, Gomez says propagation will take on average 2 seconds longer than 100KB blocks. Developers were encouraged to ask questions about the analysis both on the call and asynchronously by reaching out to the CodeX team. Links to the analysis presented on ACDC #117 about large block propagation can be found on the call agenda here.
Based on the analysis, Ryan asked whether developers felt comfortable discussing final parameters for EIP 4844, specifically the target/maximum blob count per block. Based on prior conversations, developers are considering increasing the target maximum blob count from 2/4 to 3/6. There were no updated thoughts on this parameter from developers, and so Ryan suggested revisiting this topic in a few weeks’ time after more Dencun testing.
SSZ StableContainer Proposal
As mentioned on ACDE #169, Etan Kissling, a developer for the Nimbus (CL) client, is working on upgrading Ethereum’s data structures to a new serialization format known as SSZ. He has named his new approach to this upgrade “StableContainer” and formatted it into a formal Ethereum Improvement Proposal (EIP). EIP 7495 is more flexible than prior SSZ types, which only work within one version of Ethereum, that is one fork of Ethereum. The new design scheme can support new fields and deprecate old ones. Because of its flexibility, Kissling said that the StableContainer may have use cases beyond its intended goal of supporting the transition to SSZ, such as various optimizations to the EL payload header. Kissling also mentioned that the timing of EIP 7495 implementation may change specifications for other EIPs such as EIP 6475, the SSZ type to represent optional values.
Ryan encouraged developers to review EIP 7495 and chime in with feedback in the Discord #typed-transactions channel.
Limiting Validator Churn
The last topic of discussion on ACDC #117 was a proposal to limit validator churn. This proposal was initially presented by a pseudonymous developer for the Lodestar (CL) client team with the screen name “Dapplion” on ACDC #113. As a reminder, Dapplion’s proposal would enforce a maximum churn limit so that the number of validators that can enter and exit Ethereum per epoch stays constant, instead of growing exponentially with the growth of the validator set. The proposal would be a short-term solution to curb the growth of the active validator set, which since the Shanghai upgrade in April 2023 has been increasing rapidly. 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.
On ACDC #117, Dapplion reiterated that the effectiveness of his proposal diminishes the longer developers wait to implement it on Ethereum and recommended including it for the Dencun upgrade. “Let’s limit the churn so that at least we buy some time and whenever we come up with a definitive solution in a year or half a year or two years, the network is still at a size that could be manageable. Specifically, if we go for some solution, such as changing the reward score to encourage stakers to leave, if we already have such a big validator set, I think it would be rather complicated to do so. Again, just take a look at the proposal, think about it, and if we want to do something about it, we should do it now,” said Dapplion.
Ryan said that there are no "perfect" band-aid solutions to the problem of Ethereum’s growing validator set size but Dapplion’s proposal in his view is a “reasonable” short-term solution. Sean from the Lighthouse (CL) team said that he would appreciate more time to think about the proposal but that from his initial first impressions he was against the notion of including it in the Dencun upgrade. “It’s small enough that we could do it in its own fork in something equivalent to like a difficulty bomb delay. I think it’d be better to put more effort into a better fix. Also, clients are continuing to improve how they handle larger validator set sizes. So, I don’t think I’m in favor of it at this point,” said Sean. Ethereum Foundation researcher Dankrad Feist was in favor of Dapplion’s proposal being included in Dencun, according to Ryan.
After some more discussion between developers, Ryan said that a decision to include Dapplion’s proposal in the Dencun upgrade this late into the upgrade’s testing cycle would require a “loud” show of support from developers. “I do think that we’re at the default stable spec [stage] unless there’s quite a verbal consensus here to switch. I encourage you to look at this proposal. There are high urgency problems in this domain and it’s probably going to be a big part of the Electra conversation if nothing’s done now. So let’s continue the conversation and if this does bubble up as a critical, high urgency [problem] after others have reviewed this, thought more deeply about it this week, speak up,” said Ryan.
Developers agreed to revisit this topic of discussion on next week’s ACDE call. Busa reminded developers that the Holesky testnet will be launched next week on Friday, September 15. Jayanthi encouraged any client teams running validators for the genesis of Holesky that did not receive information about the launch to reach out to him and his team.
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.