Original Title: "Ethereum All Core Developers Execution Call #176 Writeup"

Author: Christine Kim

Translation: Luccy, BlockBeats

Editor's Note:

The Ethereum All Core Developers Execution (ACDE) call is held every two weeks to discuss and coordinate changes to the Ethereum Execution Layer (EL). This is the 176th ACDE call, which covers discussions on various topics such as the Cancun/Deneb upgrade, progress on Devnet #12 testing, and planning for the Prague/Electra upgrade.

Developers discussed the testing progress of the Cancun/Deneb upgrade on Devnet #12, including the progress and issues discovered by different client teams, as well as technical challenges such as blob propagation and MEV (Maximum Extractable Value). For the upcoming Prague/Electra upgrade, developers proposed a series of possible technical changes.

Christine Kim, Vice President of Research at Galaxy Digital, provided a detailed record of the key points of this meeting, which BlockBeats has translated as follows:

On December 7th, 2023, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #176 meeting. The ACDC conference is a bi-weekly series of meetings supported by the Ethereum Foundation protocol lead Tim Beiko, where developers discuss and coordinate changes to the Ethereum execution layer (EL). This week, developers discussed the testing work of the Cancun/Deneb upgrade on Devnet #12. They agreed to coordinate the activation date of the upgrade on the Ethereum Goerli test network in early January after the holiday season. In addition, they plan to begin discussing which code changes should be included in the next Ethereum upgrade, Prague/Electra, in early January.

Devnet #12 Update

Cancun/Deneb upgrade testing on Devnet #12 is progressing smoothly. Parithosh Jayanthi, a DevOps engineer at the Foundation, revealed that some errors have been found in two clients, Reth and Lighthouse, and both client teams are working urgently to fix them. In order to test the MEV workflow more comprehensively, the DevOps team is focusing more on enabling MEV-Boost software on more validators on Devnet #12. Jayanthi said that his team has at least found one error in the MEV relay implementation of Flashbots. Ethereum Foundation researcher Danny Ryan emphasized that additional testing is needed to ensure that validators can switch to local block building in case of relay failure.

Regarding the upgrade of a specific client team, Terence Tsao, the developer of Prysm client, stated that his team is researching the updated design of blob propagation discussed in ACDC #122. Tsao confirmed that the Prysm client will be ready to join Devnet #12 for testing next week, possibly the week after. Justin Florentine, the developer of Besu client, stated that Besu is ready to move forward from Devnet #12. Representatives from Nethermind, Erigon, Lodestar, and Teku client teams also confirmed that they are ready to continue upgrade testing on the public Ethereum test network.

Based on the readiness of the client, Beiko suggests coordinating a hard fork date as soon as developers return from the holiday. Assuming no major issues are found on Devnet #12 in the coming weeks after the addition of the Prysm client, Beiko indicates that the activation of Cancun/Deneb on Goerli may take place around mid-January. Ben Edgington from the Teku team inquires whether developers are confident in the change to increase the number of blobs per block from two to three. Ryan suggests additional testing of the increased blob target during the large-scale shadow fork and activation of Cancun/Deneb on Goerli. Beiko confirms that the upgrade activation on Goerli will be the "last significant test" for three blob targets per block. Assuming no issues are found, developers will proceed with the increased blob count for mainnet activation.

Overall, Beiko stated that developers will continue testing the upgrade on Devnet #12 between now and the end of the holiday season. The DevOps team plans to initiate at least one Goerli shadow fork before the end of December in preparation for the Goerli hard fork in January. If developers convene in the new year, they will discuss the activation date for the Goerli hard fork.

Builder Coverage Flag

Next, Tsao inquired about the progress of the client team in implementing the Builder override flag. The Builder override flag is a new boolean field in the Cancun upgrade, which the execution layer client can use to indicate to the consensus layer client that when the Builder detects review activity, validators should roll back to local block generation instead of using a third-party Builder. As Tsao emphasized, the implementation details of how to detect Builder review activity are subjective and intentionally left to the client team's design. For more information on the Builder override flag, please refer to the meeting notes of ACDC#112 and ACDE#165.

The developer of the Geth client team, known as "Lightclient" online, has stated that their team has implemented the flag, but it will not be merged into the official release in the "near future". Representatives from the Besu and Nethermind teams have stated that the optional flag has not yet been implemented in their clients. Tsao emphasized that the flag could be a useful tool and it is best to implement it as soon as possible to prevent and combat certain "time games" played by staking pools or large validator node operators. Tsao explained that validators can gain more MEV (Maximum Extractable Value) by delaying block propagation, and after the introduction of blobs in the Cancun upgrade, there will be delays in block propagation. During these delays, validators may choose to include more profitable MEV transactions in the block, which is suboptimal for timely blob propagation.

Confirming blob transactions will have to compete not only with regular transactions, but also with the delay itself and all MEV obtained through delayed blocks, according to a developer with the Prysm team who goes by the screen name Potuz. "Blobs not only need to compete with fees, but also with the delay itself and all MEV obtained through delayed blocks. I think this is a market that has not been prevented or considered when designing the fee mechanism for blobs," Potuz added. Tsao said he would bring up the issue for further discussion on the Ethereum Research Discord. Additionally, Ryan emphasized the latest post on "timing games" by Ethereum Foundation researchers Caspar Schwarz-Schilling and Mike Neuder on the Ethresearch website.

Project Progress

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

Secondly, Beiko announced that he has created a new discussion topic on the Ethereum Magicians website to determine the next network upgrade, namely Prague/Electra. He requested developers to critically consider whether to bundle the upgrade of the execution layer (EL) and the consensus layer (CL) together, as was done in the past two hard forks. The activation of certain code changes, such as EIP 7002, will require changes to both EL and CL, thus requiring coordination of the Prague and Electra upgrades simultaneously. However, for other code changes, such as Verkle trees, there are methods to redesign the implementation that only require an upgrade to CL.

Ryan pointed out that developers working on the consensus layer (CL) in parallel with Verkle trees are also making code changes to support data availability sampling. Beiko suggested that developers not discuss all the details of the EIPs they would like to see in Prague/Electra upgrade, but instead review all candidate code changes during the holidays and be prepared to discuss these changes seriously in January. Potuz agreed with this view and added that an EIP aimed at addressing the problem of Ethereum validator set size growth will be an important code change in Prague/Electra. Due to the complexity of code changes, Beiko suggested that developers organize dedicated meetings after the holidays to discuss these larger protocol changes for certain EIPs, such as Verkle or data availability sampling.

"Original article link"

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia