Partnered With:

Summary of the latest meeting of Ethereum core developers: Dencun mainnet activation time, Electra upgrade proposal

Read this article in 20 Minutes

On February 8, all core developers of Ethereum participated in the 127th All Core Developers Consensus (ACDC) conference call.

Original Title: "Ethereum All Core Developers Consensus Call #127 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 127th ACDC conference call, which discussed in-depth the testing status of the upcoming Dencun upgrade, the mainnet activation date, and issues related to the mainnet missing block event.

At the same time, the meeting also discussed multiple proposals in the Electra upgrade, including EIP 7549, five EIPs related to the SSZ format, ePBS, and inclusion lists. During the discussion, developers fully discussed and evaluated the priority, design complexity, and impact on the Ethereum protocol of each proposal.

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 February 8th, 2024, Ethereum developers gathered on Zoom for the All Core Developers Consensus (ACDC) call #127 meeting. The ACDC conference call is a bi-weekly series of meetings hosted by Ethereum Foundation researcher Danny Ryan, where developers discuss and coordinate changes to the Ethereum consensus layer (CL). This week, developers scheduled the Dencun upgrade to activate on the mainnet on March 13th, 2024. They also discussed the lessons learned from an event on the mainnet that caused 9 missed validation opportunities. The event occurred on Tuesday, February 6th, 2024, and reignited discussions about the enshrined proposal to build separation (ePBS) to eliminate validator reliance on trusted relays. Additionally, developers agreed to reconsider code changes such as maxEB and inclusion lists in the Electra upgrade.

Dencun Test

The Ethereum Foundation's developer operations engineer, Parithosh Jayanthi, said that the Dencun upgrade was successfully activated on the Holesky testnet on Wednesday, February 7. Jayanthi said, "At least on Holesky, we didn't notice any issues." He added, "We have passed the expiration window of the blob transactions on Goerli, so we are running a bunch of nodes and conducting genesis synchronization and checkpoint synchronization tests."

Prysm developer Terence Tsao mentioned that he missed the fork transition block during the Holesky upgrade. Although this "is not a big problem," Tsao said that the event caused his node to have an 11-second block delay. He suggested that the client team carefully check whether their implementation caused such a delay in some way during the upgrade.

Lighthouse developer "Sean" said that the Lighthouse team has implemented logic related to node recovery in their client, which allows nodes to recover through checkpoint synchronization that depends on an unfinished checkpoint when the chain has not yet completed the blob transaction. However, Sean said that implementing this logic was more complex than his team expected, and encouraged the CL client team to seek help when encountering similar difficulties.

Nethermind developer Marcin Sobczak said his team is continuing to investigate the potential bug mentioned in last Thursday's ACD conference call in their client. Sobczak said his team has started sending a large number of transactions to the Goerli network and so far, no issues have been found. He said testing on Goerli should be completed within a few hours.

Dencun Mainnet Activation

The protocol support lead of the Ethereum Foundation, Tim Beiko, shared the activation date and time of the Dencun upgrade on the mainnet:

Screenshot of Dencun mainnet fork time:

Title: Dencun Hard Fork Time

Source: YouTube, @EthereumProtocol

Beiko mentioned that he has contacted the top 10 Ethereum Rollups teams on L2Beat.com to evaluate their readiness for Dencun. "All teams are basically in various testing stages. I think the L2 teams will be ready to use 4844 on the mainnet around early to mid-March," Beiko said. "I don't think we should stop anything based on the readiness of L2 teams."

Tsao said that from the Prysm side, his team hopes to have two weeks to prepare for the final mainnet release of the Dencun upgrade. Sean, representing the Lighthouse client team, agrees with this schedule. Other CL client teams, such as Teku and Lodestar, say they can also prepare the final mainnet client release version within two weeks.

Based on this sentiment, Beiko initially suggested setting the mainnet upgrade date on Thursday, March 8th or Tuesday, March 12th. However, developers opposed the tight turnaround time between the final client release and the proposed hard fork date in the Zoom meeting chat. Developers agreed to leave three weeks between the final client software version release and the upgrade date. Developers will have the final client release ready before the next ACDC conference call, which is on Thursday, February 22nd, 2024. Then, Beiko will officially release a blog post on the following day, Friday, February 23rd, 2024, announcing the activation of Dencun's mainnet. Mainnet node operators will have approximately three weeks from that time to upgrade their software, and the Dencun hard fork will occur on March 13th, 2024.

Missed Block Event on Mainnet

On Tuesday, February 6th, 2024, Bloxroute Max Profit relay delivered 9 blocks that failed to be added to the Ethereum blockchain to validators for delivery. This was due to an error in the relay that failed to properly downgrade the block producers submitting problematic blocks. Bloxroute subsequently patched their relay and compensated validators for missed block rewards.

This event has reignited discussions on how to best mitigate validators' dependence on blocks containing MEV. Prysm developer "Potuz" suggested an immediate solution could be to add a new heuristic to validators' circuit breaker functionality to check for invalid blocks and fallback to local block generation when two or three consecutive invalid blocks are relayed. Ethereum Foundation researchers Danny Ryan and Dankrad Feist are concerned that this heuristic could be easily exploited by savvy MEV participants who may intentionally trigger the circuit breaker to temporarily capture all MEV in the blocks for themselves. Sean from Lighthouse pointed out that the precise implementation of the heuristic may vary by client, making it harder for malicious actors to exploit, but Ryan suggested that this heuristic may still have a standard that most client implementations follow.

