Ethereum All Core Developers Execution Call #180 Writeup
On February 1, 2024, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) Call #180. Chaired by Ethereum Foundation (EF) Protocol Lead Tim Beiko, the ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers primarily discussed the details of three major code changes: Verkle, Ethereum Virtual Machine Object Format (EOF), and history expiry. They agreed to schedule Verkle for implementation in the EL upgrade after Prague, dubbed Osaka. They also agreed to continue working on the parallel network needed for history expiry known as the Portal Network in parallel to efforts for Prague. Regarding the next immediate Ethereum upgrade, Dencun, developers said that they would discuss mainnet activation dates for the upgrade during next Thursday’s ACDC call.
Besu Jan 6 Mainnet Event
Besu developer Matt Nelson shared details about an outage of roughly 70% of Besu Ethereum nodes on Ethereum in early January. A full postmortem about the event has been shared by the Besu team on their blog. Nelson explained that the outage was due to a bug in Besu’s Bonsai state storage format, specifically, how Bonsai encoded state changes. A hotfix to the Besu client has been rolled out and Nelson emphasized his appreciation for EL client diversity through the event on January 6. Because a diversity of other clients such as Geth, Nethermind, and Erigon, are being run by Ethereum node operators, the outage of Besu nodes did not materially impact network health or disrupt network activity.
Dencun Updates
EF Developer Operations engineer Parithosh Jayanthi shared an update on the Sepolia hard fork, which occurred on Tuesday, January 30. Jayanthi said, “It was an uneventful fork. We saw [network] finality, as well as blobs showing up exactly where we wanted them to.” Beiko reminded teams that the Holesky hard fork is scheduled to activate next Wednesday, February 7. Holesky will be the last public Ethereum testnet to be upgraded before Ethereum mainnet.
Regarding further testing needed for the Dencun upgrade aside from the Holesky fork, Nethermind developer Łukasz Rozmej said that his team is investigating a bug in their client that caused the blob mempool to grow beyond its specified limits. During further investigation on Devnet-12, the Nethermind team spammed the network with blob transactions and noticed that validator participation rates dropped by over 20% due to this bug. The team is planning on spamming the Goerli testnet with blob transactions as a next step. EF Developer Operations engineer Barnabas Busa requested that the Nethermind team wait until the churn limit increase is tested on Goerli before moving ahead with blob spam.
In addition to the Nethermind bug, Prysm developer “Potuz” said that his team is investigating unusual activity regarding a late block proposal on Sepolia that did not include any blob transactions.
Because of these two outstanding items that developers need to investigate related to Dencun, developers agreed to hold off from setting a mainnet activation date for the upgrade until the next ACD call, which is scheduled for next Thursday, February 8. Potuz added that he would like to see more feedback on the Dencun upgrade from Layer-2 rollup teams before mainnet activation. Beiko agreed.
Prague Proposals
For most of the call, developers discussed the implementation details of three major code changes: Verkle, EOF, and history expiry.
1. Verkle – EF Researchers Joshua Rudolf and Guillaume Ballet presented their latest work on Verkle, which is a major overhaul to the way data is stored and retrieved on Ethereum. They highlighted areas of the upgrade that still need research, such as the Verkle sync and gas schedule updates. Based on preliminary tests, they estimate that the conversion to Verkle will take roughly two weeks and make transaction execution times about 10% slower. Rozmej commented that these preliminary tests should be taken “with a grain of salt” as they have yet to be tested through a more fully-fledged mainnet shadow fork.
Because of the complexity of Verkle and the need for more research about its implementation, Rozmej and other developers expressed concerns about committing to shipping the code changes for the Prague upgrade. Ballet agreed that Verkle would not likely be ready for implementation in Prague but expressed concerns that if Verkle is not scheduled for an upgrade, either Prague or Osaka, then client teams would have little motivation to work on it at all. Ballet said that the Ethereum state grows by roughly 25% per year and the longer developers wait to execute Verkle on mainnet, the more legacy data there is to overhaul during the Verkle transition.
“It’s still way over a year to deliver in my opinion,” said Rozmej.
2. EOF – Principal Software Engineer at Swirlds Labs Danno Ferrin shared updates on the development of EOF, which is a bundle of code changes to the Ethereum Virtual Machine (EVM) that developers had punted from inclusion in the prior Shanghai and then Cancun upgrades. “We’ve been moving into ‘ship it’ mode. We’re trying to close the door on as many of the spec possibilities that are out there,” said Ferrin. Developers working on EOF have started an implementation matrix to assess the final statuses of EOF-related Ethereum Improvement Proposals (EIPs) and finalize their corresponding reference tests.
They are targeting Q3 2024 for activation of EOF on testnets for a hopeful mainnet activation during Devcon in Q4 2024. “I feel that these fundamental changes for fixing a lot of the technical debt of the EVM is kind of existential for the EVM in the next couple of years. All the complaints we see about things like, ‘We can’t increase the code size,’ these fundamental problems are fixed in the way EOF works,” said Ferrin. Erigon developer Andrew Ashikhmin expressed his support of including EOF for Prague. Ballet said that he would first like to see EOF working on a Verkle-activated testnet to see how the two upgrades would interact with each other. Reth developer Dragan Rakita said he did not agree there was necessarily a dependency between the two, adding that, “EOF in general seems a better fit for the Verkle tracking than legacy [EVM].”
3. History Expiry – EF developer Kolby Moroz Liebl presented on history expiry. As defined by EIP 4444, history expiry means that EL clients would stop serving historical block headers, bodies, and receipts on the peer-to-peer layer after a certain period such as one year. Instead, this data would be serviced for users through an alternative decentralized network called the Portal Network. Liebl has published an FAQ document about Portal.
Regarding the tooling needed to get history expiry off the ground, Geth developer “Lightclient” said, “We really just need to go ahead and put the stamp on the spec and then go ahead and ship it and start trying to get providers to provide this data because the spec itself, exporting the data, verifying the data, importing the data is [all] great but until the data is available, we can’t actually move forward with removing the data on the P2P network.” Lightclient added that once the data is made available on Portal and serviced by data providers on the network, developers should wait roughly a year before halting the service of this data on Ethereum’s P2P layer. While a hard fork would not be required to update the servicing of historical block data on the P2P layer, it would be an update that client teams want to do in unison, most likely through an upgrade to the Ethereum Wire Protocol.
After discussing all three major code changes, developers discussed how to schedule their implementation on mainnet. Lightclient encouraged client teams to start working on EIP 4444 immediately, given that it does not require major changes to the core protocol of Ethereum and would present major benefits to reducing the data load of Ethereum nodes. Lightclient said that he would work with the Nethermind and Besu client teams to get the initial work for history expiry started.
Ashikhmin noted that from the Erigon team’s perspective, history expiry implementation will have to wait a few months until their Erigon V3 release because their client currently re-executes blocks from Ethereum genesis and therefore would need to access all historical block data for this process. Ashikhmin added that he has a preference to include EOF in Prague but drop it from the upgrade if it presents compatibility issues with Verkle.
Beiko asked if there were any objections to scheduling Verkle for the Osaka upgrade. There were no objections. EF Researcher Ansgar Dietrichs suggested that developers should remain flexible about the scope of the Osaka upgrade, given that it may be over one year out and there is still research needed on Verkle to properly assess its readiness for mainnet implementation.
Miscellaneous Items
During the last few minutes of the call, Beiko ran through the last three agenda items for ACDE #180.
Specify Client Versions on Engine API execution-apis #517 – This is an open PR to improve tracking of what EL clients are used by validator node operators. At present, because most validators use MEV-Boost software, there is no way to analyze block data to ascertain the type of EL client used by the node operator. Therefore, accurate reporting on EL client diversity requires node operators to self-report. The PR recommends embedding by default in the “graffiti” field of nodes the client and version used to run the node. This is a practice already implemented by a few CL clients. Beiko encouraged client teams to review this PR and chime in with their thoughts.
EIP-7523: Empty accounts deprecation – As discussed on ACDE #173, there is an EIP to reduce technical debt on Ethereum testnets caused by empty accounts. EF 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 Precompile Address Range for RIPs – As discussed on ACDE #178, developers are planning on reserving a set of precompile addresses for use by Layer-2 rollup teams. The EIP reserving a precompile address range for rollups is moving into a “last call” phase. Beiko encouraged developers to speak up in case they had any last-minute comments or objections to the EIP.
For the next ACDE call, Beiko said that developers will focus on further scoping out the Prague upgrade.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsementof any of the digital assets or companies mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned or may own investments in some of the digital assets and protocols discussed in this document. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email [email protected]. ©Copyright Galaxy Digital Holdings LP 2024. All rights reserved.