On February 1st, Ethereum core developers participated in the 180th All Core Developers Execution (ACDE) call, which discussed three important code changes: Dencun update, Prague proposal, and Verkle Ethereum Virtual Machine Object Format. This article is based on Christine Kim’s meeting summary “Ethereum All Core Developers Execution Call #180 Writeup,” compiled and translated by Block Beats.
Summary:
The ACDE call is held every two weeks and focuses on discussing and coordinating changes to the Ethereum Execution Layer (EL). In this 180th call, the main topics of discussion were the Verkle, Ethereum Virtual Machine Object Format (EOF), and History Expiry code changes. It was decided that Verkle would be scheduled after the Prague upgrade, specifically in the Osaka upgrade. Additionally, the latest developments regarding the Dencun upgrade, including the Sepolia and Holesky hard forks, as well as other related tests and issues, were discussed.
Developers conducted preliminary testing on Verkle and expressed concerns about its complexity, emphasizing the need for further research on its readiness for implementation on the mainnet. The EOF is planned to be activated on the mainnet during the fourth quarter of 2024, with Devcon serving as the launch event. Developers decided to postpone setting a mainnet activation date for the Dencun upgrade to address two unresolved issues. Lastly, 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 meeting’s highlights, translated as follows:
On February 1, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #180 meeting. ACDE calls are held biweekly and are supported by the Ethereum Foundation, with Tim Beiko as the host, discussing and coordinating changes to the Ethereum Execution Layer (EL). This week, 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 Osaka upgrade following the Prague upgrade. They also agreed to continue working on the development of the parallel network required for History Expiry, known as the Portal Network, while the Prague upgrade is ongoing. Regarding the upcoming Ethereum upgrade, Dencun, developers mentioned that they would discuss the mainnet activation date in the next ACDC call, scheduled for next Thursday.
Matt Nelson, a developer at Besu, provided a detailed overview 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. Nelson explained that the failure was caused by an error in the Bonsai state storage format used by Besu, specifically related to how Bonsai encodes state changes. An emergency fix for the Besu client has been released, and Nelson highlighted the diversity of EL clients during the January 6th incident. As Ethereum node operators also run other clients like Geth, Nethermind, and Erigon, the failure of Besu nodes did not significantly impact network health or disrupt network activity.
Parithosh Jayanthi, DevOps engineer at the Ethereum Foundation (EF), shared the latest updates on the Sepolia hard fork, which occurred on Tuesday, January 30th. Jayanthi stated, “It was a smooth fork. We saw finalization on the network, and the data blocks appeared exactly where we wanted them.” Beiko reminded the team that the Holesky hard fork is planned for next Wednesday, February 7th. Holesky will be the last public Ethereum testnet upgrade before the mainnet upgrade.
Regarding the Dencun upgrade, Nethermind developer Łukasz Rozmej mentioned that their team is investigating an error in their client causing excessive growth of the blob memory pool beyond the specified limit. During further investigation into Devnet-12, the Nethermind team sent a large number of blob transactions to the network and noticed a decrease in validator participation by more than 20% due to this bug. The team plans to send blob transactions on the Goerli testnet in the next steps. Barnabas Busa, DevOps engineer at the Ethereum Foundation (EF), requested the Nethermind team to wait for an increase in churn limit on Goerli before conducting blob spam.
Apart from Nethermind’s error, Prysm developer “Potuz” mentioned that his team is investigating abnormal behavior related to a late block proposal in Sepolia, which did not include any blob transactions.
Due to the need for further investigation into these two unresolved issues related to the Dencun upgrade, they agreed to temporarily postpone setting a mainnet activation date until the next ACD call, scheduled for Thursday, 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.
For most of the call, developers discussed the implementation details of the three major 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 data is stored and retrieved. They emphasized areas that still require research in the upgrade, such as Verkle synchronization and gas plan updates. Based on preliminary testing, they estimated that transitioning to Verkle would take about two weeks and slow down transaction execution time by approximately 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 code changes in the Prague upgrade. Ballet agreed that Verkle might not be ready for implementation in Prague, but he worried that if Verkle is not scheduled for an upgrade, either in Prague or Osaka, client teams would have less incentive to develop it. Ballet stated that Ethereum’s state grows by approximately 25% annually, and the longer developers wait to implement Verkle on the mainnet, the more legacy data that needs improvement during the Verkle transition period.
“In my view, it will take over a year to deliver,” said Rozmej.
– EOF: Danno Ferrin, Chief Software Engineer at Swirlds Labs, shared the latest progress on EOF development, a series of code changes to the Ethereum Virtual Machine (EVM) that were previously delayed in the Shanghai and Cancun upgrades. “We are in ‘delivery’ mode. We are trying to close as many doors of specification possibilities as possible,” said Ferrin. The team responsible for EOF development has started creating an implementation matrix, assessing the final state of Ethereum Improvement Proposals (EIPs) related to EOF and completing corresponding reference tests.
They plan to activate EOF on the testnet in the third quarter of 2024 and on the mainnet during the Devcon event in the fourth quarter of 2024. “I think these fundamental changes are essential for addressing much of the technical debt of the EVM in the coming years. All the complaints about ‘we can’t increase code size’ and such issues get resolved in the way EOF works,” Ferrin said. Andrew Ashikhmin, a developer at Erigon, expressed support for including EOF in Prague. Ballet stated 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. Dragan Rakita, a developer at Reth, believed there might not necessarily be a dependency between the two and added, “Overall, EOF seems more suitable for Verkle tracking rather than traditional EVM.”
– History Expiry: Kolby Moroz Liebl, a developer at the Ethereum Foundation, introduced History Expiry. According to EIP 4444, History Expiry means that Execution Layer (EL) clients will stop providing historical block headers, bodies, and receipts on the peer-to-peer layer after a certain period, such as one year. Instead, these data will be provided to users through a decentralized alternative network called the Portal Network. Liebl has released an FAQ document about Portal.
Regarding the tools required to enable History Expiry, “Lightclient,” a developer at Geth, stated, “We really just need to keep going with the spec and start trying to get providers to provide this data because the spec itself, exporting data, verifying data, importing data, all works, but we can’t actually start deleting the data through the P2P network until the data is available.” Lightclient added that developers should wait for about a year after the data is available on the Portal and provided by data providers on the network before stopping the service of providing this data on the Ethereum P2P layer. While updating historical block data provision on the P2P layer does not require a hard fork, it will be an update that client teams want 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 client teams to start researching EIP 4444 immediately, as it does not require significant changes to the core Ethereum protocol and has significant benefits in reducing data load on Ethereum nodes. Lightclient stated that they would collaborate with Nethermind and Besu client teams to kickstart the work on History Expiry.
Ashikhmin noted that from the Erigon team’s perspective, the implementation of History Expiry would 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 the 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 for the Osaka upgrade. There were no objections. Ansgar Dietrichs, a researcher at the Ethereum Foundation, suggested keeping the scope of the Osaka upgrade flexible, considering it might be over a year away, and further research on Verkle is still needed to assess its readiness for implementation on the mainnet.
In the final minutes of the call, Beiko briefly introduced the last three agenda items for ACDE#180.
– Engine API to enforce specified client versions #517: This is an open PR aimed at improving the tracking of Execution Layer (EL) client usage by validator node operators. Currently, due to most validators using MEV-Boost software, it is not possible to determine the EL client type used by analyzing block data. Therefore, accurate reporting of EL client diversity requires node operators to report it themselves. The PR suggests embedding the client and version used for execution in the “graffiti” field of the node. 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 the Ethereum testnet. 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 Precompile Address Range: As discussed in ACDE#178, developers plan to reserve a set of precompile addresses for Layer-2 rollup teams. The EIP to reserve a precompile 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 focus will be on further determining the scope of the Prague upgrade.