Ethereum All Core Developers Execution Call #157 Writeup
On March 16, Ethereum developers gathered for their 157th 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 timing for mainnet activation of the Shanghai upgrade. They agreed to activate Shanghai on Ethereum on April 12, 2023 at epoch 6209536, which is estimated to hit at 6:27 PM (ET). With the Shanghai upgrade scheduled, developers then moved on to discussing the Ethereum Improvement Proposals (EIPs) slated for the Cancun upgrade. Notably, there was a significant amount of support from developers for deactivating the SELFDESTRUCT opcode and implementing two new opcodes to support transient storage for smart contracts.
Shanghai Scheduled for April 12
Developers were pleased with the activation of Shanghai on the Goerli testnet earlier this week. They did not identify any issues or bugs with client software. The main issue during the activation of the upgrade on Goerli was the lack of readiness by Goerli validator node operators. Because a significant number of validators had not upgraded their software, the network was unable to finalize for roughly an hour and half. While withdrawals and blocks were still being processed by a minority of validators through this time, the network could not come to consensus about the finality and irreversibility of these transactions until later. Beiko highlighted on Twitter that the issue of non-upgraded nodes is not likely to be an issue on mainnet, given that there are assets of real financial value at stake on Ethereum incentivizing validator node operators to upgrade their software.
With the Shanghai activation on Goerli complete, developers agreed to schedule a date for upgrade activation on Ethereum mainnet. Developers settled on epoch 6209536, which is expected to be reached on April 12 at 6:27PM (ET). Beiko said that finalized client releases for Shanghai on Ethereum would be released in an official blog post by the end of March.
Strengthening Ethereum’s Censorship Resistance
Next, developers discussed a new pull request on GitHub suggested by Prysm developers Terence Tsao and “Potuz.” PR #388 suggests adding a field where the execution layer (EL) client of an Ethereum node can indicate to the consensus layer (CL) client a suggestion of falling back to local block production. Based on evaluations from the EL on the mempool and incoming transactions, the EL would be able to flag suspicious activity such as censoring behavior on the network by third-party actors such as MEV relays. This is especially timely based on certain upgrades to MEV relays on Ethereum that could make identifying censoring behavior on-chain more difficult. Tsao stressed that the implementation of the PR does not force the CL client to rely on locally built blocks but rather, merely presents this as an option based on certain pre-programmed criteria by the EL.
Danny Ryan, chair of the All Core Developer Consensus (ACDC) calls, voiced his support for the PR saying, “It’s a very small change that can then be very much iterated on by ELs and CLs as they see fit and really does open up the design landscape to try to ensure that we have censorship resistance and other potentially nice properties of how the mempool is being utilized.” Other developers did agree the PR would be trivial to implement in Ethereum software clients. However, out of an abundance of caution and to allow for sufficient testing time, developers did not commit to pushing this code change in time for the Shanghai upgrade. Instead, developers committed to implementing this PR some time after Shanghai.
Cancun EIPs
After Shanghai, developers will activate EIP 4844, proto-danksharding, which is a code change designed to significantly reduce the cost of Layer-2 rollups and thereby, increase the scalability of Ethereum. For more information about Layer-2 rollups, read this Galaxy Research report. Aside from EIP 4844, developers agreed during a prior call to consider EOF implementation in the Cancun upgrade. As a side note, Cancun is the name of the upgrade for the EL of Ethereum. The corresponding upgrade name for the CL of Ethereum is Deneb. EOF stands for EVM Object Format. EOF is a bundle of several optimizations to Ethereum’s code execution environment aimed at helping smart contract developers more easily and efficiently test and deploy code. Aside from EOF, the following is a list of other EIPs considered for inclusion in Cancun:
SSZ formatting: As discussed on prior calls, developers are working towards updating the serialization scheme used by Ethereum’s EL so that it is consistent with the scheme used by Ethereum’s CL. Etan Kissling, a developer of the Ethereum Nimbus (CL) client team, is spearheading efforts to get this done. Developers are divided on whether they should delay changes to SSZ formatting until after Shanghai to reduce the complexity of the Cancun upgrade. Kissling reminded developers on this week’s call that regardless of whether the full conversion from RLP to SSZ is included in Cancun or not, developers will still have to make minor conversions to accommodate the code changes in EIP 4844. “The [EIP] that has to be in Cancun if the blob transaction is SSZ is EIP 6493 because we need a signature scheme that cannot ever conflict with a future transaction type that we introduce,” said Kissling. As for the other code changes that are more involved to fully completing the transition, Kissling said they could be introduced in later upgrades. Most developers on the call were in favor of making the minimal changes necessary for updating block formats in Cancun. Speaking to the larger efforts to fully convert the EL RLP serialization scheme to an SSZ format, Geth developer Péter Szilágyi said, “I don’t see this going in along with EIP 4844. I would much rather just gather everything that needs to be done so that we can roll this out in one big go and update everything that’s needed.” Ryan also expressed concerns about tooling and smart contract applications on Ethereum that could break as a result of the full conversion.
SELFDESTRUCT removal: Similar to SSZ formatting, the removal of the SELFDESTRUCT opcode is a topic that developers have discussed several times on prior calls. In fact, developers initially considered including the removal of SELFDESTRUCT as a code change for the Shanghai upgrade. Developers ultimately decided on simply including EIP 6049 in Shanghai, which does not change anything about the Ethereum protocol but acts as a warning message to smart contract developers about the forthcoming behavior change of the opcode in the future. Andrew Ashikhmin from the Erigon (EL) client team said that finally moving forward with the deprecation of SELFDESTRUCT should be a “top priority” for developers in Cancun. Geth (EL) developer Marius van der Wijden agreed the code change should be included in the upgrade. Geth (EL) developer Guillaume Ballet was also in agreement and highlighted that this code change is necessary for future upgrades, such as updating Ethereum’s data structure from Merkle Patricia to Verkle trees.
EVMMAX: Presented by Geth (EL) developer Jared Wasinger, EVMMAX represents code changes that would introduce more flexibility to the arithmetic operations and signatures schemes that could be used on Ethereum. Initially, Wasinger presented these changes as part of EOF implementation. However, he has recently decoupled them into their own standalone EIP, which can be read in detail here.
Precompile for BLS Curve Operations: Also called EIP 2537, this code change like EVMMAX represents the addition of new cryptographic signature schemes to Ethereum. This EIP in specific creates a new precompile to efficiently perform BLS signature verification and SNARK verifications. The full details of the code change can be read here.
Transient Storage: Also called EIP 1153, this code change was originally proposed for inclusion in the Shanghai upgrade. It introduces two new opcodes for reducing smart contract gas costs. Notably, the code change has already been implemented across nearly all EL clients and a dedicated test suite has been created for the EIP. In addition, the EIP is supported by several major Ethereum projects such as Uniswap, OpenSea, and Arbitrum. Details about EIP 1153 here.
Unlimited SWAP and DUP Instructions: This code change explained in more detail here can only be implemented alongside or after EOF implementation.
PAY Opcode: This code change introduces a new smart contract operation that allows users to send ETH to an address without calling any of the functions of that address. The main rationale for creating this opcode would be reduce the attack vectors and costs of ETH transfers. More details here.
Beacon State Root in the EVM: This code change exposes the Beacon Chain state for verification inside the execution environment of Ethereum. In other words, it makes data about the CL of Ethereum more accessible to smart contract applications deployed on the EL. Specifically, this EIP, dubbed EIP 4788, would enable permissionless staked ETH withdrawals by a smart contract application such as Lido or Rocketpool. About the EIP, Ryan said, “Beacon root is simple and a major win to decentralize staking pools.”
Exploring Ethereum Client Diversity
Last but not least, Pooja Ranjan from the Ethereum Cat Herders presented her group’s findings on client diversity. The Ethereum Cat Herders are a group of mostly volunteer project managers supporting the Ethereum community. Two months ago they conducted a survey of Ethereum validator node operators about the clients they were running and the reasons behind their choice of client software. There were 160 respondents. Survey respondents said they wanted to see better incentives for individual node operators, as well as a unified EL/CL application that handles operation of both clients in one application. In addition, tools to support “automatic client switching” was another feature that respondents suggested would be helpful for improving client diversity on Ethereum. Full survey results and insights can be read here.
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 2022. All rights reserved.