Ethereum All Core Developers Execution Call #160 Writeup
On April 27, Ethereum developers gathered for their 160th All Core Developers Execution (ACDE) call over Zoom. Chaired by the Ethereum Foundation’s Tim Beiko, the ACDE calls are a bi-weekly meeting series where Ethereum developers discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers discussed the code changes that would be included in the next Ethereum upgrade, dubbed Cancun. The corresponding consensus layer (CL) upgrade that will be activated at the same time as Cancun is called Deneb.
Executive Summary
Alongside Ethereum Improvement Proposal (EIP) 4844, also known as proto-danksharding, developers agreed to include the following EIPs in Cancun:
EIP 6780: Changes the functionality of the SELFDESTRUCT opcode so that the operation sends all ETH in an account to the caller, except when the opcode is called in the same transaction a contract was created.
EIP 6475: A new Simple Serialize (SSZ) type to represent optional values. This makes the implementation of EIP 4844 more future-compatible with a larger forthcoming SSZ update to the EL of Ethereum.
EIP 1153: Adds new opcodes for manipulating state that behaves identically to storage opcodes but is discarded after every transaction.
EIPs that developers are considering for Cancun but have not formally accepted into the upgrade:
EIP 6913: Introduction of the SETCODE instruction which would allow contracts to replace their code without clearing their internal state.
EIP 6493: Defines a signature scheme for SSZ encoded transactions. This would also help make Ethereum more future-compatible with a larger forthcoming SSZ update.
EIP 4788: Expose beacon chain block roots in EL block headers to allow proofs of CL state in the Ethereum Virtual Machine (EVM). This would improve trust assumptions of staking pool, restaking constructions, smart contract bridges, MEV protocols, and more.
EIP 2537: Adds the BLS12-381 curve as a precompile to efficiently perform operations such as BLS signature and SNARK verifications. These operations are useful for various applications including account abstraction, Layer-2 rollups, and CL light client development.
EIP 5656: Introduction of a new EVM instruction for copying memory areas to provide efficient means of building data structures and deploying computationally heavy operations on Ethereum.
EIPs that were removed from consideration for Cancun:
Big EOF: A bundle of EIPs that would have made sweeping improvements to the EVM, one of the major ones being separation of code from data.
EVMMAX: A subset of EIPs related to EOF implementation that creates new storage logic for modular arithmetic parameters and memory space to move the values in these parameters to and from the EVM.
SELFDESTRUCT Deprecation
To kick off the discussion, Chair of the ACDE call Tim Beiko asked representatives of EL client teams to share their thoughts on what EIPs should be included in Cancun next to EIP 4844. Many teams were in favor of prioritizing EIP 6780, which would formally deprecate the SELFDESTRUCT opcode. For years, core developers have dissuaded the Ethereum community from using this opcode due to the way it breaks important assumptions about smart contract functionality. For example, SELFDESTRUCT is the only opcode that can cause the code of a smart contract to change and change account balances without account holder consent. In Shanghai, core developers included EIP 6049 which did not introduce any code changes to Ethereum but simply signaled to the community that the behavior of the SELFDESTRUCT opcode would soon be changed. Through the implementation of EIP 6780 in Cancun, developers hope to officially change the SELFDESTRUCT opcode in the protocol and restrict its use to certain limited instances.
Because there are applications on Ethereum that have already been deployed using the SELFDESTRUCT opcode, and EIP 6780 may introduce breaking changes to some of these applications, Ethereum core developers have hired a third-party auditor to assess the impact of EIP 6780. In addition, a developer by the screen name of William Morriss has proposed EIP 6913 to allow smart contracts that are relying on SELFDESTRUCT to replace their code post-Cancun through a new SETCODE instruction. Developers agreed to reassess the candidacy of EIP 6780 once the results of the audit are ready in about a month’s time and consider whether to bundle EIP 6780 with EIP 6913. Regardless of the outcome, developers like Dankrad Feist (Research, Ethereum Foundation) and Andrew Ashikhmin (Software Engineer, Erigon) affirmed that efforts to prepare EIP 6780 for inclusion in Cancun would be orthogonal and independent to efforts preparing EIP 4844, meaning that EIP 6780 would not delay or negatively impact EIP 4844 progress.
Minimal SSZ Changes
Next, developers discussed what changes related to SSZ formatting should be included in Cancun. As background, SSZ refers to the data serialization scheme used on the CL to store and transmit information about chain state. Serialization schemes are important for several reasons, two of the main ones being peer-to-peer communication between nodes and API access. The EL uses a serialization format called RLP, and the differences in serialization between the EL and CL create network overhead and inefficiencies. Over the last few months, Etan Kissling of the Nimbus (CL) client team has been working on a plan to standardize serialization formats between the EL and CL and upgrade the EL RLP format to SSZ. While the entirety of code changes required to complete the transition from RLP to SSZ will not be ready in time for Cancun, there are a handful of smaller EIPs that would be beneficial to include sooner rather than later to make Ethereum more future-compatible with the SSZ serialization scheme.
“I would like to look very seriously at these SSZ EIPs because I don’t want to get into a situation where we do whatever the absolute fastest thing is for EIP 4844 with the intention of changing it just a fork later, or two forks later. I do think it’s important to try and figure out what is the minimal amount of work that can be done so that it’s future compatible with the SSZ world since that’s what we’ve been talking about doing for a couple of years now,” said a pseudonymous developer for the Ethereum Foundation’s Geth (EL) client by the screen name of “lightclient.” Based on the discussion around the four SSZ EIPs, developers came to a consensus about including EIP 6475 at a minimum for Cancun. Developers also discussed EIP 6493 as a candidate but tabled this discussion for further consideration on next Monday’s EIP 4844 Implementors’ Call.
Transient Storage Opcodes
Then, developers discussed a swath of other EIPs including EIP 4788, 1153, and 2537. Representatives of the Besu client team were in favor of including EIP 1153 over the other two because it is further along in testing. Marek Moraczyński from the Nethermind (EL) client team also said he had a slight preference for EIP 1153. Andrew Ashikhmin of the Erigon Execution Layer (EL) client team agreed that EIP 1153 was a good candidate for Cancun as it is a code change that has been under discussion for a long time. Lightclient said his preference was for EIP 4788. Given the support for EIP 1153 from client teams, Beiko said that the code change should be included in Cancun. As for the other EIPs that a fewer minority of core developers expressed support for on the call like EIP 4788, EIP 2537, EIP 5656, and EIP 5920, these should be further discussed in more detail on a future ACDE call.
As for the EIPs that developers agreed would not be included in Cancun, Danno Ferrin, Principal Software Engineer at Hedera Hashgraph, who is heavily involved in work for EOF implementation said regretfully that the EIPs related to EOF would not be ready in time for implementation by Q3 2023, which is presumably when core developers are targeting Cancun activation. “I am in support of moving EOF out of Cancun. One of the things is that that’s going to give us more time to get some core deep questions right,” said Ferrin, adding. “Pulling [EOF] out of Cancun solves a lot of the time pressure so we can focus on getting it right instead of getting it ready for a Q3 shipment. As much as it hurts, I think it’s the right decision.” Other developers from the Geth, Nethermind and Erigon (EL) client teams were all in agreement with Ferrin’s sentiments.
Ansgar Dietrichs, a researcher at the Ethereum Foundation, and Justin Florentine, a developer on the Besu (EL) client team, were in favor of committing EOF implementation to a future upgrade where EOF would be the primary EIP, rather than a secondary consideration. Like how withdrawals were prioritized for Shanghai, and EIP 4844 for Cancun, Dietrichs and Florentine suggested prioritizing EOF for its own upgrade so that the changes are not repeatedly kicked down the road. To this, Greg Colvin, an independent Ethereum developer, said, “I’d like to reiterate that we commit to getting EOF in at some point. The basic functionality is the same as EIP 615, which I proposed in 2016. We’ve been discussing this for seven years. It’s just time. I’ve got work that I’ve been wanting to do in the [EVM] for seven years that I can’t do until this in.” Beiko said that EL client teams are on board with including EOF in its own hard fork but cannot commit to making Prague, the next upgrade after Cancun, EOF-focused. “I don’t want us to commit strongly to something today when we don’t even have implementation for Cancun,” said Beiko.
EIP 4844 Progress
After a discussion around Cancun EIPs, the next agenda item for the call was progress on EIP 4844. During last week’s ACDC call, developers discussed how blob transactions should be reinserted into block in the event of a chain reorganization. This was raised again by Beiko on the ACDE call, though developers did not have any new thoughts to add about the topic. Beiko encouraged developers to chime in on the behavior around reinserting block transactions into blocks post reorgs on Discord. “We need to agree on a design for this,” said Beiko.
Then, Barnabas Busa, a DevOps Engineer at the Ethereum Foundation, gave an update on EIP 4844 Devnet #5. The multi-client test network for EIP 4844 was launched on Wednesday, April 26. There are 1,000 validators on Devnet #5 running three different CL clients, Lighthouse, Lodestar, and Prysm, and four EL clients, Nethermind, EthereumJS, Erigon, and Geth. There is a live blockchain explorer and fork monitoring tool for Devnet #5, which can be found here. Developers plan on spinning up a dedicated explorer for tracking blob transactions by the end of this week. Busa said that he would like more client teams to participate in this testnet. The specifications for joining the testnet can be found here. With Devnet #5 launched, Busa also said that his team plans on shutting down Devnet #4 by the end of the week as a heads for any client teams that are still testing on Devnet #4.
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.