Summary of the latest meeting of Ethereum core developers: Dencun update, Prague proposal

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

Original author: Christine Kim

Original compilation: Luccy, BlockBeats

Editor's note:

The All Core Ethereum Developers Consensus Call (ACDE) is held every two weeks to discuss and coordinate changes to the Ethereum Execution Layer (EL). This is the 180th ACDE conference call. This conference mainly discussed three important code changes: Verkle, Ethereum Virtual Machine Object Format (EOF) and historical expiration. They decided to place Verkle after Prague's upgrade, which is Osaka. Additionally, the latest developments in Dencun upgrades are discussed, including the Sepolia and Holesky hard forks, as well as other Dencun-related tests and issues.

Developers conducted preliminary testing of Verkle and raised some concerns about its complexity, emphasizing research into its readiness for mainnet implementation. EOF plans to conduct mainnet activation during Devcon in the fourth quarter of 2024. The developers decided to delay setting 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, EIP-7587, and further planning for Prague upgrades.

Christine Kim, Vice President of Research at Galaxy Digital, recorded the key points of this meeting in detail. BlockBeasts compiled the original text as follows:

On February 1, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call#180meeting. The ACDE Conference Call is a biweekly series of meetings hosted by Tim Beiko, Head of Protocol Support at the Ethereum Foundation, where developers discuss and coordinate changes to the Ethereum Execution Layer (EL). This week, developers focused on three important code changes: Verkle, Ethereum VM Object Format (EOF), and history invalidation. They decided to implement Verkle in the EL upgrade after the Prague upgrade, the Osaka upgrade. At the same time, they also agreed to continue working on developing the parallel network required for history failure, known as the Portal Network, while Prague is being upgraded. Regarding the next upcoming Ethereum upgrade, Dencun, the developers said they will discuss the upgrade’s mainnet activation date during the ACDC conference call next Thursday.

Besu mainnet event on January 6

Besu developer Matt Nelson detailed an outage of approximately 70% of Besu nodes that occurred on Ethereum earlier this year. The Besu team shared a detailed postmortem of the incident on their blog. Nelson explained that the glitch was caused by a bug in Besu's Bonsai state storage format, specifically, an issue with how Bonsai encodes state changes. An emergency fix for the Besu client has been rolled out, with Nelson highlighting his appreciation for the diversity of EL clients involved in the January 6 incident. Since the Ethereum node operator also runs other clients such as Geth, Nethermind, and Erigon, the failure of the Besu node did not materially affect network health or interfere with network activity.

Dencun Updates

Parithosh Jayanthi, DevOps Engineer at the Ethereum Foundation (EF), shared an update on the Sepolia hard fork, which took place on Tuesday, January 30. "It was a smooth fork. We saw final confirmation of the network and the blocks were exactly where we wanted them to be," Jayanthi said. Beiko reminded the team that the Holesky hard fork is scheduled for next Wednesday, February 7 activation. Holesky will be the last public Ethereum testnet to be upgraded before the Ethereum mainnet.

Regarding the issue of Dencun upgrades requiring further testing beyond the Holesky fork, Nethermind developer Łukasz Rozmej said that their team is investigating a bug in their client that caused the blob memory pool to grow beyond the specified limit. While investigating further on Devnet-12, the Nethermind team sent a large number of blob transactions to the network and noticed that validator participation dropped by more than 20% due to this bug. The team plans to send blob transactions to the Goerli test network in the next steps. Barnabas Busa, DevOps Engineer at the Ethereum Foundation (EF), asked the Nethermind team to wait to test the churn limit increase on Goerli before proceeding with blob spam.

In addition to Nethermind's bug, Prysm developer "Potuz" said his team is investigating unusual activity regarding a late block proposal from Sepolia that did not contain any blob transactions.

As the developers need to investigate these two outstanding issues related to Dencun, they have agreed to hold off on the upgrade's mainnet activation date until the next ACD call, which is scheduled for next Thursday, February 8 . Potuz added that he hopes to get more feedback from the Layer2 Rollup team on the Dencun upgrade before mainnet activation. Beiko agrees.

Prague suggestion

For much of the call, the developers discussed implementation details of three major code changes: Verkle, EOF, and history invalidation.

· Verkle: Ethereum Foundation researchers Joshua Rudolf and Guillaume Ballet presented their latest work on Verkle, a major overhaul of how Ethereum data is stored and retrieved. They highlighted areas that still need research in the upgrade, such as Verkle synchronization and gas plan updates. Based on preliminary testing, they estimate that switching to Verkle will take about two weeks and slow down transaction execution times by about 10%. Rozmej commented that these preliminary tests should be “taken with a grain of salt” as they have not yet been tested with a more complete shadow fork of the mainnet.

