Ethereum All Core Developers Execution Call #185 Writeup
On April 11, 2024, Ethereum developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #185. 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 discussed what code changes should be added to the Prague hard fork, the next immediate EL upgrade on Ethereum. Prague will be activated simultaneously with a CL upgrade dubbed Electra. Both are tentatively scheduled to activate sometime before the end of 2024.
Initially, developers agreed to scope out Prague/Electra (Pectra) to include five Ethereum Improvement Proposal (EIPs). They are:
EIP 2537, Precompile for BLS12-381 curve operations
EIP 6110, Supply validator deposits on chain
EIP 7002, EL triggerable exits
EIP 7251, Increase the MAX_EFFECTIVE_BALANCE
EIP 7549, Move committee index outside attestation
This week, they agreed to include EIP 3074 (AUTH and AUTHCALL opcodes) and EIP 2935 (Save historical block hashes in state) in the above list. They also agreed to exclude EIP 7547 (Inclusion lists) and EIP 7667 (Raise gas costs of hash functions) from Prague. Developers were in strong favor of bundling EIP 7667 with Verkle in the next EL upgrade after Prague, Osaka. There are 10 Ethereum Virtual Machine Object Format (EOF) EIPs and EIP 7623 (Increase calldata costs) still under consideration for Prague.
Reviewing What’s Already Included in Prague
Before diving into the list of EIPs under consideration for Prague, developers spent a brief amount of time reviewing outstanding concerns about the EIPs already included in the upgrade.
EIP 7251
One of these EIPs, EIP 7251, will allow node operators to consolidate validators with an effective balance of up to 32 ETH into one large validator with an effective balance of up to 2048 ETH. An effective balance refers to the staked ETH balance on which validators earn issuance rewards. Balances greater than 32 ETH do not earn validators more issuance, which is why node operators must operate multiple validators to multiply their issuance rewards. EIP 7251 seeks to reduce the number of active validators on Ethereum by enabling validator consolidation and auto-compounding of staking rewards.
Based on developers’ discussions with large Ethereum staking pools such as Lido, they have agreed to consider changes to the EIP that will make validator consolidation an operation triggerable by smart contracts from the EL. Ethereum Foundation Researcher Alex Stokes highlighted his writeup on how in-protocol consolidation could function as an EL operation and requested feedback from client teams on the call about his proposed code changes.
EIP 2537
Stokes also shared an update on EIP 2537, which adds operations to the Ethereum Virtual Machine (EVM) so that developers can efficiently perform cryptographic signature verifications using the BLS12-381 curve construction. This is a more secure and faster way of doing signature verifications than the ECDSA signatures generated on the EL using the secp256k1 curve construction. Stokes said initial benchmarking work to price these operations has been completed and developers can expect a final update on the exact gas costs for them over the coming weeks. In the meanwhile, client teams are encouraged to implement the EIP as presently scoped out for the first Pectra developer test network, pectra-devnet-0.
Debating What Else Should Be Included in Prague
Prior to this week’s call, EL client teams shared written updates about what other EIPs they would like to see included in Prague outside of the five that they had already agreed to include in the upgrade. Beiko linked to EL client team preferences in the call agenda and for posterity they are also linked below:
Mega EOF Endgame
Kicking off discussions about other EIPs to include in Prague, Geth developer Guillaume Ballet expressed his opposition to including EOF changes in the upgrade. He said that he is worried that the changes may “paint ourselves in a corner” by making it difficult or impossible to implement Verkle in the upgrade after Prague, which is dubbed Osaka. To this, Chief Software Engineer of Swirlds Labs Danno Ferrin pushed back and said EOF could be “100% compatible” with Verkle code changes. Indicating that he was not confident about Ferrin’s assessment, Ballet reiterated comments made from a prior ACDE call about wanting to see EOF on a Verkle testnet. Beiko jumped in to explain that assessing the compatibility of EOF based on how it functions on a testnet for a future hard fork is not a reasonable requirement and asked Ballet if he could clarify specific concerns about EOF’s compatibility with Verkle. Ballet did not. He said there were no code specifications for EOF for him to even review. A developer shared the link to the latest EOF specifications in the Zoom chat. A link to the readiness of EOF based on client implementations was also linked in the chat.
Geth developer Marius van der Wijden asked how many opcodes EOF would add or update. Beiko noted that EOF, based on its latest specifications, would change 18 opcodes. EOF is a bundle of code changes to the EVM from 10 different EIPs. Van der Wijden said that his main concerns with EOF are its complexity and the amount of work it will take from client teams to adequately test all the edge cases in EOF. Nethermind developer Marek Moraczyński agreed that EOF may “introduce number new consensus bugs” and will require “careful testing,” but that the downside of not implementing these EIPs now means that these improvements to the EVM will have to wait another two to three years.
Ferrin pointed out that when developers were debating the merits of EOF for inclusion in the Shanghai upgrade, they pushed back on the code changes for being too narrow in scope. Now that Ferrin and other developers have worked to make EOF more expansive, client teams are pushing back for the code changes being too complex and difficult to implement. “We just can’t get a consistent request on what people want out of the All Core Devs group,” said Ferrin, adding that it was “frustrating” to hear complaints about both versions of EOF. The Reth and Erigon client teams were supportive of including EOF in Prague. Beiko recommended that developers move on to discussing other EIPs and circle back on the conversation about EOF later in the call.
EIP 3074, AUTH and AUTHCALL opcodes
Beiko asked client teams about their thoughts on EIP 3074, the introduction of AUTH and AUTHCALL opcodes. These opcodes would create more programmability in user-controlled accounts, called externally owned accounts (EOAs) on Ethereum, by allowing smart contracts to authorize transactions from an EOA. Many developers on the call including Georgios Konstantopoulos, Danno Ferrin, and “protolambda”, were supportive of this code change. Protolambda resurfaced EIP 7664, his proposal to fix a gap in EIP 3074’s logic when interacting with access lists. Geth developer and EIP 3074 co-author Matt Garnett, also known as “Lightclient”, said that he thought EIP 7664 was a good idea. Another developer asked about how EIP 3074 would impact the ORIGIN opcode, which is an operation that returns the address that originated a transaction. Beiko said that the impacts are listed in the EIP and asked if anyone developers opposed including this code change in Prague. There were no objections.
EIP 2935, Save historical block hashes in state
Ballet presented EIP 2935 on ACDE #184 as a code change that would offer future benefits for Verkle implementation. The Reth client team was “neutral [to] positive” about the EIP and said that given it is a simple change they would not be opposed to including it in Prague. The Erigon client team was of a similar opinion but did note that they were less confident about including it in Prague if bigger code changes like EOF would also be included in the upgrade. Beiko recommended moving on to discussing other EIPs and circling back to EIP 2935 later in the call.
EIP 7667, Raise gas costs of hash functions
Cofounder of Ethereum Vitalik Buterin has proposed an EIP to raise the gas costs of hash function opcode and precompiles to match their execution costs through zero-knowledge (ZK) systems such as ZK EVMs. For more information about ZK EVMs, read this Galaxy Research report. About the motivation for repricing hash function operations on Ethereum, Buterin wrote in the EIP 7667 document, “Gas costs for hash function opcodes and precompiles were originally set based on the time that it takes to execute them on a regular CPU. Since then, however, there has emerged another equally important execution substrate that the EVM is executed on: zero knowledge proof (ZK-SNARK) systems. By that standard, these opcodes and precompiles are very underpriced relative to other operations.”
On the call Buterin added that it is easy to underestimate how quickly ZK proofs will become commonplace operations for verifying blockchain state not only across Layer-2 rollups but across Layer-1 blockchains like Ethereum as well. “I think it's very plausible to our belief that even within one or two years, we'll have the capability of proving the Ethereum L1 in real time. So, I think it's just important to mentally adapt to the fact that there's no such thing as a distinction between ZK chains and non ZK chains. We are basically now entering a mode where every serious chain is a ZK chain,” said Buterin.
Given that there will be changes to gas pricing and schedule in the Osaka upgrade due to Verkle, Ferrin recommended implementing this EIP with Verkle. EF Researcher Carl Beekhuizen said that this EIP requires a lot of investigation, and developers must be “very careful” in doing their analysis on how these gas changes will impact smart contracts on Ethereum. Van der Wijden agreed with Beekhuizen about moving this EIP forward with caution. Ferrin also recommended possibly having these changes first implemented on Layer-2 rollups while Ethereum developers investigate its implications on Layer-1 further. Beiko agreed with this sentiment and recommended that developers give EIP 7667 a status of “CFI” or “considered for inclusion” in the Osaka upgrade alongside Verkle. There were no objections.
EIP 7623, Increase calldata cost
EF Researcher and co-author of EIP 7623 Toni Wahrstätter shared updates about his proposal to increase the cost for calldata and asked client teams about their thoughts on it. EF Researcher Ansgar Dietrichs and Nethermind developer Ahmad Bitar were in favor of it. Beekhuizen added that when EIP 7623 was brought up on the latest Rollcall meeting, a meeting series between Layer-2 rollup teams, there were no objections to its implementation. Beiko recommended moving on to discussion about other EIPs and circling back to this one later in the call.
EIP 7645, Alias ORIGIN to SENDER
Beiko asked client teams about their thoughts on EIP 7645 which proposes changing the behavior of the ORIGIN opcode to prevent its misuse by smart contracts. Cyrus Adkisson, an early investor in Ethereum and author of EIP 7645, noted that there are three possible paths forward to updating the ORIGIN opcode, each that come with different tradeoffs. Ferrin said that the one recommending a behavior change to the opcode needs careful review by security professionals and auditing companies as Ethereum protocol developers cannot adequately assess the impact of such a change on existing smart contracts and end-users. Beiko recommended developers move on to discussing other EIPs for the sake of time.
EIP 7547, Inclusion lists
Beiko asked developers about their thoughts on the inclusion of EIP 7547 in Prague. It did not appear that there was broad support from EL client team for the code change. Beiko recommended excluding it from the upgrade. There were no objections.
Issuance Curve Adjustment Proposal
Dietrichs raised a proposal to reduce the issuance of Ethereum. Given that a change to issuance would primarily impact the CL of Ethereum, Beiko recommended that developers further discuss the merits of this proposal on ACDC calls.
Revisiting EOF, EIP 7623, and 2935 for Prague
Developers then revisited the EIPs proposed for Prague that had not yet reached a consensus. Beiko asked whether EOF could be bundled in with the Verkle upgrade. Ballet was vehemently opposed to this idea, saying that both code changes were complex and doing them at the same time would be “too risky.” Protolambda highlighted EIP 7664 as an additional EIP that should be considered for Prague. Garnett added that EIP 7639, a proposal for clients to cease serving historical data from before the Merge upgrade, September 2022, should also be considered.
Speaking to concerns that the inclusion of EOF would add too much additional burden on client teams, Reth developer Georgios Konstantopoulos encouraged developers to “try and go the extra mile.” Still, there was no consensus on EOF. Developers ultimately agreed to continue working on EOF, especially the testing needed for it, and determine later whether it should be included in Prague. They also agreed to defer a decision on EIP 7623. Regarding EIP 2935, developers agreed to include it in Prague.
Recapping all the decisions made on the call, Beiko said that developers will include EIP 3074 and EIP 2935 in the first devnet for the Pectra upgrade. After this devnet, they agreed to decide whether to include EOF and/or EIP 7623 in the second Pectra devnet.
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.