Ethereum All Core Developers Execution Call #179 Writeup
On January 18, 2024, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) Call #179. 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 shared a post-mortem on the activation of the Cancun/Deneb (Dencun) upgrade on Goerli. Developers also agreed to stick with activating Dencun on the Sepolia and Holesky testnets in the weeks upcoming on January 30 and February 7, respectively. Finally, developers discussed priorities for the Prague/Electra (Petra) upgrade, which most client teams on the call agreed should contain smaller code changes that can be prepared for implementation on mainnet before the end of 2024.
Dencun Hard Fork on Goerli
The Dencun upgrade was activated on Goerli on Wednesday, January 17 at roughly 6:30 (UTC). As summarized by EF DevOps Engineer Parithosh Jayanthi, the Goerli network experienced a drop in network participation rates immediately after the upgrade was activated. The root cause of the drop in participation turned out to be a bug in the Prysm (CL) client. The Prysm team issued a hot fix to the issue less than four hours after it was discovered. Once node operators running Prysm client software updated their machines, network participation rates increased from roughly 40% to 70%, which allowed the network to finalize blocks, blobs, and transactions.
Since the activation of Dencun on Goerli, the EF testing team has been submitting large quantities of blob transactions on Goerli to test the network’s capacity to process these types of transactions. Jayanthi said that initial metrics, including blob, block, and attestation propagation speeds, appear healthy. A more detailed analysis of these metrics can be found in this writeup by the EF DevOps team here.
Terence Tsao from the Prysm team also shared a more detailed explanation of the bug in the Prysm client that was fixed on Goerli. Tsao explained that the issue was due to the historical roots field in the Prysm client being empty. Historical root is a legacy field carried over from the prior Ethereum upgrade, Shanghai/Capella (Shapella), that developers had forgotten to update to a non-zero value. This was an “easy” bug to catch, Tsao said, that simply required analysis of test networks that moved through upgrades such as Shapella according to a longer timeframe. All prior devnets and shadow forks implementing Dencun moved through prior upgrades on the network too quickly for this bug to be caught. Moving forward, developers agreed to include this edge case in their test vectors and be more conscientious to test for this edge case earlier in the upgrade testing process.
Regarding other irregularities seen on Goerli after Dencun, Tsao mentioned that certain CL clients appeared to be requesting blobs “no matter what,” even for blocks without KZG commitments. Given that this type of behavior is “wasteful,” Tsao recommended that client teams look into their clients behavior and ensure that blob requests are triggered only for blocks with the appropriate KZG commitments.
Then, Jayanthi asked developers on the call for insights on when Layer-2 protocols (L2s) would begin submitting blob transactions on Goerli. Given that his team is “artificially spamming” the test network with blobs, Jayanthi said he would like to reduce the activity when L2s are ready to submit their own blob transactions. Tsao from the Prysm client team, which is a software client owned by L2 protocol Arbitrum, said that the Arbitrum team will likely test blob transactions on the Sepolia testnet rather than on Goerli. A pseudonymous developer by the screen name “Protolambda” who works for the Optimism L2 protocol said that the Optimism team is aiming to start testing on Goerli in a few weeks. EF Researcher Ansgar Dietrichs said that he would mention this question on the next Rollcall meeting, which is a meeting series for L2s to encourage standardization and coordination of L2-focused upgrades.
L2 Readiness for Dencun
Chair of the ACDE meetings Tim Beiko asked a more pointed question about the level of confidence developers had in the immediate usefulness of the Dencun upgrade for L2s. “Do we see a risk that 4844 is somehow inadequate for L2s? Obviously, you can imagine it being on mainnet for months before an L2 chooses to use it. That’s probably fine but what’s the minimum amount of confirmation we want that this is quote unquote usable and do we already have that?” said Beiko. (4844 refers to Ethereum Improvement Proposal 4844, also known as proto-danksharding, which is the main code change in the Dencun upgrade designed for use by L2s. For more information about what proto-danksharding entails, read this Galaxy Research report.
Protolambda responded saying that while the Optimism team is “close” to being able to support Dencun, he is concerned about the readiness of infrastructure and tooling for blob transactions. “There’s more infra to update outside of the Layer 1,” said Protolambda. Beiko clarified to say that he would not block Ethereum mainnet from adopting Dencun faster than L2s can support the upgrade. However, there may be “additional validation from L2s” that could ensure Dencun is a useful change to the Ethereum protocol shortly after it is activated.
Jayanthi said that he would reduce blob spam on Goerli from a target of six to three blobs per blobs to allow for L2s to test out their infrastructure for blobs when they are ready. EF Researcher Alex Stokes also mentioned that the Flashbots team has been delivering some block builder payloads that include blobs on Goerli to test the MEV-Boost workflow.
Execution API Specifications Change
A developer for the Geth (EL) client with the screen name “Lightclient” raised a pending change to execution API specifications related to the Dencun upgrade. As discussed on ACDE #174, the introduction of blob transactions means new methods for retrieving data about blob gas prices and fees. To encourage consistency with the naming of methods already used for retrieving gas information about regular transactions on Ethereum, there is a proposal to update one of the execution API methods from “eth_blobgasprice” to “eth_blobbasefee”. The proposal also recommends adding blob fee data to the “eth_feeHistory” execution API method.
Developers agreed to make a final call for comment about them in the Ethereum Research and Development Discord channel and explicitly tag a representative from Infura who may be impacted by this change for review and merge these changes if there are no objections.
EIP 4788 Contract Deployment
As discussed on prior ACD calls, one of the code changes in the Dencun upgrade, EIP 4788, requires the manual deployment of code and the creation of a smart contract address that can then be activated at the time of the hard fork. Developers agreed to deploy the code in advance on Ethereum mainnet. Beiko asked for a volunteer to chime in on the Ethereum R&D Discord and said that he would refund the volunteer for the gas spent to submit the transaction.
EF Researcher and Chair of the ACDC calls Danny Ryan gave a short update on new CL specifications being released for Dencun. The latest release will contain the fork choice filtering change mentioned on ACDC #125, as well as the new test vectors for checking the historical roots field and a handful of other minor updates. The new release is expected to go out this week and be the standard for CL client teams to conform to for their respective code releases.
Sepolia & Holesky Fork Timing
Then, developers discussed timing for Dencun activation on the final two Ethereum public testnets, Sepolia and Holesky. Before the activation of Dencun on Goerli, developers had agreed to activate Dencun on Sepolia and Holesky on January 30 and February 7, respectively. On this week’s ACD call, developer reconfirmed these dates and agreed to move forward with a single client release for both upgrades such that the Holesky upgrade can occur more quickly, one week after the Sepolia upgrade. A representative from the Lighthouse client team mentioned in the Zoom chat that the releases for Sepolia and Holesky may have to be a “pre-release” again, meaning a release that is not ready for use on mainnet that will likely require updating. Prysm shared on an earlier call that their release for the Goerli upgrade was a pre-release. It is unclear if their release for Sepolia and Holesky will similarly be another pre-release.
Specific timing for the Sepolia and Holesky upgrades can be found in the Dencun Hard Fork Meta EIP document here.
Protolambda asked in the Zoom chat how developers felt about the time between Dencun activation on the final testnet, Holesky, and Ethereum mainnet. “What does everyone here estimate for minimum rollout time between Holesky and Mainnet L1? A month, two months? Sufficient time to test L2 effects, incl. blob expiry, would be great,” wrote Protolambda. In response, Beiko wrote, “1 month is the minimum I would expect?” Jayanthi said that the earliest blob expiry could be tested on Goerli would be February 5 and recommended that developers discuss this topic in more detail on the ACD call thereafter on February 8. Danny Ryan suggested 2 to 3 weeks.
Prague/Electra Proposals
Next, developers discussed a handful of EIPs proposed for inclusion in the Petra upgrade.
EIP 3074
Presented on the call by a pseudonymous developer with the screen name “Foobar”, EIP 3074 introduces two new EVM instructions “AUTH” and “AUTHCALL” to enable greater functionality for externally owned accounts, one of the most important of which is the ability to sign batched transactions. Foobar gave a detailed presentation on why batched transactions are an important functionality for end-users on Ethereum that will increase the security of their assets and improve the user experience on decentralized exchanges (DEXs). For more information on EIP 3074, read this blog post written by Foobar.
EF Researcher Ansgar Dietrichs said that his two main push backs to EIP 3074 was its implementation benefits over narrower versions of this EIP. Secondly, Dietrichs said that in his view EIPs that improve the user experience on Ethereum should be first implemented and tested on L2s, given that L2s are more flexible and faster at adopting new technology than Ethereum mainnet. William Morriss, founder of a DeFi trading firm called VM Capital, disagreed with Dietrichs on his second pushback. “I don't think Layer 2 should be treated like a feature test net. The developers making Layer 2s care a lot about compatibility with main net and if they deployed a feature that had a tentative specification, then when it finally comes to main net, even if it has the same opcode number, there might be differences in behavior and those would be technical debt for them. So, they aren't especially interested in doing that role for us usually,” said Morriss.
Ben Adams, a developer for the Nethermind client, agreed with Foobar that batched transactions were a desirable feature for improving the end user experience on Ethereum. Lightclient added that there is in his view lots of demand for some kind of improvement to the user experience on Ethereum in the next upgrade, so if not EIP 3074, developers should consider another version of it that is easier to implement. Beiko recommended continuing to discuss the merits of EIP 3074 on Ethereum Magicians.
EIP 6913
Then, Morriss presented different implementation designs for EIP 6913. In his presentation, Morriss shared the motivation for a new EVM instruction called “SETCODE” that would be able to replace code in a smart contract account without requiring the migration of code to a new address. Developers had several pushbacks to the EIP. Marius van der Wijden from the Geth team said that the EIP would break gas estimations and create DoS attack vectors on nodes. Dietrichs said that EIP 6913 should only be considered in context of “a comprehensive AA roadmap,” referring to a roadmap for account abstraction on Ethereum. Lightclient said the EIP was not “useful enough to change the protocol” in his view. Morriss agreed that developers should focus on enabling account abstraction in some way on Ethereum, be it through EIP 6913 or other AA-focused EIPs.
EIP 7251 & EIP 7545
EF Researcher Mike Neuder presented EIP-7251 and EIP-7547 as two CL-focused code changes that would have minor impacts on the EL.
EIP 7251 increases the maximum effective balance of validators. It requires coupling with EIP 7002, which would allow validators to trigger partial withdrawals from the Beacon Chain to the EL using their EL withdrawal credentials.
EIP 7547 implements a mechanism through which block proposers can force inclusion of certain transactions in a block. For more details on forced inclusion through inclusion lists and their benefits to helping prevent transaction censoring on Ethereum, read this Ethereum Research post by Mike Neuder.
Many developers on the call were in favor of prioritizing the EIPs presented by Neuder for Petra. About EIP 7547 specifically, Neuder stressed, “We’re in this slightly delicate situation where a number of the large builders have started censoring a subset of transactions. There is a few builders that are not. If those builders decide to start censoring, then it could quickly turn into both like a bad look … if ninety plus percent of blocks are censored and also like a legit degradation in UX in terms of getting those transaction in. So, right now, I would say the situation is very unstable and the more I hear from builders and validators, the more I think that getting some enshrined inclusion feels very important, especially as regulatory stuff continues to be uncertain.”
Thoughts about Petra
Given the full list of EIPs proposed for the Petra upgrade, Beiko asked client teams what their “high level” thoughts were on the content of the upgrade. Georgios Konstantopoulos from the Reth client team said his team would be supportive of a Petra upgrade that can be shipped before the end of the year that includes staking related EIPs and isolated EVM changes. For a more detailed overview of which EIPs this would include, read the Reth blog post about the Petra upgrade here.
EF Researcher Alex Stokes was supportive of Reth’s views for Petra. Other client teams such as Nethermind and Geth were also supportive of an upgrade that could be shipped before the end of the year. Most client teams were also in favor of focusing the upgrade thereafter on Verkle trees. There was some debate on the call whether EOF-related code changes should be implemented before the Verkle upgrade given that EOF may increase the complexity of Verkle implementation. For more information on EOF, refer to prior ACD calls notes.
Based on the high-level thoughts about Petra shared by client teams on the call, Beiko recommended converging on including at least EIP 6110, 7002, and 2537, in the Prague upgrade. (Accompanying CL-focused EIPs for inclusion in the Electra upgrade will be discussed in further detail on the next ACDC call.) With those three at a minimum being included in the Prague upgrade, Beiko also recommended spending the focus of the next ACDE call to decide on a schedule for the larger, more complex code changes such as Verkle, EOF, and historical data pruning. A pseudonymous developer for the Prysm client team by the screen name “Potuz” added that developers should commit to shipping Petra for implementation on mainnet before the end of 2024 as opinions about what should be included in Petra may change if the upgrade may ship in 2025 or anytime thereafter. Potuz also gave a shout-out to the Reth team for their detailed blog post on what should be prioritized for Petra. He encouraged other client teams to prepare similar documents.
Besu Jan 6 Mainnet Event
Due to limited time on this week’s ACD call, the last discussion item regarding an outage impacting Besu nodes on Ethereum mainnet on January 6and incorrect performance numbers shared about minority clients on the latest EF Research team Reddit AMA was skipped. Beiko said that this discussion item would be raised as the first topic of the next ACDE call.
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 2023. All rights reserved.