Rozmej and other developers expressed concerns about committing to releasing code changes in the Prague upgrade due to Verkle's complexity and the need for more research into its implementation. Ballet agrees that Verkle likely won't be ready for implementation in Prague, but he worries that if Verkle isn't planned as an upgrade, whether it's Prague or Osaka, client teams won't have much incentive to develop it. Ballet said the state of Ethereum is growing roughly 25% per year, and the longer developers wait to implement Verkle on mainnet, the more old data will need to be overhauled during the Verkle transition.

"In my opinion, delivery will take more than a year," Rozmej said.

· EOF: Danno Ferrin, principal software engineer at Swirlds Labs, shared an update on the development of EOF, a series of code changes to the Ethereum Virtual Machine (EVM) that developers had delayed incorporating into previous Shanghai and Cancun upgrades . "We've gone into 'delivery' mode. We're trying to close the door as much as possible on all the normative possibilities that exist," Ferrin said. The team responsible for EOF development has begun developing an implementation matrix to evaluate the final status of Ethereum Improvement Proposals (EIPs) related to EOF and complete corresponding reference testing.

They plan to activate EOF on the test network in Q3 2024 and hope to activate mainnet during Devcon in Q4 2024. "I think these fundamental changes will be critical to solving a lot of the technical debt of the EVM over the next few years. All the complaints about 'we can't increase the code size' etc. are met in the way EOF works. It's solved," Ferrin said. Erigon developer Andrew Ashikhmin expressed support for including EOF in Prague. Ballet said he first wants to see EOF running on a Verkle-activated test network to understand how the two upgrades will impact each other. Reth developer Dragan Rakita said he doesn't think there is necessarily a dependency between the two, adding: "Overall, EOF seems to be more suitable for Verkle tracking than traditional EVM."

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

Regarding the tools needed to enable historical invalidation, Geth developer "Lightclient" said: "We really just need to continue to implement the specification and start trying to get providers to provide this data, because the specification itself, exporting data, verifying data, importing data are all very complicated. OK, but we can't actually continue deleting data over the P2P network until the data is available." Lightclient added that once the data is available on the Portal and served by data providers on the network, developers should wait about a year before stopping. Services for these data are provided in the P2P layer of Ethereum. While the update to provide historical block data on the P2P layer will not require a hard fork, it will be an update that the client team hopes to complete unanimously, most likely through an upgrade to the Ethereum Wire Protocol.

After discussing the three major code changes, the developers discussed how to schedule their implementation on mainnet. Lightclient encourages client teams to start working on EIP 4444 immediately as it does not require significant changes to Ethereum’s core protocol and has significant benefits in reducing the data load on Ethereum nodes. Lightclient said it will work with the Nethermind and Besu client teams to initiate preliminary work on history invalidation.

Ashikhmin noted that from the Erigon team's perspective, the implementation of history invalidation will have to wait a few months until their Erigon V3 release, as their clients currently re-execute blocks from Ethereum origin, so Access to all historical block data is required to complete this process. Ashikhmin added that he would prefer to include EOF in Prague, but if it has compatibility issues with Verkle, he will remove it from the upgrade.

Beiko asked if there was any objection to Verkle being included in the Osaka promotion. No objections. Ethereum Foundation researcher Ansgar Dietrichs suggested remaining flexible on the scope of the Osaka upgrade, which could be more than a year away. Verkle still needs further research to properly assess its readiness for mainnet implementation.

something else

In the final minutes of the call, Beiko briefly outlined the final three agenda items for ACDE #180.

Execution in Engine API Specify Client Version #517: This is an open PR designed to improve execution layer (EL) client tracking used by validator node operators. Currently, since most validators use MEV-Boost software, there is no way to determine the type of EL client used by a node operator by analyzing block data. Therefore, accurate reporting of EL client diversity requires self-reporting by node operators. This PR proposes embedding the client and version used to run the node by default in the node's "graffiti" field. This is a practice that some CL clients already implement. Beiko encourages client teams to review this PR and have their say.

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

EIP-7587 Reserve precompiled address ranges for RIP: As discussed on ACDE#178, the developers plan to reserve a set of precompiled addresses for the Layer-2 rollup team. EIPs that reserve precompiled address ranges for rollups are entering the "last call" phase. Beiko encourages developers to raise any last-minute comments or objections to the EIP at this stage.

For the next ACDE call, Beiko said the developers will focus on further defining the scope of the Prague upgrade.

标签：core CORE THE