Ethereum All Core Developers Execution Call #162 Writeup
On May 25, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) call #162. Chaired by the Ethereum Foundation’s Tim Beiko, the ACDE calls are a bi-weekly meeting series where Ethereum client teams discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers discussed the results of an impact analysis on Ethereum Improvement Proposals (EIPs) 4758 and 6780, progress on EIP 4844, and potential inclusion of EIP 5920, 5656, and 7069 in the Cancun upgrade.
Self-Destruct Removal Impact Analysis
Neville Grech, Director of Dedaub, presented the results of an impact analysis on EIP 4758 and 6780. Dedaub is a blockchain security firm that was commissioned by the Ethereum Foundation to assess the frequency and use of the self-destruct opcode by decentralized application (dapp) developers and maximal extractable value (MEV) searchers. EIP 4758 and 6780 are two different proposals for deprecating the self-destruct opcode, the former being simpler in design affecting a higher number of smart contracts and the latter being comparatively more complex but less impactful on existing applications. The impact analysis reads, “We are of the opinion that the impact of EIP-4758 and EIP-6780 is manageable and perhaps a net positive due to the simplicity of the implementations of Ethereum Clients, especially if EIP-6780 is selected.”
As background, the self-destruct opcode sweeps the entire balance of ETH from an address to a beneficiary address. Unlike the call opcode, self-destruct does not execute any code associated with the beneficiary address, meaning beneficiary addresses that have implemented a block on token receive functions can still receive balances from a sending address if the action is initiated through self-destruct. Additionally, self-destruct clears the runtime bytecode of the sending address, as well as resets the sending address’ nonce and all storage vars to zero. EIP 4758 renames the self-destruct opcode to “sendall” and removes the functionality of clearing runtime bytecode, nonce, and storage var resets from the sendall operation. EIP 6780 does not rename the self-destruct opcode but instead adds a condition to the operation logic where if the opcode is executed in the same transaction as the creation of the smart contract, the functionality of self-destruct remains unchanged. In all other circumstances, the self-destruct opcode does not delete any bytecode or reset any values.
If EIP 4758 were to be deployed on Ethereum today in May 2023, a handful of dapps on Ethereum would break. However, most of these dapps are upgradeable, meaning the functionality of these dapps could be updated to accommodate new opcode logic. If EIP 6780 were to be deployed, most dapps on Ethereum would be able to operate without modifications. Notably, the impact analysis also stated that in the instances where self-destruct is called, it is often called in conjunction with the create or create2 opcodes which are used to deploy smart contracts on Ethereum. Further, self-destruct is called most frequently by short-lived smart contracts, that is contracts that are created and destroyed in the same transaction. The following table summarizes the frequency of instances when self-destruct has been called between blocks 15mn to 17.23mn:
Results from Dedaub Self-Destruct Impact Analysis
Source: Dedaub
An Ethereum developer by the screen name of William Morriss said that the impact analysis report by Dedaub does not explain the common usage pattern of self-destruct by MEV searchers and decentralized exchange (DEX) traders. In a written statement, Morriss said, “Any actor trying to get competitive transactions included with any urgency must participate in priority gas auctions. Offchain systems are being built to allow anyone to participate in these auctions. Such auctions are denominated in gas used, so any upgrade mechanism with any gas overhead whatsoever cannot be used competitively. That leaves code replacement as the only viable mechanism for traders. Suppose I want to be able to upgrade my code in order to trade on the newest protocol. It is much simpler now when I am able to replace the code. Without this ability, I would need to redeploy to a new account instead.”
Morriss added that the ability to replace code without calling into external contracts is an important capability that self-destruct and create used in conjunction make possible. To preserve this capability after the removal of self-destruct, Morriss has proposed the creation of a new instruction known as “setcode.” Setcode is defined within EIP 6913. On the call, Ethereum developers raised concerns around the security and testing requirements associated with EIP 6913. Some of these considerations are outlined in writing here. Geth (EL) developer Marius van der Wijden asked whether EIP 6913 could be implemented in a hard fork upgrade after the activation of EIP 6780. While ideally the two EIPs would be activated together in the same hard fork, Morriss confirmed EIP 6913 could technically come later. Van der Wijden and Erigon (EL) developer Andrew Ashikhmin were both in favor of activating EIP 6780 as soon as possible in the Cancun upgrade and analyzing EIP 6913 for consideration in a future hard fork after Cancun.
EIP 4844 Updates
Next, developers discussed progress on EIP 4844, proto-danksharding. A Geth (EL) developer that goes by the screen name “lightclient” explained there was a discrepancy between the calculations used to determine the “excess_data_gas” and “base_fee” fields for blob transactions. His proposal for aligning the gas pricing information for blobs is outlined here. Tim Beiko, Chair of the ACDE calls, recommended that developers review the proposal and be ready to discuss it during next Monday’s EIP 4844 coordination call.
Then, Alex Stokes, researcher for the Ethereum Foundation, talked about an update to block validity rules that clearly specify the maximum number of blobs per block. The update is outlined here. No concerns were raised about the change and developers agreed to incorporate it into EIP 4844 implementation specifications posthaste.
Developers also discussed preparations for the next EIP 4844 testnet, Devnet #6. Barnabus Busa, DevOps Engineer for the Ethereum Foundation, explained that the previous testnet, Devnet #5, recently underwent “a long period of non-finalization” where 900 validators were forced to exit. Devnet #5 has since recovered and new validators have been added to the testnet. Busa said that he is open to including new features and code changes to EIP 4844 specifications for Devnet #6. Lodestar (CL) developer Gajinder Singh proposed several cleanups to transaction network payload references. His full proposal can be found here. Tim Beiko suggested that the full list of code changes for Devnet #6 be discussed during the forthcoming EIP 4844 coordination call, along with any other outstanding changes to EIP 4844 specifications that have been proposed but not yet discussed.
The last topic on EIP 4844 was on the decision to remove SSZ serialization formats from the EL implementation of proto-danksharding. For background on this decision, read the call notes from ACDE #161. Based on the removal of SSZ, Beiko recommended also removing the SSZ-related EIPs, that is EIP 6475 and EIP 6493, from the list of proposed EIPs for the Cancun upgrade. The list of proposed EIPs for Cancun is outlined here. There were no objections to the removal of SSZ-related EIPs from Cancun.
Cancun Opcode Allocation
Danno Ferrin, Principal Software Engineer at Hedera Hashgraph, presented a comprehensive document organized proposed EIP opcodes for the Cancun and Prague (EL) hard fork upgrades. The document lists the names of proposed opcodes, their descriptions, and a methodology to assign opcode prefixes. William Morriss suggested reserving space for the setcode opcode in the document. Tim Beiko asked where the document should live. Lightclient explained that a list of Ethereum transaction types is stored in a readme file in the Ethereum GitHub repository under a folder called “lists.” Ferrin agreed to create the pull request to move his document to the same folder.
Other EIPs Under Consideration for Cancun
Alex Stokes gave an update on EIP 4788, which enables trust-minimized access to the CL directly through the Ethereum Virtual Machine (EVM). Based on conversations from ACDC #109, Stokes has implemented EIP 4788 as a stateful precompile, rather than a new opcode. Precompiles allow complex cryptographic computations to be executed through the EVM without incurring high costs or computational overhead. Unlike previous Ethereum precompiles that have been added to the EVM over time, EIP 4788 introduces a precompile that has direct access to execution state where the Beacon block root data will be stored. There remain a few outstanding questions around the implementation of EIP 4788 as a precompile.
Assuming these questions are resolved over the next few weeks, Stokes asked whether Ethereum client teams felt strongly about including the code change for the Cancun upgrade. Beiko also asked whether Ethereum client teams felt strongly about including any other code changes outside of EIP 4788 in Cancun, outside of the three, EIP 4844, EIP 6780, and EIP 1153, that have already been confirmed for inclusion. Based on the current scope of Cancun which includes three EIPs, Stokes said that a reasonable target for Cancun activation is October 2023. Lightclient affirmed this saying that the upgrade based on its current scope is "5-6 months away at least."
Erigon (EL) developer Andrew Ashikhmin was in favor of including EIP 5920, the introduction of a new “pay” opcode. Ethereum dapp developer Charles Cooper was in favor of including EIP 5656, an efficient EVM instruction for copying memory areas. Marius van der Wijden was hesitant about including EIP 5920 in Cancun due to the large amount of testing needed for the code change. Alex Beregszaszi, Solidity team lead at the Ethereum Foundation, was in favor of including EIP 7069 for revamping Ethereum call instructions. Due to limited time, Beiko suggested that developers revisit the conversation around the scope of the Cancun upgrade during a future call. He also suggested that future conversations around expanding Cancun scope be limited to the following five EIPs: EIP 5920, 5656, 7069, 4788, and 2530.
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.