skip to content

Ethereum All Core Developers Execution Call #176 Writeup

Ethereum All Core Developers Consensus Call #186 Writeup — Galaxy Research

On December 7, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) Call #176. Chaired by the Ethereum Foundation’s Protocol Support Lead Tim Beiko, the ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers discussed ongoing testing efforts for the Cancun/Deneb upgrade on Devnet #12. They agreed to coordinate an activation date for the upgrade on the Ethereum Goerli test network after the holidays in early January. Additionally, they agreed to begin discussions in early January on what code changes should be included in the next Ethereum upgrade, Prague/Electra.

Devnet #12 Updates

Testing for the Cancun/Deneb upgrade is well underway on Devnet #12. Parithosh Jayanthi, a DevOps Engineer at the Foundation, said that bugs have been discovered in two clients, Reth and Lighthouse, so far. Both client teams are in the process of patching. The DevOps team is focusing more testing efforts on the MEV workflow by activating MEV-Boost software across more validators on Devnet #12. Jayanthi said that his team has found at least one bug in the Flashbots’ MEV relay implementation. Danny Ryan, an Ethereum Foundation researcher, stressed that additional tests will be needed to check the fallback mechanisms for validators to local block building in the event of relay failures.

Moving on to client team specific upgrades, Terence Tsao, a developer for the Prysm client, said that his team is working on the revamped design for blob propagation discussed on ACDC #122. Tsao affirmed that the Prysm client will be ready to join Devnet #12 for testing next week, potentially the week after next. Justin Florentine, a developer for the Besu client, said that Besu is ready to move on from Devnet #12. Representatives from the Nethermind, Erigon, Lodestar, and Teku client teams echoed the same readiness to move ahead to testing the upgrade on public Ethereum testnets.

Based on client readiness, Beiko recommended coordinating a hard fork date as soon as developers return from the holiday break. Assuming no major bugs are discovered in clients on Devnet #12 in the coming weeks after the addition of the Prysm client, Beiko said Cancun/Deneb activation on Goerli could tentatively happen some time by mid-January. Ben Edgington from the Teku team asked developers whether they were confident about the change to target blob count per block from two blobs to three. Ryan suggested additional testing for the increased blob target on a large-scale shadow fork and during Cancun/Deneb activation on Goerli. Beiko affirmed that upgrade activation on Goerli would be “the last significant test” for the three blob per block target. Assuming no issues are discovered, developers will move ahead with the increased blob count for mainnet activation.

In summary, Beiko said that developers will continue to test the upgrade on Devnet #12 between now and the end of the holiday season. The DevOps team will launch at least one shadow fork of Goerli before the end of December in preparation for the real hard fork on Goerli some time in January. Once developers have reconvened in the new year, they will discuss a date for Goerli hard fork activation.

Builder Override Flag

Then, Tsao asked the status of client teams on their implementation of the builder override flag. The builder override flag is a new Boolean field in the Cancun upgrade that execution layer clients can use to indicate to consensus layer clients that validators should fall back on local block production instead of a third-party builder due to the detection of censoring activity by builders. As highlighted by Tsao, the implementation details for how to detect censoring activity by builders is subjective and intentionally left up to client teams to design. For more information on the builder override flag, refer to prior call notes here and here.

A pseudonymous developer for the Geth client team by the screen name “Lightclient” said that his team had implemented to the flag but would not be merging it in an official release any time “in the near future.” Representatives from the Besu and Nethermind teams indicated that they had not implemented the optional flag within their clients. Tsao highlighted that the flag could be a useful tool to implement sooner rather than later to dissuade and discourage staking pools or large validator node operators from engaging in certain “timing games.” Tsao explained that validators can earn more MEV, maximal extractable value, from delaying block propagation and with the introduction of blobs post-Cancun upgrade, delays to block propagation will be created. Instead of including blobs in blocks during these delays, validators may choose to include more lucrative MEV transactions, which is suboptimal for timely blob propagation.

Affirming that blob transactions will have to compete with regular transactions for inclusion in a block, a developer from the Prysm team with the screen name Potuz added, “Blobs not only need to compete with fees, but they also need to compete with that delay itself and all the MEV that you can get out of delaying your block. This is a market that I think wasn’t prevented or thought of when the fee mechanism for blobs was designed.” Tsao said that he would resurface this issue for further discussion in the Ethereum Research Discord. Additionally, Ryan highlighted a recent post on the Ethresearch site about the topic of timing games by Ethereum Foundation researchers Caspar Schwarz-Schilling and Mike Neuder.

Process Items

Next, Beiko shared three updates related to the Ethereum upgrade planning process. First, as discussed on ACDC #123, Beiko has created a Meta EIP document for the Cancun/Deneb upgrade, which lists all of the Ethereum Improvement Proposals (EIPs) that have been included in Cancun/Deneb. It has been created on GitHub with an EIP number of 7569. Additionally, Beiko has created EIP 7568 as the Meta EIP documents for all prior upgrades for which developers did not create a dedicated document tracking the list of EIPs included in an upgrade. EIP 7568 will link to upgrade code specifications.

Second, Beiko announced that he has created a new discussion thread on the Ethereum Magicians site to scope out the next network upgrade, Prague/Electra. He asked that developers think critically about whether to couple the EL and CL upgrades together as they have for the last two hard forks. The activation of certain code changes such as EIP 7002 will require changes on both the EL and CL and thus, will require coordinating Prague and Electra upgrades at the same time. However, for other code changes such as Verkle trees, there are ways to re-work the implementation to only require an upgrade to the CL.

Ryan notes that CL developers in parallel to Verkle trees are also working on code changes to support data availability sampling. Rather than going into the details of all the EIPs that developers would like to see in the Prague/Electra upgrade, Beiko recommended that developers review all candidate code changes over the holidays and be ready to discuss them in earnest in January. Potuz agreed with this sentiment and added that an EIP to address Ethereum’s validator set size growth issue would be an important code change to add to Prague/Electra. Based on the complexity of a code change, Beiko recommended that for certain EIPs such as Verkle or data availability sampling, developers organize dedicated meetings after the holidays to discuss these larger protocol changes in detail.