Summary of the latest Ethereum core developer meeting: Dencun update and Prague proposal.

2024-02-02 10:50

Read this article in 17 Minutes

On February 1st, all core developers of Ethereum participated in the 180th All Core Developers Execution (ACDE) conference call.

Original Title: "Ethereum All Core Developers Execution Call #180 Writeup"

Author: Christine Kim

Translation: Luccy, BlockBeats

Editor's Note:

The Ethereum All Core Developers Execution (ACDE) call is held every two weeks to discuss and coordinate changes to the Ethereum Execution Layer (EL). This was the 180th call, and the main topics discussed were three important code changes: Verkle, Ethereum Object Format (EOF), and Historical Expiration. They decided to schedule Verkle after the Prague upgrade, which is Osaka. In addition, they discussed the latest developments in the Dencun upgrade, including the Sepolia and Holesky hard forks, as well as other tests and issues related to Dencun.

The developers conducted preliminary testing on Verkle and expressed some concerns about its complexity, emphasizing the need for research on its readiness for implementation on the mainnet. EOF is planned to be activated on the mainnet during Devcon in Q4 2024. The developers decided to postpone the mainnet activation date for the Dencun upgrade to ensure that two unresolved issues are addressed. Finally, the meeting briefly mentioned proposals such as EIP-7523 and EIP-7587, as well as further planning for the Prague upgrade.

Christine Kim, Vice President of Research at Galaxy Digital, provided a detailed record of the key points of this meeting, which BlockBeats has translated from the original article:

On February 1, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #180 meeting. The ACDE conference is a bi-weekly series of meetings supported by the Ethereum Foundation protocol lead Tim Beiko, where developers discuss and coordinate changes to the Ethereum execution layer (EL). This week, developers mainly discussed three important code changes: Verkle, Ethereum Object Format (EOF), and historical invalidation. They decided to implement Verkle in the EL upgrade after the Prague upgrade, which is the Osaka upgrade. At the same time, they also agreed to continue developing the parallel network required for historical invalidation, called the Portal Network, during the Prague upgrade. Regarding the upcoming Ethereum upgrade, Dencun, developers stated that they will discuss the mainnet activation date of the upgrade at the ACDC conference call next Thursday.

Besu January 6th Mainnet Incident

Besu developer Matt Nelson detailed the approximately 70% Besu node failure that occurred earlier this year on Ethereum. The Besu team shared a detailed post-mortem analysis of the incident on their blog. Nelson explained that the failure was caused by an error in Besu's Bonsai state storage format, specifically how Bonsai encoded state changes. An emergency fix has been released for the Besu client, and Nelson emphasized his appreciation for the diversity of EL clients in the January 6th incident. As Ethereum node operators also run other clients such as Geth, Nethermind, and Erigon, the failure of Besu nodes did not materially impact network health or disrupt network activity.

Dencun Update

The latest update on the Sepolia hard fork was shared by Parithosh Jayanthi, a developer and operations engineer at the Ethereum Foundation (EF). The fork occurred on Tuesday, January 30th. Jayanthi stated, "This was a smooth fork. We saw finality on the network and blocks appearing where we expected them to." Beiko reminded the team that the Holesky hard fork is planned for next Wednesday, February 7th. Holesky will be the final public Ethereum testnet upgrade before the Ethereum mainnet.

Regarding the issue of further testing for Dencun upgrade besides the Holesky fork, Nethermind developer Łukasz Rozmej stated that their team is investigating an error in their client that causes the growth of blob memory pool to exceed the specified limit. During further investigation of Devnet-12, the Nethermind team sent a large number of blob transactions to the network and noticed that due to this bug, the participation rate of validators decreased by more than 20%. The team plans to send blob transactions to the Goerli test network in the next step. Barnabas Busa, the developer operations engineer of the Ethereum Foundation (EF), requested that the Nethermind team wait to test the increase of churn limit on Goerli before sending blob spam.

Except for errors from Nethermind, Prysm developer "Potuz" stated that his team is investigating abnormal activity regarding a late block proposal for Sepolia, which did not include any blob transactions.

Due to the developer's need to investigate the two unresolved issues related to Dencun, they agreed to temporarily postpone the activation date of the upgraded mainnet until the next ACD conference call, which is scheduled for Thursday, February 8th. Potuz added that he hopes to receive more feedback on the Dencun upgrade from the Layer2 Rollup team before the mainnet activation. Beiko agreed with this.

Prague Proposal

During most of the conversation, developers discussed the implementation details of three main code changes: Verkle, EOF, and historical invalidation.

· Verkle: Joshua Rudolf and Guillaume Ballet, researchers at the Ethereum Foundation, presented their latest work on Verkle, a major reform of Ethereum's data storage and retrieval methods. They emphasized areas that still need research in the upgrade, such as Verkle synchronization and gas plan updates. Based on preliminary tests, they estimate that the transition to Verkle will take about two weeks and slow down transaction execution time by about 10%. Rozmej commented that these preliminary tests should be "cautious" as they have not yet been tested through a more complete mainnet shadow fork.

