Summary of the latest meeting of ETH Workshop Core Developers: Activate the Cancun upgrade on the testnet in early January 2024

Original title: Ethereum All Core Developers ution Call #176 Writeup

Original article by Christine Kim

Original compilation: Luccy, BlockBeats

Editor’s note:

The ETH Workshop All Core Developer Consensus Calls (ACDEs) are held every two weeks to discuss and coordinate changes to the ETH Workshop Execution Layer (EL). This is ACDE’s 176th conference call, and it will cover discussions with the Cancun/Deneb upgrade, the progress of testing Devnet #12, and the Prague/Electra upgrade plan.

The developers discussed how the Cancun/Deneb upgrade was tested on Devnet #12, including progress and some issues found by different client teams, as well as technical challenges in blob propagation, MEV (Maximum Extractable Value), and more. For the upcoming Prague/Electra upgrade, the developers have proposed a series of possible technical changes.

Christine Kim, VP of Research at Galaxy Digital, gave a detailed note on the highlights of the meeting, which BlockBeasts compiled as follows:

On December 7, 2023, ETH developers gathered at Zoom for All Core Developers ution (ACDE) call #176. The ACDC Conference Call is a bi-weekly series of meetings led by Tim Beiko, Head of Protocol Support at the ETH Foundation, where developers discuss and coordinate changes to the ETH Place’s Executive Layer (EL). This week, the developers discussed testing the Cancun/Deneb upgrade on Devnet #12. They agreed to coordinate the activation date of the upgrade on the Goerli test network in ETH early January after the holiday ended. In addition, they plan to start discussions in early January about what code changes should be included in the next ETH workshop upgrade, Prague/Electra.

Devnet #12 update

Testing of the Cancun/Deneb upgrade on Devnet #12 is going well. Parithosh Jayanthi, a DevOps engineer at the Foundation, revealed that some bugs have been found in two clients, Reth and Lighthouse, and that the two client teams are working on an emergency fix. To test MEV workflows more thoroughly, DevOps teams are focusing more on enabling MEV-Boost software on more validators on Devnet #12. According to Jayanthi, his team has found at least one bug in the MEV relay implementation of Flashbots. Danny Ryan, a researcher at the ETH Foundation, emphasized that in order to ensure that validators can switch to the local block build in the event of a relay failure, additional testing is needed to check for alternate mechanisms.

For client-specific team upgrades, Terence Tsao, the developer of the Prysm client, said his team is working on an updated design for ACDC #122中讨论的 blob propagation. Tsao confirmed that the Prysm client will be ready to join Devnet #12 for testing next week, possibly next week. Justin Florentine, the developer of the Besu client, said that Besu is ready to move from Devnet #12. Representatives from the Nethermind, Erigon, Lodestar, and Teku client teams also said they were ready to continue testing the upgrade on the public ETH testnet.

Based on the client’s readiness, Beiko recommends coordinating a hard fork date as soon as the developers are out of the holidays. Assuming no major bugs are found on Devnet #12 in the next few weeks after the Prysm client joins, Beiko states that Cancun/Deneb activation on Goerli is likely to occur around mid-January. Ben Edgington from the Teku team asked developers if they were confident in changing the number of blobs per block from two to three. Ryan suggests additional testing of the increased blob targets during the massive shadow fork and Cancun/Deneb activation on Goerli. Beiko confirmed that the upgrade activation on Goerli will be the “last significant test” of the three blob targets per block. Assuming no issues are found, developers will continue to use the increased number of blobs for mainnet activation.

Overall, Beiko said that developers will continue to test upgrades on Devnet #12 between now and the end of the holidays. The DevOps team plans to launch at least one Goerli shadow fork by the end of December in preparation for a true Goerli hard fork in January. If the developers assemble for the New Year, they will discuss the date of the activation of the Goerli hard fork.

Builder override flags

Next, Tsao asked the client team about their progress in implementing the Builder override flag. The Builder override flag is a new Boolean field in the Cancun upgrade that the execution layer client can use to indicate to the consensus layer client that when the Builder detects censorship activity, the validator should fall back to the local block generation instead of using a third-party Builder. As Tsao emphasizes, the implementation details on how to detect the Builder’s review activities are subjective and deliberately left to the client team to design. For more information on Builder override flags, please refer to the minutes of ACDC#112 and ACDE#165.

The developer of the Geth client team, who goes by the screen name “Lightclient”, said that his team has implemented the flag, but will not merge it in the official release “in the near future”. Representatives from the Besu and Nethermind teams stated that this optional flag has not yet been implemented in their clients. Tsao emphasized that the flag can be a useful tool, and it is best to implement it as early as possible to discourage and discourage staking pools or large validator node operators from participating in certain “time games”. Tsao explained that validators can earn more MEV (Maximum Extractable Value) by delaying block propagation, and that after the introduction of blobs after the Cancun upgrade, there will be a delay 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 that blob transactions will have to compete with regular transactions, a pseudonymous developer on the Prysm team, who goes by the screen name Potuz, added: "Blobs need to compete not only with fees, but also with latency itself and all the MEV gained by delaying blocks. When designing the fee mechanism for blobs, I thought it was a market that had not been blocked or taken into account. Tsao said he would bring the issue up again in the Ethereum Research Discord for further discussion. In addition, Ryan highlighted Ethereum Foundation researchers Caspar Schwarz-Schilling and Mike Neuder’s latest post on “timing games” on the Ethresearch website.

Project Progress

Next, Beiko shared three updates related to the ETH Workshop upgrade planning process. First, as in the ACDC #123上讨论的那样, Beiko has created a Meta EIP document for the Cancun/Deneb upgrade, which lists all ETH Improvement Proposals (EIPs) that have been included in Cancun/Deneb. It has been created on GitHub with EIP number 7569. In addition, Beiko created EIP 7568 as the Meta EIP document for all previous upgrades, and the developers did not create a dedicated document to track the list of EIPs included in the upgrade. EIP 7568 is linked to the upgrade code specification.

Second, Beiko announced that he had created a new discussion thread on the Ethereum Magicians website to identify the next network upgrade, Prague/Electra. He asked developers to think critically about whether to bundle the Execution Layer (EL) and Consensus Layer (CL) upgrades together as the past two hard forks have done. The activation of certain code changes, such as EIP 7002, will require changes to both EL and CL, so both Prague and Electra upgrades will need to be coordinated. However, for other code changes, such as the Verkle tree, there is a way to redesign the implementation and only need to upgrade the CL.

Ryan noted that the consensus layer (CL) developers working in parallel with the Verkle tree are also making code changes to support data availability sampling. Beiko advises developers not to go into detail about all the EIPs they want to see in the Prague/Electra upgrade, but rather to review all candidate code changes during the holidays and be ready to discuss them seriously in January. Potuz agrees, adding that an EIP designed to address the growing problem of ETH validator set size would be an important code change in Prague/Electra. Based on the complexity of the code changes, Beiko recommends 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.