Partnered With:

Summary of the latest Ethereum core developer meeting: Progress on Cancun/Deneb upgrade testing and updates on slashable information.

Read this article in 9 Minutes

On December 14th, all core developers of Ethereum participated in the 124th All Core Developers Consensus (ACDC) conference call.

Original Title: "Ethereum All Core Developers Consensus Call #124 Writeup"

Author: Christine Kim

Translated by: Luccy, BlockBeats

Editor's Note:

The Ethereum All Core Developers Consensus Call (ACDC) is held every two weeks to discuss and coordinate changes to the Ethereum consensus layer (CL). This is the 124th ACDC conference call, which mainly covers updates on Devnet #12, progress on the Cancun/Deneb upgrade, and issues related to Slashable information dissemination. During the call, developers actively discussed minor changes to the Libp2p network protocol to reduce the amplification effect of large messages on nodes.

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

On December 14th, 2023, Ethereum developers gathered on Zoom for the All Core Developers Consensus (ACDC) call #124 meeting. The ACDC conference is a bi-weekly series hosted by Ethereum Foundation researcher Danny Ryan, where developers discuss and coordinate changes to the Ethereum consensus layer (CL). This week, developers focused on discussing the progress of the Cancun/Deneb upgrade on the Devnet #12 test network. Since last week's All Core Developers Execution (ACDE) meeting, all Execution Layer (EL) and Consensus Layer (CL) client combinations have been connected to Devnet #12, including the Prysm client. MEV-Boost software has been enabled, but not with the Prysm client combination. Developers say they are proceeding as planned and plan to launch the Goerli shadow branch in the next one to two weeks to test the Cancun/Deneb upgrade, including all clients. In addition, developers also discussed the rules for Slashable information dissemination and the schedule for the next two weeks of calls.

Devnet #12 Update

The DevOps engineer of the Ethereum Foundation, Barnabas Busa, stated that all EL/CL client combinations, including those using Prysm as the CL client, have successfully connected to Devnet #12. Client combinations using Prysm have not yet undergone MEV-Boost software testing. However, on Devnet #12, the MEV workflow is being tested with other CL clients. Recently, the Lighthouse client has been patched to address MEV-related errors. In addition, another DevOps engineer of the Foundation, Parithosh Jayanthi, stated that they have noticed issues with Besu nodes on Devnet #12 and are still working to determine the root cause. As the next step, developers will intentionally send malicious blocks over the network to test block generators and run hive tests for the newly added Prysm client to stress test client combinations on Devnet. Jayanthi stated in a public Discord message during the call that developers still plan to launch the shadow branch on the Goerli testnet before the end of the year.

Slashable Information Update

Next, the developers briefly discussed several issues related to the dissemination and timing of Slashable information on Ethereum after the Cancun/Deneb upgrade. As background, Slashable information includes the propagation of duplicate or invalid blocks and blobs. Dapplion, an anonymous developer of the Lodestar client, submitted a pull request (PR) on GitHub aimed at adding new events to the Beacon Chain API, allowing node operators to more quickly understand Slashable events, especially in cases where there is a large amount of Slashable information. Dapplion mentioned in his PR: "For large operators, the total cost of cutting events depends largely on their response time. If many keys are involved in operational errors, then these Slashable information may take some time to be included in the chain." Dapplion's PR has already been merged into the specification of the Beacon Chain API before the call and is being implemented by various CL client teams, such as Prysm and Lighthouse.

Dapplion also proposed a PR related to measuring block propagation time. He pointed out that due to the Cancun/Deneb upgrade and the introduction of blob transactions, measuring block propagation time will become more difficult. Dapplion detailed his proposed solution in his PR. As developers noticed in the PR thread, they tend to solve this problem by adding a timestamp field in existing relevant Beacon Chain API events.

The third topic discussed by developers regarding the spread of slashable information after the Cancun/Deneb upgrade is the propagation conditions of blobs. Lighthouse developer "sean" (or "realbigsean" on GitHub) pointed out that the existing rules for blob propagation have led to unexpected consequences. Sean stated during the conversation, "If you use the Beacon API for broadcast verification, then the validity and invalidity of messages may be unexpected when gossiping. This is because, technically, it is possible to propagate blobs with different blob indexes that have Slashable headers associated with them. You are allowed to propagate these, but not those with the same blob index."

Sean added that the strange behavior when it comes to the propagation of Slashable information related to blobs has no substantial impact on the health of the network, except for being a "strange" result that node operators need to understand and parse. Therefore, although it is not urgent for the activation of Cancun/Deneb, he suggests that developers consider modifying the rules for handling Slashable information propagation in future upgrades. Danny Ryan agrees with this view and suggests that developers take the time to "comprehensively" consider solutions to this issue. Ryan proposes to revisit this topic in January, allowing developers time to design a comprehensive plan to update the rules for Slashable blobs and block propagation.

Next, developers discussed minor changes to the libp2p network protocol to reduce the amplification effect of sending large messages (such as blocks with a large number of blobs) to nodes. Sean emphasized the new "IDONTWANT" control message, which can be used to notify libp2p peer nodes to pause sending large messages. Ryan said he would try to contact the libp2p team to merge this PR, and if there is further delay, the issue will be discussed again in next week's ACDE conference call.