skip to content

Ethereum All Core Developers Consensus Call #117 Writeup

Ethereum All Core Developers Execution Call -156 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:

block propagation latency screenshot

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.