Summary of the latest meeting of ETH Place's core developers: There will be a Goerli shadow fork and a test of the Cancun/Deneb upgrade before the end of the year

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

Original article by Christine Kim

Original compilation: Luccy, BlockBeats

Editor’s note:

The ETH Workshop All Core Developer Consensus Calls (ACDCs) are held bi-weekly to discuss and coordinate changes to the ETH Workshop’s Consensus Layer (CL). This is the ACDC’s 124th conference call, which covers updates to Devnet #12, progress on the Cancun/Deneb upgrade, and topics related to Slashable’s dissemination. During the meeting, the developers actively discussed minor changes to the Libp2p network protocol to reduce the amplification effect of large messages on nodes.

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 14, 2023, ETH developers gathered on Zoom for the All Core Developers Consensus (ACDC) call #124 session. The ACDC conference call is a bi-weekly series of meetings led by Danny Ryan, a researcher at the ETH Workshop Foundation, where developers discuss and coordinate changes to the ETH Workshop Consensus Layer (CL). This week, the developers focused on the progress of the testing of the Cancun/Deneb upgrade on the Devnet #12 testnet. Since last week’s All-Core Developer Execution (ACDE) meeting, all Execution Layer (EL) and Consensus Layer (CL) client combinations have been onboarded to Devnet #12, including the Prysm client. MEV-Boost software is enabled, but client combinations with Prysm are not included. The developers said they are on track with plans to launch the Goerli shadow branch in the next one to two weeks to test the Cancun/Deneb upgrade and include all clients. In addition, the developers discussed the rules for the dissemination of information about Slashable, as well as the schedule of calls for the next two weeks.

Devnet #12 update

Barnabas Busa, DevOps Engineer at the ETH Foundation, said that all EL/CL client combinations, including those that use Prysm as a CL client, have been successfully integrated into Devnet #12. The client portfolio using Prysm has not been tested for MEV-Boost software. However, on Devnet #12, the MEV workflow is testing other CL clients. Recently, the Lighthouse client has undergone a patch update to address MEV-related bugs. In addition, Parithosh Jayanthi, another DevOps engineer at the Foundation, said that they noticed an issue with the Besu node on Devnet #12 and that they are still working to determine the root cause. As a next step, developers will deliberately send malicious blocks over the network, test block generators, and run hive tests for newly added Prysm clients to stress test client combinations on Devnet. Jayanthi said in a public Discord message during the call that the developers still plan to launch a shadow branch on the Goerli testnet by the end of the year.

Slashable information updated

Next, the developers briefly discussed several issues related to the spread and timing of Slashable’s message on the ETH after the Cancun/Deneb upgrade. For background, Slashable information includes the propagation of duplicate or invalid blocks and blobs. Dapplion, an anonymous developer of the Lodestar client, has made a pull request (PR) via GitHub that aims to add new events to the Beacon Chain API to enable node operators to learn about Slashable events more quickly, which would be especially useful if there is a large amount of Slashable information. In his PR, Dapplion mentions, "For large operators, the total cost of a cutting event depends heavily on their response time. If there are many keys involved in operational errors, then it may take some time for this slashable information to be included on the chain. Dapplion’s PR was merged into the specification of the Beacon Chain API prior to the call and is being implemented by various CL client teams, such as Prysm and Lighthouse.

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

The third topic that developers discussed related to the propagation of Slashable information after the Cancun/Deneb upgrade was blob propagation conditions. Lighthouse developer “sean” (or “realbigsean” on GitHub) pointed out that the existing blob propagation rules led to unintended consequences. During the call, Sean said, "If you’re using the Beacon API for broadcast authentication, it’s unexpected that a gossip approach can lead to valid and invalid messages. The reason for this is that, technically, it is possible to propagate two blobs with different blob indexes of the Slashable header associated with them. You are allowed to propagate these, but not those that have the same blob index. 」

Sean added that the strange behavior when it comes to the slashable information propagation of blobs has no substantial impact on the health of the network, other than just a “weird” result for node operators to understand and parse. Therefore, while there is no urgency for the activation of Cancun/Deneb, he suggests that developers consider making changes to the rules for handling Slashable information dissemination in future upgrades. Danny Ryan agrees, saying that developers should take the time to think “holistically” about how to solve this problem. Ryan suggests revisiting this topic in January to give developers time to devise a comprehensive plan to update Slashable’s blob and block propagation rules.

Next, the developers discussed minor changes to the libp2p network protocol to reduce the amplification effect on nodes sending large messages, such as blocks with a large number of blobs. Sean highlighted the new “IDONTWANT” control message, which can be used to notify libp2p peers to pause sending large messages. Ryan said he will try to reach out to the libp2p team to merge this PR, and if there are further delays, the issue will be revisited in the ACDE conference call next week.