Ethereum Core Developers Latest Meeting Summary Goerli Shadow Fork to Take Place Before End of Year, Cancun/Deneb Upgrade to be Tested

Ethereum Core Developers Discuss Plans for Upcoming Meetings Goerli Shadow Fork Scheduled for End of Year, Cancun/Deneb Upgrade to Undergo Testing

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

Original Author: Christine Kim

Original Translation: Luccy, BlockBeats

Editor’s Note:

• Glassnode Bitcoin pacing back and forth, encountering resistance in its upward movement
• LianGuai Observation | Upbit coin effect reappears, CTC surges nearly 4 times in a single day. What is special about Creditcoin?
• Gods Unchained was delisted by Epic, Immortal Game halted P2E development, and Web3 gaming still faces numerous challenges entering the mainstream.

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 124th call covered updates on Devnet #12, progress on the Cancun/Deneb upgrade, and topics related to slashable information propagation. During the call, developers actively discussed minor changes to the Libp2p network protocol to reduce amplification effects of large messages on nodes.

Christine Kim, VP of Research at Galaxy Digital, provided a detailed writeup of the key points from this meeting, which BlockBeats has translated as follows:

On December 14, 2023, Ethereum developers gathered on Zoom for the All Core Developers Consensus (ACDC) call #124. ACDC calls are held every two weeks and are moderated by Danny Ryan, a researcher at the Ethereum Foundation. Developers discuss and coordinate changes to the Ethereum consensus layer (CL) during these calls. This week, the developers focused on the progress of the Cancun/Deneb upgrade on the Devnet #12 test network. Since the previous All Core Developer Execution (ACDE) meeting last week, all Execution Layers (EL) and Consensus Layers (CL) client combinations have been onboarded to Devnet #12, including the Prysm client. MEV-Boost software has been enabled, but the client combination with Prysm is not included. Developers mentioned that they are on track and plan to launch the Goerli shadow fork in the next one to two weeks to test the Cancun/Deneb upgrade, including all clients. Additionally, developers discussed the rules for slashable information propagation and the agenda for the next two weeks of calls.

Devnet #12 Updates

Barnabas Busa, a DevOps engineer at the Ethereum Foundation, stated that all EL/CL client combinations, including those using Prysm as the CL client, have successfully onboarded to Devnet #12. The client combination using Prysm has not undergone MEV-Boost software testing yet. However, on Devnet #12, the MEV workflow is being tested with other CL clients. Recently, the Lighthouse client has received patch updates to address errors related to MEV. Additionally, another DevOps engineer at the foundation, LianGuairithosh Jayanthi, noted issues with Besu nodes on Devnet #12 and they are working to determine the root cause. As the next step, developers will intentionally send malicious blocks over the network to test block production and run stress tests on the client combinations on Devnet, including the newly added Prysm client. Jayanthi mentioned in a public Discord message during the call that developers still plan to launch the shadow fork on the Goerli testnet before the end of the year.

Slashable Information Updates

Next, developers briefly discussed several issues related to the propagation and timing of slashable information on Ethereum after the Cancun/Deneb upgrade. 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 aiming to add new events to the Beacon Chain API that would allow node operators to be informed faster about slashable events. This would be particularly useful in cases where there is a high volume of slashable information. Dapplion mentioned in his PR: “For large operators, the total cost of slashing events largely depends on their response time. If many keys are involved in operational mistakes, then it could take some time for these slashable information to get included on the chain.” Dapplion’s PR has already been merged into the Beacon Chain API specification 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 are inclined to solve this problem by adding a timestamp field in the existing relevant Beacon Chain API events.

The third topic discussed by developers regarding slashable information propagation after the Cancun/Deneb upgrade is the propagation conditions of blobs. Lighthouse developer “sean” (or “realbigsean” on GitHub) pointed out that the existing blob propagation rules have unintended consequences. Sean expressed in the call, “If you broadcast verification with the Beacon API, then gossiping can lead to unexpected validity and invalidity of messages. The reason is that, 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 concerning slashable information propagation with blobs has no substantial impact on the health of the network, except that it is merely a “strange” outcome that node operators need to understand and parse. Therefore, while not urgent for the activation of Cancun/Deneb, he suggests developers consider modifying the rules for handling slashable information propagation in future upgrades. Danny Ryan agrees with this view, stating that developers should take the time to “comprehensively” consider methods to address this issue. Ryan suggests revisiting this topic in January to allow developers time to design a comprehensive plan for updating the propagation rules of slashable blobs and blocks.

Next, developers discussed minor changes to the libp2p network protocol to reduce the amplification effect of sending large messages (e.g., blocks with a large number of blobs) to nodes. Sean emphasized the addition of the “IDONTWANT” control message, which can be used to notify libp2p peer nodes to pause sending large messages. Ryan mentioned 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 next week’s ACDE conference call.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!