Due to the complexity of Verkle and the need for further research on its implementation, Rozmej and other developers expressed concerns about the promised code changes in the Prague upgrade. Ballet agrees that Verkle may not be ready for implementation in Prague, but is concerned that if Verkle is not planned for the upgrade, there will be little incentive for client teams to develop it, whether in Prague or Osaka. Ballet states that the Ethereum state grows by approximately 25% each year, and the longer developers wait to execute Verkle on the mainnet, the more old data that needs to be thoroughly improved during the Verkle transition period.

"In my opinion, it will take more than a year to deliver," Rozmej said.

· EOF: Danno Ferrin, the Chief Software Engineer of Swirlds Labs, shared the latest progress on the development of EOF, a series of code changes to the Ethereum Virtual Machine (EVM), which was previously delayed from the Shanghai and Cancun upgrades. "We are now in 'delivery' mode. We are trying to close as many doors as possible to existing specification possibilities," Ferrin said. The team responsible for EOF development has begun to develop an implementation matrix, evaluate the final status of Ethereum Improvement Proposals (EIPs) related to EOF, and complete corresponding reference tests.

They plan to activate EOF on the test network in the third quarter of 2024 and hope to activate the main network during Devcon in the fourth quarter of 2024. "I think these fundamental changes are crucial for addressing many technical debts of EVM in the coming years. All complaints about issues such as 'we cannot increase code size' have been addressed in the way EOF works," said Ferrin. Erigon developer Andrew Ashikhmin supports including EOF in Prague. Ballet said he would like to see EOF run on the Verkle test network first to understand how these two upgrades will interact. Reth developer Dragan Rakita said he does not necessarily believe there is a dependency between the two and added, "Overall, EOF seems more suitable for Verkle tracking than traditional EVM."

· History Expiry: Kolby Moroz Liebl, a developer at the Ethereum Foundation, introduced the concept of History Expiry. According to the definition in EIP 4444, History Expiry means that the Execution Layer (EL) client will stop providing historical block headers, block bodies, and receipts on the peer-to-peer layer after a certain period of time, such as one year. Instead, these data will be provided to users through a decentralized network called the Portal Network. Liebl has published an FAQ document about Portal here.

Regarding the tools needed to initiate historical invalidation, "Lightclient," a Geth developer, stated: "We really just need to continue to follow the specification and start trying to get providers to offer this data, because the specification itself, exporting data, validating data, importing data, is all good, but we can't actually continue to delete data over the P2P network until the data is available." Lightclient added that once the data is available on the Portal and provided by data providers on the network, developers should wait about a year before stopping the service of providing this data on the Ethereum P2P layer. Although updating historical block data on the P2P layer does not require a hard fork, this will be an update that client teams hope to complete consistently, most likely through an upgrade to the Ethereum Wire Protocol.

After discussing the three main code changes, developers discussed how to schedule their implementation on the mainnet. Lightclient encouraged the client team to immediately start researching EIP 4444, as it does not require major changes to Ethereum's core protocol and has significant benefits for reducing the data load on Ethereum nodes. Lightclient stated that he will work with the Nethermind and Besu client teams to initiate preliminary work on historical invalidation.

Ashikhmin pointed out that from the perspective of the Erigon team, the implementation of historical invalidation will have to wait for several months until their Erigon V3 version is released, because their client currently re-executes blocks from the Ethereum origin, requiring access to all historical block data to complete this process. Ashikhmin added that he prefers to include EOF in Prague, but if it has compatibility issues with Verkle, he will remove it from the upgrade.

Beiko asked if anyone objected to including Verkle in the Osaka upgrade. There were no objections. Ansgar Dietrichs, a researcher at the Ethereum Foundation, suggested keeping the scope of the Osaka upgrade flexible, possibly for over a year, and further research is still needed on Verkle to properly assess its readiness for implementation on the mainnet.

Other Matters

During the last few minutes of the call, Beiko briefly introduced the last three agenda items of ACDE#180.

Execution API specified client version #517: This is an open PR aimed at improving the EL client tracking used by validator node operators. Currently, due to most validators using MEV-Boost software, it is not possible to determine the type of EL client used by node operators by analyzing block data. Therefore, accurate reporting of EL client diversity requires node operators to report it themselves. This PR proposes to embed the client and version used to run the node in the "graffiti" field of the node by default. This is a practice that some CL clients have already implemented. Beiko encourages client teams to review this PR and express their opinions.

EIP-7523 Account Abstraction: As discussed in ACDE#173, there is an EIP aimed at reducing technical debt caused by empty accounts on the Ethereum test network. Ethereum Foundation developer Paweł Bylica has raised questions about this EIP's next steps. Beiko encourages Bylica to share these questions in the Ethereum R&D Discord channel.

EIP-7587 reserves precompiled address range for RIP: As discussed in ACDE#178, developers plan to reserve a set of precompiled addresses for Layer-2 rollup teams. The EIP that reserves the precompiled address range for rollups is entering its "last call" stage. Beiko encourages developers to provide any last-minute comments or objections to the EIP.