Ethereum All Core Developers Execution Call #183 Writeup
On March 14, 2024, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) Call #183. Chaired by Ethereum Foundation (EF) Protocol Support 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 retrospective on the Dencun upgrade, which went live on mainnet Wednesday, March 13. Major rollups including Base, Optimism, zkSync, and StarkNet have already started to utilize blobs from the Dencun upgrade to lower transaction fees for their users. “This has been a massive, massive fork that we’ve worked on for over two years so [it’s] very cool to see it go live and be so uneventful,” Beiko remarked. Developers also discussed potential code changes for inclusion in the next major Ethereum upgrade after Dencun dubbed Pectra.
Dencun Retrospective
Ethereum developers shared remarks about the early impacts of the Dencun upgrade on the network. Because a high percentage of validator node operators upgraded their software in support of the hard fork, the network experienced no meaningful disruptions or block processing delays. In fact, Prysm developer Terence Tsao noted that the network is appearing to process new transactions, blobs, more speedily than he initially expected. While he expected blobs transactions to arrive later than blocks due to their larger size, it appears blobs despite their weight are arriving earlier than blocks, most likely due to optimizations deployed by “private source” relays for earning additional MEV rewards from blobs and blocks. For more information on blob transactions, read this Galaxy Research report. For more information on MEV, read this Galaxy Research report. For more information on MEV relays, read this Galaxy Research report.
Tsao also mentioned that his node is experiencing roughly three to four more one-block reorganizations per day than prior to the upgrade. Tsao said that before Wednesday, his node used to experience roughly 15 reorgs per day. After the upgrade, Tsao noted that now his node is seeing roughly 17 to 18 per day. As background, an Ethereum node is a computer that connects to and validates the Ethereum blockchain. Tsao asked developers on the call whether their nodes also saw a similar uptick in the number of reorgs. There were no responses to this question on the call.
With the Dencun upgrade complete, developers will now update the status of the nine Ethereum Improvement Proposals (EIPs) that were included in the upgrade to “Final.” Beiko said that he will start to remind relevant EIP authors to make this update over the next week. Additionally, he noted that developers had previously announced to the Ethereum community that the Goerli testnet would be deprecated shortly after the Dencun upgrade goes live on mainnet. While developers plan on supporting the testnet until April 15, 2024, the network is already experiencing bouts of delayed finality and disruptions from a high volume of users and node operators moving off Goerli in advance of the deadline.
Pectra EIPs
Then, developers discussed a few EIPs for consideration in the Pectra upgrade. The first EIP that was discussed has already been approved for inclusion in Pectra, EIP 2537. One of the authors of EIP 2537, EF Researcher Alex Stokes, raised three open questions related to the proposal’s implementation. As background, the proposal introduces new cryptographic primitives to Ethereum that smart contract developers can use to build more secure and performant decentralized applications (dapps). Technically, the EIP introduces these primitives in the form of 9 new precompiles, which are operations built into the execution environment of Ethereum directly as opposed to through a smart contract.
One of Stokes’ questions related to EIP 2537 was whether additional precompiles should be created to allow for “point decompression” which may be a better way for Layer-2 rollups and other “data-constrained environments” to utilize the new cryptographic primitives introduced by the proposal. Stokes also noted that there will be gas cost changes that need to be made to the proposal to accurately price these new operations. After some discussion on the tradeoffs between differing design choices for the EIP, Stokes said that he would source more feedback from rollup teams on the next Rollcall, which is a recurring coordination call between major Ethereum rollups. The next Rollcall is scheduled for Wednesday, April 10 at 14:00 UTC.
EIP 3074: AUTH and AUTHCALL Opcodes
The second EIP that developers discussed related to the Pectra upgrade was EIP 3074. This code change is one of three main EIPs in the running for Pectra that are all focused on introducing greater programmability and flexibility to user-controlled accounts, also called externally owned accounts (EOAs). Speaking in support of EIP 3074 in Pectra, Metamask wallet developer Dan Finlay said, “EOAs have proven to provide an insufficiently flexible system for authorization for many people and people are suffering millions of dollars in fund losses every day. We believe that 3074 is an opportunity for the protocol layer to bring some opportunities for user safety that can then be implemented at the wallet layer. 3074 allows EOA holders to adopt smart contracts to authorize their transactions and that could eventually mean taking fully authorized one of one private keys off of hot machines entirely, and ensuring far more people are using patterns that we're continuing to refine for safety and usability.”
After further discussion on the design of EIP 3074, primarily the authorization of user transactions under this EIP and the reliance on trusted relays for transaction sponsorship, Beiko recommended that developers take more time to consider the merits of EIP 3074 considering first the other account abstraction related EIPs in the running for Pectra and second all other EIPs proposed for inclusion in Pectra. If included in Pectra, Finlay said that Metamask could have features to utilize the code change as quickly as sometime this year. Developers also briefly discussed the benefits of prototyping the proposal initially for execution on rollups such as Polygon before Ethereum mainnet to hammer out any implementation kinks and design details. Geth developer “Lightclient” pushed back on the idea of holding off on an approval for EIP 3074 in Pectra until other EIPs are prioritized saying that the code change “is a very simple implementation” that would not prevent developers from including other code changes in the upgrade. Still, Beiko affirmed that the next steps for EIP 3074 would be to finalize its specifications and prototype the design with client and/or rollup teams, then, rediscuss whether to prioritize the code change for inclusion in Pectra.
EIP 7547: Inclusion Lists
Then, EF Researcher Mike Neuder resurfaced his arguments for inclusion of EIP 7547 in Pectra. For background on EIP 7547, listen to this Galaxy Research podcast. About the motivation for the proposal, Neuder said, “[I’m] trying to make the point that if we commit to not doing inclusion lists in Electra, we let the MEV infrastructure continue to evolve for basically the next year and a half to two years without any kind of changes. On our side. I think that's a very active decision in itself, not doing anything is almost as strong of a decision as doing something. So that's the first point I wanted to make. The second is that the scope of the [inclusion list] change is generally well contained. We've been working on this proof-of-concept spec, POC spec, … just trying to kind of de risk and show across both the consensus layer, execution layer, and Engine API, that the changes are pretty small. Hopefully to motivate going for it in this fork.”
The Reth client team expressed their support for inclusion of EIP 7547 in Electra. Representatives from the Geth, Lighthouse, Lodestar, and Nethermind client teams shared that they are working on a prototype for the code change. Additionally, Besu developer Justin Florentine expressed his personal support for the inclusion of the code change in the next Ethereum upgrade. Neuder encouraged developers to review the latest specifications for the EIP and chime in with any thoughts or questions in the inclusion lists Discord channel. He also shared that he will be hosting a breakout meeting for inclusion list implementation details next Monday, March 18, at 14:00 UTC.
EIP 7623: Increase Calldata Cost
Next, EF Researcher Toni Wahrstätter reshared his proposal to reduce the maximum block size on Ethereum by increasing the cost of calldata. Calldata is where batched transaction data from rollups is usually stored in an Ethereum transaction. However, with the introduction of blobs through Dencun, rollups can now temporarily store transaction data from users on Ethereum at significantly cheaper costs than calldata. “The nice thing is that this rebate mechanism basically enforces, ‘If you bring a lot of calldata into the [Ethereum Virtual Machine], you need to also use it. Otherwise just use blobs.’ Seems very healthy,” EF Researcher Ansgar Dietrichs remarked in the meeting chat about EIP 7623. Wahrstätter shared new analysis on how an increase to calldata costs would impact user transactions. He said that the increase in costs would only impact 4.5% of Ethereum transactions and 1% of Ethereum users. Wahrstätter said that his next steps are to reach out to rollup teams to get their feedback on his proposal during the next Rollcall. Beiko mentioned that because the EIP represents a trivial change to the Ethereum codebase, developers do not need to decide on its inclusion in Pectra posthaste, but rather over the course of the next few ACDE calls.
EIP 7645: Alias ORIGIN to SENDER
Cyrus Adkisson, an early investor in Ethereum, proposed changing the behavior of the ORIGIN opcode to return the same value as the SENDER opcode. “The ORIGIN opcode is sort of a relic. It represents the account that originated the action and paid for the gas for the transaction, which is and until we get true [account abstraction], always the same thing. In mid-2016, it became generally acknowledged that TX ORIGIN for anything was bad news for a variety of reasons. … One, origin can be used in sort of cross site scripting way to steal assets and misuse authority if that authority is delineated in TX ORIGIN terms. ORIGIN breaks compatibility since your contract can’t be used by other contracts and ORIGIN is almost never useful,” said Adkisson. Under this EIP, the ORIGIN opcode would return the same value as the SENDER opcode, which is the address of the immediate sender of the message or transaction.
As a potential precursor to this EIP, Adkisson also proposed a different strategy to ban the ORIGIN opcode before changing its behavior. This sparked some pushback from developers. Danno Ferrin, Besu client maintainer, said that without EOF, which is a separate set of code changes to the EVM, it is impossible to accurately check all the use cases for the opcode before banning its use. Ferrin said the EOF code specifications, which are also in the running for inclusion in Pectra, have been frozen and reference tests are being written for the proposal.
Freelance Ethereum developer Charles Cooper said that a change in the behavior for the opcode was “dangerous,” given that certain users may be relying on the opcode for important use cases. Instead, Cooper suggested an increase in the gas cost for ORIGIN to help alert users of its deprecation and discourage its use. “[This] maybe a slicker change from a compatibility standpoint,” said Cooper.
ACDE #184 Agenda
Due to limited time, as these meetings are maximum an hour and half long, Beiko recommended moving certain agenda items for discussion at the top of the next ACDE call. Once of these agenda items that was punted for ACDE #184 is the Reth client team’s research on Ethereum state growth. Before ending the call, Beiko asked developers about their thoughts on the continuation of the weekly Monday testing calls. These calls were focused on coordinating testing efforts between client teams for the Dencun upgrade. With the Dencun upgrade complete, developers agreed to retire the recurring Monday testing calls and restart a new series once the Pectra upgrade is closer to being ready for multi-client testing efforts.
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.