Later, Ryan proposed an idea for a "gossip channel", where validators could listen and provide information about block signatures of block producers, to quickly notify the entire network of problematic producers without relying on relays. However, Potuz opposed this idea, stating that developers should invest resources in delivering ePBS, a code change that would completely eliminate the need for trusted relays and support direct interaction between block producers and validators. Before delving into whether ePBS should be prioritized over short-term solutions such as a dedicated gossip channel for block validation, Danny Ryan suggested evaluating several other code changes proposed for Electra.

Electra Proposal

Briefly, Ryan asked the developers if they support using "Pectra" as the merged upgrade name for Prague/Electra. The developers on the conference call seemed to have no strong opinions on this compound word. Ryan continued to discuss which code changes should be prioritized for Electra issues.

Electra EIP 7549

During ACDC #126, developers agreed to include EIP 7549 in the Electra upgrade. EIP 7549 is a code change that only affects Ethereum CL and aims to make the aggregation of proofs by validators more efficient. Developers have agreed to adopt the simplest design of EIP 7549 to be included in Electra. However, according to further discussions among developers on code changes on GitHub, some hope to increase the complexity of the code changes to have a wider impact on the network. Teku developer Mikhail Kalinin explained, "This is a further development based on the initial proposal of EIP 7549. As Danny said, it allows us to tightly pack proofs on-chain. The benefit is that, given the current size of the validator set, we can increase the proof block space by up to four times. Currently, if they aggregate ideally, we can keep proofs of two slots. This change will allow us to increase this number to eight slots without increasing the byte block size."

Danny Ryan agrees that this is a good change to the EIP, but suggests carefully weighing the potential impact it may have on the protocol. Ryan said, "You increase capacity, but you decrease the potential diversity of that capacity, which seems like a reasonable trade-off, but the risks need to be considered." Kalinin agrees and says he will further analyze and provide new specification changes under the same EIP number.

Electra SSZ

As discussed in ACDC＃126, developers are considering five EIPs related to the SSZ format. Sean from Lighthouse stated that he needs to evaluate the code changes in more detail, but from his perspective, these changes are "a good thing". Another developer reportedly wrote in a Zoom chat that they hope to bundle the SSZ format changes as a large change to the protocol, rather than implementing them in stages. Ryan suggested that the client team conduct more due diligence on the SSZ changes proposed by Nimbus developer Etan Kissling and revisit the topic at the next ACDC call.

Electra ePBS

Prysm developer "Potuz" has proposed the rationale for "ePBS" in the next major Ethereum upgrade. "I don't think the problem we're facing on the mainnet is an immediate or minor one. The key issue is that we need to trust the relayers. We don't even know what the checks are. We don't even know what the fixes are. This is closed-source software, and the development is done in a black box," said Potuz, adding, "These are five relayers forwarding all of our blocks or 90% of them, and up to 10 players building these blocks. I think what we need to do is decide that this is a priority, and we shouldn't have a trusted player in Ethereum using closed-source software to make decisions, responsible for paying or not paying, refunding validators, or even deciding which transactions are audited or not. Once we make this a priority, then we can discuss whether there is a feasible design for ePBS."

Potuz urges developers to consider postponing the Electra fork to 2025 instead of 2024, and to use the "Interop event", which is likely to be the Ethereum core developer meeting in May 2024, to finalize the design of ePBS. Tsao said that ePBS is only "one solution to the problem." He emphasized that the builder API is an important software that does not "maintain incentive consistency" with the Ethereum protocol and needs to be updated. Sean from Lighthouse encourages developers to consider solutions other than ePBS, which fix relays in the Ethereum protocol to solve the problem of trust relays. Dankrad Feist, a researcher at the Ethereum Foundation, said that in his opinion, ePBS is a very significant change and should not be rushed. One of his main concerns about removing relays is the possibility of opening up validators to steal builder MEV. Currently, relays are not only trusted by validators, but also by builders. Builders trust that relays will not run their transactions ahead of time, and they may not have the same level of trust in validators, without proper protective barriers in the protocol.

Potuz objected to the view that ePBS is a major code change, stating that the current ePBS design has little to do with the engineering changes that include the list or maxEB. Danny Ryan interjected, saying, "Whenever I see this topic brought up, there are a lot of questions about what exactly we are optimizing for. What is the right end goal? There seem to be a lot of different opinions. First, including this decision is to figure out what the design is." To this end, Ryan suggested a group discussion to discuss the design of ePBS and see if developers can reach a consensus on its complexity and dependence on other code changes.

The ePBS group discussion will be held on February 13th at 9:00 AM Eastern Time (14:00 UTC).

Electra Inclusion Lists

Next, developers discussed EIP 7547, which includes a list. During ACDC #126, developers were not enthusiastic about incorporating the proposal into Electra. However, Ryan stated that since the last ACDC conference call, developers have expressed interest in discussing the proposal again. Ethereum Foundation researcher Mike Neuder stated that a simplified design containing a list has been created. He also pointed out a new document that details the possible inclusion list specification for clients. Ryan stated that he has reviewed these specifications and agrees that it is not as complicated as he initially thought. Sean agreed that the inclusion list may be able to be included in Electra, but in his opinion, maxEB is a more important code change. "I think now I am inclined to try to include both maxEB and the inclusion list, rather than the full ePBS," Sean said. He added that data availability sampling (DAS) can be done in parallel with these other changes.

Similar to ePBS, developers agree to discuss the inclusion list in a separate group conference call. The group conference call for the inclusion list will be held on February 16th at 9:00 AM Eastern Time (14:00 Coordinated Universal Time).