Ethereum All Core Developers Call #148 Writeup
After a month-long hiatus, Ethereum developers gathered for their 148th All Core Developers (ACD) meeting. Chaired by the Ethereum Foundation’s Tim Beiko, these ACD calls are one of two recurring meeting series where developers plan and coordinate protocol-level upgrades to Ethereum. This week, developers discussed priorities for Ethereum’s next planned upgrade dubbed Shanghai. Developers agreed that at a minimum, testing for Shanghai would include staked ETH withdrawals and three other minor network optimizations. In addition, developers agreed to continue scoping out Ethereum Improvement Proposal (EIP) 4844 and Ethereum Virtual Machine Object Format (EOF) code changes for potential inclusion in Shanghai as well.
Shanghai Planning
The core EIPs that developers largely agreed should be prioritized for Shanghai were:
EIP 4895: Supporting validator withdrawals from the Beacon Chain through the creation of a new system-level operation type
EIP 3860: Limiting the maximum size of initcode, which is the code that creates bytecode, and applying extra gas cost for its growth on-chain
EIP 3651: Starts the coinbase address, that is the address receiving the block reward, warm such that it does not cost more in gas fees to access the address
EIP 3855: Introduces a new instruction called “PUSH0” that pushes the constant value of 0 to help reduce smart contract code size
In addition to these core EIPs, developers agreed that two other potential categories of code changes that may be included in some form for Shanghai are proto-danksharding and the implementation of EOF.
Proto-danksharding
Also called EIP 4844, proto-danksharding introduces a new transaction type to Ethereum for settling batches of transactions from Layer-2 rollups in a cost-effective way. Representatives from the Besu and Nethermind (EL) client teams expressed concern on the call about the readiness of EIP 4844 for implementation, saying that the complexity and scope of the code change had not yet been sufficiently defined. Lukasz Rozmej from Nethermind said the code change may create “a lot of tension and uncertainty” for his team if the specifications for proto-danksharding are subject to change. To this, Ethereum Foundation researcher Ansgar Dietrichs said that final decisions for the scope of EIP 4844 could be made in the next four weeks. Dietrichs emphasized that only small questions remain around the implementation of proto-danksharding and “if there was a desire to, we could make a final call [soon.]”
Implementation of EOF
The implementation of EOF is essentially an upgrade to the Ethereum Virtual Machine, which is the execution environment that deploys smart contracts on Ethereum. It introduces a new version of the EVM that better distinguishes code from data and in this way introduces significant gas savings for contract deployment, among other benefits. Formatting contracts for a new version of the EVM requires several code changes, only two of which, EIP 3540 and EIP 3670, were originally slated for inclusion in Shanghai.
On the call, Geth developer Marius van der Wijden expressed concern about partially implementing EOF through only a subset of EIPs in Shanghai. This would mean that developers must maintain backwards compatibility with several versions of the EVM if the implementation of EOF happens in a piecemeal fashion. “We can very easily shoot ourselves in the foot with this,” said van der Wijden. Tomasz K. Stanczak of the Nethermind team agreed that EOF formatting should not be “rushed to mainnet.” Andrew Ashikhmin of the Erigon team and Dankrad Feist of the Ethereum Foundation also agreed saying that it would be ideal to implement all EOF-related EIPs in one go rather than across multiple hard forks. To this, Alex Beregszaszi, one of the main EIP authors pushing for the implementation of EOF in Shanghai, did agree that only implementing part of EOF in Shanghai would be significantly less valuable than the full set.
Disabling Self-Destruct
There was also some discussion around the addition of EIP 4758 to Shanghai. This code change deactivates the “selfdestruct” opcode on Ethereum. As explained on the call by Geth developer Peter Szilagyi, selfdestruct is one of the last opcodes on Ethereum that has a fixed gas cost but can contain an unlimited storage cost on the network. It has been labelled as an opcode that smart contract developers should avoid using under most circumstances. However, as mentioned by Micah Zoltu, there is a prominent decentralized application that does rely on this opcode and would not be in favor of deactivating the selfdestruct in Shanghai. To this, Ethereum Foundation’s Jared Wasinger said that he would investigate ways in which EIP 4758 could be included in Shanghai in such a way that it addresses concerns of breaking functionality in existing Ethereum smart contracts.
Shanghai Testnets and Timing
Based on the discussion, Tim Beiko suggested the creation of a core Shanghai test network that would include the basic code changes such as staked ETH withdrawals slated for activation in the next network upgrade. Those EIPs include EIP 4895, 3860, 3651, and 3855. For reference, there is already a bare bones test network known as Shandong that has been launched by the Ethereum Foundation JavaScript Team. It implements all five EIPs in addition to a few EIPs related to EOF implementation.
In parallel to these efforts, Beiko suggested the creation of two other test networks: one dedicated to the continued development of EIP 4844 and the other dedicated to the full implementation of EOF. In this way, Ethereum client teams can focus on preparing the core components of the Shanghai upgrade and down the road, after further scoping of proto-danksharding and EOF, the code changes for either of these initiatives can be added to the main Shanghai test network if developers agree that they are ready for implementation on mainnet.
Developers also discussed the approach of splitting up Shanghai and its core components into multiple smaller upgrades, rather than one large one. A representative from the Teku (CL) client team expressed his preference for enabling staked ETH withdrawals first and EIP 4844 in a latter upgrade. This would give time for CL client teams to focus on cleanups and refinements to the Ethereum Beacon Chain post-Merge before focusing on the addition of new several new features. However, Geth developer Peter Szilagyi pushed back on this idea, explaining that developers had been trying to execute smaller hard fork upgrades on Ethereum on a quicker cadence but the realities of testing and reaching consensus for even a small upgrade makes it extremely difficult to shorten the cadence of hard forks on Ethereum meaningfully.
“Sometimes it’s worth cramming one more feature than to wait it out,” said Szilagyi on the call. Echoing the thought, Geth developer Marius van der Wijden explained that executing a hard fork only with staked ETH withdrawals could mean that Shanghai Part One happens in February and Shanghai Part Two, which focusses exclusively on proto-danksharding, happens sometime in September. Bundling these two upgrades together, according to van der Wijden, would mean that Shanghai could happen sometime in June or July. As such, while van der Wijden prefers smaller hard forks in theory, he admitted that a larger upgrade makes more sense on Ethereum for the sake of accomplishing more in the same time frame.
Shanghai Fork Activation
Developers then briefly discussed the activation process of Shanghai. As background, Ethereum hard forks have historically been activated on a predetermined block height. However, for the Merge upgrade in September, Ethereum’s transition to a fully proof-of-stake consensus protocol was activated by a terminal total difficulty threshold. Read more about the activation process for the Merge here. Now that the Ethereum network has fused together with the Beacon Chain, upgrades to the CL of Ethereum will be activated at a predetermined epoch number, which can be calculated and expressed in a timestamp format. As such, for upgrades impacting both the EL and CL of Ethereum, there was discussion about activating upgrades on the EL of Ethereum through timestamps instead of a block height. While some developers were in favor of this, it was clear that more testing around the edge cases for activating upgrades on the EL of Ethereum through a timestamp is needed. As such, Tim Beiko suggested further experimentation on the Shanghai core test networks of this fork activation strategy in the coming weeks.
Beiko also highlighted that EIP authors would be able to join forthcoming ACD calls to present their thoughts on other code changes that client teams should consider for inclusion in Shanghai outside of the ones mentioned on this week’s call.
Miscellaneous
Finally, developers raised three other minor topics on this week’s call.
Marius raised a minor change to the Ethereum Wire Protocol which defines request and response messages for exchanging data between Ethereum clients. Marius proposed the addition of a message standard for communicating new transaction types and sizes between clients. This is an important update to the Ethereum Wire Protocol for enabling proto-danksharding.
Tim Beiko made a call for client teams to review a change to Ethereum’s Engine API, which dictates communication between EL and CL clients. This change would enable validators to easily compare the value of a locally built block with the value of a block built by a third-party block builder. This is a code change that will be discussed in more detail during next week’s CL call.
Afri Schoeden, one of the developers maintaining the Ethereum test network Goerli, expressed concern over the supply of Goerli testnet ETH. Schoeden explained on the call that at present, it is easier for users to buy Goerli testnet ETH than simply to receive it from a faucet, meaning a dedicated channel for issuing testnet ETH supply. There are a number of solutions Schoeden has proposed to this issue of testnet ETH supply on Goerli that will be discussed during a public community call next Tuesday, November 1. Schoeden encouraged client teams to review his post and attend the call.
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.