Ethereum All Core Developers Call #149 Writeup
On November 10, 2022, Ethereum developers gathered for their 149th All Core Developers (ACD) call. Chaired by the Ethereum Foundation’s Tim Beiko, the ACD calls are one of two bi-weekly meeting series where Ethereum developers discuss and coordinate changes to the protocol of Ethereum. This week, developers discussed progress on code changes related to Ethereum Virtual Machine Object Formatting (EOF) and proto-danksharding for the network’s first major upgrade after the Merge dubbed Shanghai. Four other Ethereum Improvement Proposals (EIPs) were also discussed for potential inclusion in Shanghai on the call. While each proposal does present some unique merits and benefits to Ethereum, developers disagreed strongly about which EIPs should be prioritized for Shanghai. In addition to Shanghai discussions, developers briefly touched on the topic of censorship resistance and the potential tradeoffs being made to Ethereum’s censorship resistant qualities for the sake of network scalability.
Shanghai Planning
During the prior ACD call, Ethereum developers agreed on a core list of EIPs for inclusion in Shanghai. Full call notes from ACD Call #148 here. Notably, from this list of core EIPs, developers agreed to include staked ETH withdrawals in Shanghai and did not commit to including EOF or proto-danksharding in the same upgrade until these latter two code changes are further fleshed out. On the topic of EOF specifically, developers had been on the fence about whether to partially implement EOF through a small subset of EIPs in Shanghai or try to bundle the full vision for EOF in an upgrade after Shanghai.
EOF Implementation
Danno Ferrin, principal software engineer at Hedera, gave an update on this week’s call on the progress being made for EOF implementation in Shanghai. He explained that the preference by developers was to bundles most EIPs related to EOF implementation in one large upgrade sooner rather than later. The EIPs being considered for inclusion in Shanghai related to EOF implementation are EIP 3540, 3670, 4200, and 4750. There remains disagreement among developers about whether EIP 5450 should be included in the list of EOF-related code changes.
Andrew Ashikhmin of the Erigon Execution Layer (EL) client team also expressed concern about whether the Solidity smart contract language team would be able to fully support and implement all four (or potentially five) EIPs in Ethereum’s main programming language. Ashikhmin emphasized the importance of first confirming ready implementations of these EIPs from the Solidity team before committing to activating them in Shanghai. It is “an essential sanity check,” said Ashikhmin on the call. Marius van der Wijden of the Geth EL client team agreed.
Proto-danksharding
Developers then moved on to discussing the latest developments in proto-danksharding. Unlike EOF implementation, there is only one EIP associated with this code change and that is EIP 4844. Diederik Loerakker, more commonly known as “Protolambda”, is a researcher at OP Labs. Loerakker said there were still a few items under discussion related to EIP 4844. Ansgar Dietrichs of the Ethereum Foundation added that some of these items are related to setting a minimum price for blob transactions and decreasing transaction throughput for blobs in Shanghai. These to-do items are summarized on Github here.
Disabling Self-Destruct and Other Potential EIPs
In parallel to the work being done by developers to prepare EOF and proto-danksharding for Shanghai, developers tentatively agreed to continue looking into four other EIPs for inclusion in Ethereum’s next upgrade.
EIP 4758, Disabling the “selfdestruct” opcode on Ethereum: Developers revisited the conversation from last ACD call about deactivating an opcode that has widely been considered by developers to be bad practice to use in smart contracts and decentralized applications (dapps). The opcode is one of the few legacy opcodes left that has a fixed gas cost to deploy but potentially unlimited storage costs to the network. Independent developer Micah Zoltu reiterated that certain active smart contracts on Ethereum still use the selfdestruct opcode and disabling the opcode would break functionality. There may be workarounds for these special edge cases and more community outreach by the Ethereum Foundation is needed, said Tim Beiko.
EIP 1153, Addition of transient storage opcodes: Representatives from the Uniswap and Optimism teams presented a compelling case for introducing transient storage opcodes, which behaves identically to regular storage opcodes on Ethereum except that the values of these two new opcodes, TLOAD and TSTORE, would be discarded after every transaction. There are number of motivations for transient storage, one which as explained by Optimism’s Mark Tyneway is to save on gas costs. This EIP could potentially save end-users $3mn/year in gas costs on Uniswap alone. In addition, the use of transient storage over regular storage would help to reduce Ethereum’s technical debt. The Uniswap and Optimism teams have done a lot of work to help create the implementations for this code change in multiple different Ethereum software clients and have built out a comprehensive test suite for the EIP. Daniel Lehrner of the Besu (EL) client team expressed his gratitude on the call for the work of external developers in preparing EIP 1153 for implementation. Even so, not all developers agreed that the additional testing load from including EIP 1153 was worth it. Geth developer Marius van der Wijden warned that EIP 1153 may interfere and cause complications to the work being done for preparing EOF-related EIPs. That said, van der Wijden said he was still “on the fence” about the increased testing efforts for this code change. Developers agreed to proceed with testing EIP 1153 for inclusion in Shanghai with the help of external developers from the Uniswap and Optimism teams.
EIP 2537, Addition of BLS precompile: Ethereum Foundation’s Alex Stokes presented on the merits of adding BLS precompiles to Ethereum. Stokes explained there are many reasons for this including the ability to create more secure cryptographic proofs, better interoperability with the Ethereum Beacon Chain, and increased functionality of decentralized staking pools. Van der Wijden agreed that the addition of BLS precompiles was an important code change, one that might even take precedence over EOF implementation and EIP 1153. However, due to the large amount of testing required to implement EIP 2537, van der Wijden said he was worried the addition of this code change would delay Shanghai. Ethereum Foundation’s Jared Wasinger mentioned that he was working on a parallel EIP that could offer a simpler implementation path than EIP 2537. Developers agreed to look into EIP 2537 and start paring down the number of different BLS precompiles for potential inclusion in Shanghai.
EIP 2294, Addition of an explicit bound to chain ID size: Finally, Zainan Victor Zhou, a software engineer at Google, presented on EIP 2294. The code change is relatively simple and simply limits the byte size of Ethereum’s chain ID field, which is traditionally used to help node discovery after a hard fork. Due to the likelihood of a sharded and multi-chain future for Ethereum, the use case for chain IDs will grow bigger and more important, said Victor Zhou on the call. To prevent people from taking advantage of this field by trying to store other types of data in the chain ID field, Victor Zhou called for an explicit bound to the chain ID size. All developers agreed this change was important and easy to implement. Micah Zoltu highlighted that such a code change only requires a soft fork, meaning that Ethereum client teams can implement the change on their own respective timelines without having to coordinate a specific block height for the change. There was some discussion around whether to limit the chain ID size to 64 or 256 bits at the tail end of the call. Tim Beiko encouraged developers to take the discussion offline and hash out the number asynchronously on Discord chats.
Based on the growing list of EIPs slated for inclusion in Shanghai, developers disagreed about which EIPs outside of the core list to prioritize. An Ethereum Foundation developer that goes by the pseudonym of “lightclient” proposed sticking with withdrawals and prioritizing only one other major EIP, be it proto-danksharding, EOF implementation, or one of the four presented on the call. Tim Beiko agreed that it was unrealistic to try and bundle EOF implementation, proto-danksharding, BLS precompiles, and the addition of transient storage opcodes all in the next upgrade. Due to the lack of time on the call, Beiko tabled the discussion on Shanghai planning and encouraged developers to be prepared to discuss the highest priorities for Shanghai outside of staked ETH withdrawals during the next ACD call.
Increasing Operational Costs of Running an Ethereum Node
During the conversation around Shanghai, independent Ethereum developer Micah Zoltu raised an important discussion item about Ethereum’s censorship resistance. Zoltu explained that practically no end-users of Ethereum run their own node to execute transactions. All of them rely on centralized services such as Infura or Alchemy, which actively censor users from specific countries and censors decentralized applications (dapps) on Ethereum such as Tornado Cash. For all the efforts that developers are pouring into increasing Ethereum’s scalability through EIP 4844, there is a lack of effort to reduce the costs of running an Ethereum node and encourage greater guarantees of censorship resistance on Ethereum. Mikhail Kalinin, developer for Ethereum’s Teku (CL) client team, proposed focusing on reducing the costs of running an Ethereum node after the implementation of EIP 4844. Erigon’s Andrew Ashikhmin argued that Ethereum developers could focus on both at the same time. Ansgar Dietrichs said that for pragmatic reasons, Ethereum developers should compromise on censorship resistance in the short-term for scalability and focus on censorship resistance in the long-term.
Dankrad Feist, researcher at the Ethereum Foundation, suggested that the marginal increase in operational costs for node operators because of EIP 4844 was negligible and would not materially damage Ethereum’s censorship resistant qualities. Feist also added that most Ethereum users do not operate their own node not because of the cost but because of the poor user experience. Diederik Loerakker said that scaling should be the priority for Ethereum developers for the sake of creating higher levels of decentralization because code changes like EIP 4844 would make Ethereum cheaper to use and reduce the barrier to entry for more people around the world.
Lukasz Rozmej of the Nethermind EL client team also questioned whether EIP 4844 would negatively impact Ethereum’s censorship resistance if it makes it harder for Ethereum validators to censor individual user transactions, since many of these transactions would theoretically be executed on a Layer-2 rollup. Zoltu explained that while EIP 4844 may make it harder for validators to censor individual transactions in the future, the operations of Layer-2 rollups at present are centralized and therefore censorable. Wrapping up this discussion, Tim Beiko said that work to improve the user experience for running an Ethereum node should be an area of focus for the community moving forward. Instead of adding more to the resource-constrained plate of Ethereum core developers, Beiko suggested that developer teams adjacent to Ethereum core developers help simplify running an Ethereum node and work to make it more accessible for average users.
Miscellaneous
There were a few discussion items that Ethereum developers did not have time to bring up on the call. They included:
Engine API spec improvement proposal: Teku developer Mikhail Kalinin has created a proposal for improving Ethereum’s Engine API specifications. As background, the Engine API is the software that enables easy communication between the EL and CL clients of an Ethereum node. The proposed changes to the Engine API may be discussed during next Thursday’s Ethereum CL call.
Shanghai "Core" vs prototypes devnet: Testing EIPs for Shanghai will require the creation of several dedicated test networks. Shandong is one test network launched by the Ethereum Foundation JavaScript Team that already implements EIP 4895, 3860, 3651, and 3855 in addition to a few EIPs related to EOF implementation. During the next few ACD calls, developers will coordinate the creation of more dedicated test networks for client teams to test Shanghai EIPs.
Ropsten sunset date: Afri Schoeden, one of the developers maintaining the Ethereum test network Goerli, has created a proposal for launching and deprecating Ethereum test networks on a planned timeline. This is in response to frustration among application developers and infrastructure providers at the deprecation of multiple Ethereum test networks with only a few weeks’ notice. Developers are encouraged to share their thoughts around how to responsibly deprecate public Ethereum test networks like Ropsten in this Ethereum Magicians thread.
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.