Ethereum All Core Developers Execution Call #158 Writeup
On March 30, Ethereum developers gathered for their 158th All Core Developers Execution (ACDE) call. 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 progress on several longstanding initiatives including EVM Object Format (EOF), deprecating self-destruct, fallback mechanisms for EL clients to suggest local block building, and verkle trees.
Shanghai Incoming
Before diving into status updates on a variety of long-term projects for Ethereum, developers briefly discussed final preparations for the Shanghai upgrade. On Tuesday, March 28, the Ethereum Foundation (EF) published a blog post announcing the forthcoming activation of Shanghai on mainnet Ethereum. Shanghai contains one major code change, enabling staked ETH withdrawals from the Beacon Chain. The upgrade will go live on April 12 at 6:27pm (ET). All Ethereum node operators are encouraged to upgrade their software to the latest client versions, which are all linked in the EF’s blog post.
Since the blog post was published, the Erigon (EL) client team has put out a new software release, which node operators are encouraged to use. The Prysm and Lodestar (CL) client teams also shared that they intend to put out another optional release before Shanghai mainnet activation. Paritosh Jayanthi, a DevOps Engineer for the Ethereum Foundation, reminded Ethereum client teams that the final shadow fork testing Shanghai clients will be activated next Tuesday or Wednesday.
Pooja Ranjan from the Ethereum Cat Herders group reminded Ethereum Improvement Proposal (EIP) authors that have EIPs getting included in Shanghai to update relevant code repositories on GitHub to reflect the final status of their code changes from proposed or in draft to a status of finalized and implemented. Speaking of minor updates to GitHub code repositories, Ethereum Foundation Researcher Alex Stokes highlighted that he had added the finalized timestamp for the Shanghai upgrade to the master Ethereum branch.
Mega EOF
Moving on to discussions around long-term Ethereum projects, Alex Beregszaszi, Ethereum Foundation Research Team Lead, gave an update on EOF initiatives. As background, EOF is a bundle of code changes that target upgrades to the Ethereum Virtual Machine (EVM). The EVM is the execution environment through which smart contract code and user transactions are compiled and deployed on-chain. Beregszaszi explained that the EOF changes proposed last December have undergone significant edits to address feedback from other core developers and clients teams. The full details of what changes have been made to EOF since the end of last year are outlined in this document here.
About the timing for EOF implementation, Andrew Ashikhmin from the Erigon (EL) client team said EOF was “too big a change” to couple with Ethereum Improvement Proposal (EIP) 4844 in the forthcoming Cancun upgrade, which will be worked on in earnest after Shanghai. Ansgar Dietrichs, Researcher for the Ethereum Foundation, said that if client teams were not comfortable bundling EOF with proto-danksharding in the Cancun upgrade, EOF should be implemented in its own hard fork shortly after the Cancun upgrade. “If we keep basically trying to bundle [EOF] with another big change but then we keep prioritizing the other big change over EOF, we will just keep pushing it. So, I feel like if we don’t end up combining it with EIP 4844, it should really get its own fork afterwards,” said Dietrichs.
After the Cancun upgrade, developers had tentatively discussed on prior calls implementing an upgrade to Ethereum data structures which would replace the current use of Merkle Patricia Trees with more powerful Verkle trees. The name for the upgrade after Cancun on the EL side is Prague. Both EOF and Verkle tree implementation represent EL-focused code changes that do not impact the CL. Alongside these EL-focused code changes, there is also an ongoing initiative to upgrade the EL serialization format from RLP to SSZ. Developers discussed to what extent EOF should be prioritized ahead of Verkle trees and to what extent EOF could be coupled with the SSZ upgrade. They did not come to a consensus on the timing for EOF or a decision around which EL-focused upgrades EOF should be bundled with in forthcoming upgrades. Danno Ferrin from Hedera Hashgraph encouraged developers to chime in with more thoughts asynchronously from the ACDE calls on Discord and through the regular EOF calls scheduled bi-weekly.
Deprecating Self-Destruct
Next, developers discussed the deprecation of the self-destruct opcode. Dankrad Feist, Researcher for the Ethereum Foundation, presented EIP 6780 which seeks to address the edge cases around deprecation of an opcode that is used by active smart contracts on Ethereum. The EIP preserves the self-destruct operation only when the operation is executed in the same transaction that a contract was deployed. This ensures that usage of the opcode is limited to a select group of pre-existing users and prevent any new users or decentralized application (dapp) developers from calling the operation. A full description of EIP 6780 can be found here.
Based on the proposal, developers agreed to consider the EIP for inclusion in Ethereum’s Cancun upgrade. Beiko recommended that the authors of the EIP conduct a more thorough survey of Ethereum stakeholders and the dapp ecosystem to ensure that the code changes does not break or negatively impact existing smart contracts.
Exposing the Beacon State Root in the EVM
Ethereum Foundation researcher Alex Stokes, then shared a few paths forward for implementing EIP 4788, which seeks to expose the state of the Ethereum CL, also called the Beacon Chain, in the EVM and make the state accessible to smart contract applications by the protocol without the need for third-party oracles or other trusted intermediaries. The options for exposing the Beacon Chain state in the EVM are explained in detail here. Stokes encouraged core developers, client teams, and liquid staking protocols to chime in with their thoughts.
Builder Override Flag
Mikhail Kalinin from the Teku (CL) client team presented new specifications for a change to the Engine API. The Engine API dictates communication between Ethereum EL and CL nodes. Notably, client teams can implement the changes asynchronously without a hard fork. The change adds a new Boolean field called “should override builder” that the EL can use to indicate to the CL node that it should consider falling back on local block production instead of relying on a third-party builder. This field is useful in the event that the EL node notices peculiar transaction activity that indicate some kind of censorship within blocks produced by a third-party builder. CL nodes can override the flag but at the very least, node operators will be notified of potential censoring behavior on-chain and be able to act accordingly. Nethermind (EL) client team is currently working on a prototype for implementing the proposed changes to the Engine API. Kalinin encouraged other EL client teams to also take a look at the specifications and consider prototyping the override flag.
Verkle Trees
Finally, Geth (EL) developer Guillaume Ballet gave an update on his work around Verkle trees. Ballet said that the code changes are making good progress and in a stage of early testing on two separate testnets. He added, “I’m not saying it’s ready to ship in Cancun but I still get the impression at least the specifications have been stable…It’s looking realistic to be shipped in Prague.” Łukasz Rozmej from the Nethermind (EL) client team followed up with several questions about the detailed status of testing for Verkle trees by asking whether the code had been tested against chain reorgs, JSON RPC, shadow forks, and multiple client transitions. Ballet’s responses illustrated that key areas of testing have not been completed or even attempted for Verkle Trees yet. Based on the incomplete status of testing and development, Rozmej said, “[Verkle trees] are far away. It is a lot closer than it was say a few months ago. I am reluctant to rush it until we have answers, and we are happy with those answers.”
Other developers chimed in with their thoughts about the hurdles to Verkle tree implementation on Ethereum, which disproportionately impacts EL clients like Geth more than Erigon. In response to a question around whether the development of zkEVMs on Ethereum make Verkle trees irrelevant and no longer useful, Dankrad Feist said, “A zkEVM that can in a decentralized fashion prove in a second that a block is correct would indeed make Verkle trees not necessary but I think we are a few years away from that. I’d be willing to be proven wrong…zkEVMs are coming but they still have much higher latencies. They also have massive prover costs.” For a detailed overview of the latest development in zkEVMs, read this Galaxy Research report.
To close off the call, Beiko reminded developers to chime in on these ongoing initiatives to improve various aspects of the Ethereum protocol on relevant forums like GitHub and Discord. The next ACDE call will occur on April 13th at 10AM (ET) after the Shanghai upgrade on mainnet so part of the agenda for next call will be a post-mortem on the upgrade. ACDE calls can be tuned in live from this YouTube channel.
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.