On February 1st, Ethereum core developers participated in the 180th All Core Developers Execution (ACDE) call, discussing three important code changes: Dencun update, Prague proposal, and Verkle Ethereum Virtual Machine Object Format. This article is sourced from Christine Kim’s meeting summary “Ethereum All Core Developers Execution Call #180 Writeup,” compiled and translated by Block Beats.
Table of Contents:
– Besu January 6th Mainnet Incident
– Dencun Update
– Prague Proposal
– Other Matters
The Ethereum All Core Developers Consensus Call (ACDE) is held every two weeks to discuss and coordinate changes to the Ethereum execution layer (EL). The 180th call focused on three important code changes: Verkle, Ethereum Virtual Machine Object Format (EOF), and history expiry. It was decided to schedule Verkle after the Prague upgrade, specifically in the Osaka upgrade. In addition, the latest developments on the Dencun upgrade were discussed, including the Sepolia and Holesky hard forks and other testing and issues related to Dencun.
Developers conducted preliminary testing on Verkle and expressed concerns about its complexity, emphasizing the need for further research on its implementation on the mainnet. The EOF is planned to be activated on the mainnet during the fourth quarter of 2024, during Devcon. Developers decided to postpone setting the mainnet activation date for the Dencun upgrade to ensure the resolution of two unresolved issues. Lastly, the meeting briefly mentioned proposals such as EIP-7523, EIP-7587, and further planning for the Prague upgrade.
Galaxy Digital’s Vice President of Research, Christine Kim, provided detailed notes on the key points of the meeting, which are translated as follows:
On February 1, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #180 meeting. The ACDE call is a bi-weekly series of meetings supported by the Ethereum Foundation, chaired by Tim Beiko, the Protocol Support Manager, where developers discuss and coordinate changes to the Ethereum execution layer (EL). This week, the developers mainly discussed three important code changes: Verkle, Ethereum Virtual Machine Object Format (EOF), and history expiry. They decided to schedule Verkle for implementation in the EL upgrade after the Prague upgrade, known as the Osaka upgrade. They also agreed to continue working on the development of the parallel network required for history expiry, called the Portal Network, while the Prague upgrade is ongoing. Regarding the upcoming Ethereum upgrade, Dencun, developers stated that they will discuss the activation date of the upgrade at the next ACDC call on Thursday next week.
Besu developer Matt Nelson provided a detailed account of the approximately 70% Besu node failures that occurred on Ethereum earlier this year. The Besu team shared a detailed post-analysis of the incident on their blog, explaining that the failure was caused by an error in the Bonsai state storage format used by Besu, specifically in how Bonsai encodes state changes. An emergency fix for the Besu client has been released, and Nelson praised the diversity of EL clients seen during the January 6th incident. As Ethereum node operators also run other clients such as Geth, Nethermind, and Erigon, the Besu node failures did not significantly impact the network’s health or disrupt network activity.
Parithosh Jayanthi, a developer operations engineer at the Ethereum Foundation, shared the latest updates on the Sepolia hard fork, which occurred on Tuesday, January 30th. Jayanthi stated, “It was a smooth fork. We saw the final confirmations on the network, and the data blocks appeared where we expected them.” 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 mainnet. Regarding the Dencun upgrade, in addition to the unresolved issues requiring further testing, Nethermind developer Łukasz Rozmej mentioned that their team is investigating an error in their client that causes the blob memory pool to grow beyond the specified limit. Further investigation on Devnet-12 revealed that the team sent a large number of blob transactions to the network and noticed a decrease in validator participation of over 20% due to this bug. The team plans to send blob transactions on the Goerli testnet in the next steps. Barnabas Busa, a developer operations engineer at the Ethereum Foundation, requested that the Nethermind team wait for an increase in churn limits on Goerli before performing blob spamming.
Aside from Nethermind’s error, Prysm developer “Potuz” mentioned that his team is investigating abnormal activity related to a late block proposal in Sepolia that does not include any blob transactions.
Due to the need for further investigation of these two unresolved issues related to Dencun, it was agreed to temporarily postpone the mainnet activation date of the upgrade until the next ACD call, planned for Thursday next week, February 8th. Potuz added that he would like to receive more feedback on the Dencun upgrade from the Layer2 Rollup team before its activation on the mainnet. Beiko agreed with this suggestion.
During most of the call, the developers discussed the implementation details of the three main code changes: Verkle, EOF, and history expiry.
– Verkle: Ethereum Foundation researchers Joshua Rudolf and Guillaume Ballet presented their latest work on Verkle, a significant reform of how Ethereum stores and retrieves data. They emphasized areas that still need research in the upgrade, such as Verkle synchronization and gas cost updates. Based on preliminary testing, they estimated that the transition to Verkle would take approximately two weeks and slow down transaction execution time by about 10%. Rozmej commented that these preliminary tests should be taken with caution as they have not been tested through a more comprehensive 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 committing to releasing code changes in the Prague upgrade. Ballet agreed that Verkle may not be ready for implementation in Prague, but he worried that if Verkle is not planned for an upgrade, whether it’s Prague or Osaka, client teams will have less motivation to develop it. Ballet mentioned that Ethereum’s state grows by approximately 25% annually, and the longer developers wait to implement Verkle on the mainnet, the more outdated data that needs significant improvement during the Verkle transition.
“In my opinion, it will take over a year to deliver,” said Rozmej.
– EOF: Danno Ferrin, the Chief Software Engineer at Swirlds Labs, shared the latest progress on the development of EOF, a series of code changes to the Ethereum Virtual Machine (EVM) that had been postponed in previous upgrades like Shanghai and Cancun. “We are in ‘delivery’ mode. We are trying to close as many doors as possible in terms of spec possibilities,” Ferrin said. The team responsible for EOF development has started creating an implementation matrix to assess the final status of Ethereum Improvement Proposals (EIPs) related to EOF and complete the corresponding reference tests.
They plan to activate EOF on the testnet in the third quarter of 2024 and aim to activate it on the mainnet during Devcon in the fourth quarter of 2024. “I think, in the next few years, these foundational changes are crucial for addressing a lot of the technical debt around the EVM. All the complaints about ‘we can’t grow the code size’ and stuff like that are solved in the way EOF works,” Ferrin said. Erigon developer Andrew Ashikhmin expressed support for including EOF in Prague. Ballet mentioned that he would like to see EOF running on the Verkle-enabled testnet first to understand how these two upgrades will interact with each other. Reth developer Dragan Rakita stated that he doesn’t necessarily see a dependency between the two and added, “Overall, EOF seems more suited for tracking Verkle rather than traditional EVM.”
– History Expiry: Kolby Moroz Liebl, a developer at the Ethereum Foundation, introduced history expiry. According to the definition of EIP 4444, history expiry means that execution layer (EL) clients will stop providing historical block headers, bodies, and receipts at the peer-to-peer layer after a certain period, such as one year. Instead, these data will be provided to users through a decentralized network called the Portal Network. Liebl has released an FAQ document on Portal.
Regarding the tools needed for launching history expiry, Geth developer “Lightclient” said, “We really just need to keep doing the spec work and start trying to get providers to provide that data because the spec itself, exporting data, validating data, importing data, are all good, but we can’t actually go ahead and delete the data through 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 for approximately a year before ceasing to provide these data services in the Ethereum P2P layer. While updating the provision of historical block data on the P2P layer does not require a hard fork, it will be an update that client teams aim to implement consistently, most likely through an upgrade to the Ethereum Wire Protocol.
After discussing the three main code changes, the developers discussed how to schedule their implementation on the mainnet. Lightclient encouraged client teams to start researching EIP 4444 immediately since it does not require significant changes to the Ethereum core protocol and has significant benefits in reducing data load for Ethereum node operators. Lightclient stated that he would work with the Nethermind and Besu client teams to kickstart the preliminary work on history expiry.
Ashikhmin pointed out that from the Erigon team’s perspective, the implementation of history expiry will have to wait for several months until their Erigon V3 version is released because their client currently does a re-execution of blocks starting from the Ethereum genesis, requiring access to all historical block data to complete this process. Ashikhmin added that he is more inclined to include EOF in Prague, but if it has compatibility issues with Verkle, he would remove it from the upgrade.
Beiko asked if anyone opposed scheduling Verkle in the Osaka upgrade. There were no objections. Ethereum Foundation researcher Ansgar Dietrichs suggested keeping the scope of the Osaka upgrade flexible, considering a possible timeframe of over a year, as further research is still needed on Verkle to accurately assess its readiness for implementation on the mainnet.
In the last few minutes of the call, Beiko briefly introduced the final three agenda items of ACDE#180.
– Engine API Execution Specifying Client Version #517: This is an open PR aimed at improving the tracking of EL client usage 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 analyzing block data. Therefore, accurate reporting of EL client diversity requires node operators to report it themselves. The PR proposes embedding the client and version used for execution in the “graffiti” field of nodes by default. This practice has already been implemented by some CL clients. Beiko encouraged client teams to review this PR and provide their feedback.
– EIP-7523 Empty Account Abolition: As discussed in ACDE#173, there is an EIP aimed at reducing technical debt caused by empty accounts on Ethereum test networks. Paweł Bylica, a developer at the Ethereum Foundation, raised questions about the next steps for this EIP. Beiko encouraged Bylica to share these questions on the Ethereum R&D Discord channel.
– EIP-7587 Reserved Precompiled Address Range for RIPs: As discussed in ACDE#178, developers are planning to reserve a set of precompiled addresses for Layer-2 rollup teams. The EIP to reserve a precompiled address range for rollups is entering the “last call” stage. Beiko encouraged developers to provide any last-minute comments or objections to the EIP during this stage.
For the next ACDE call, Beiko stated that the developers will focus on further solidifying the scope of the Prague upgrade.