Ethereum All Core Developers Call #151 Writeup
On December 8, 2022, Ethereum developers gathered for their 151st 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 agreed to include the five Ethereum Improvement Proposals (EIPs) related to EOF implementation. As background, EOF implementation is a major code change targeting the Ethereum Virtual Machine (EVM). The EVM, sometimes referred to as the “heart” of Ethereum, is the execution environment through which all transactions on Ethereum are processed and since its inception in 2015, has not undergone major changes. EOF implementation will be the first major change to the EVM and will help the EVM become more easily upgradeable, parse between smart contract code and data, introduce gas savings for application developers, help simplify the debugging process for smart contracts, and more.
The decision to include EOF implementation with staked ETH withdrawals in Shanghai came with a few caveats. Namely, if execution layer (EL) client teams have not implemented and tested the five EIPs by January 5th, then these code changes will be dropped from the upgrade. This is to ensure that staked ETH withdrawals are not delayed by other code changes in bundled together in Shanghai. The preference of most developers on the call was to expedite withdrawals as much as possible. As discussed during an earlier call, developers are confident they could activate withdrawals, along with three minor EIPs, in March 2023. Therefore, developers agreed to stick as closely as possible to this timeline and agreed to drop any EIPs that have not already been implemented in client releases by January 5th. Developers also agreed to target a cross-client test network launch in late January and possibly mainnet shadow forks for Shanghai by early February. For background on shadow forks, click here.
Scoping out Shanghai
The main discussion of this week’s call was the scope of Shanghai. Chair of the ACD calls, Tim Beiko asked all client teams on the call to share their thoughts on what outside of the core EIPs, which are 4895, 3860, 3651, and 3855, should be included in Ethereum’s next upgrade. Team lead at the Ethereum Foundation for the Geth (EL) client team, Péter Szilágyi said, “For me personally, I kind of feel that scaling Ethereum is significantly more important than withdrawals and [if] the whole thing [EIP 4844] delays withdrawals a bit, that seems acceptable.” Ethereum Foundation Researcher Dankrad Feist, who came up with the concept of danksharding for improving Ethereum’s scalability, agreed with Szilágyi’s sentiment and added that he wasn’t sure if Ethereum client teams were even the right individuals to ultimately decide on the tradeoffs between delaying EIP 4844 to a future upgrade or not.
Speaking from the perspective of consensus layer (CL) client teams, chair of the CL calls Danny Ryan reiterated that from his point of view staggering EIP 4844 in a separate upgrade shortly after Shanghai would be a “cleaner” approach. As background, CL client teams agreed last week to work on withdrawals separately from their work on proto-danksharding, that is EIP 4844. Developers continued to go back and forth about whether a few months delay would be justified for Shanghai to include EIP 4844. Despite the skepticism from Szilágyi about the quick turnaround for a hard fork upgrade for EIP 4844 after Shanghai, developers ultimately agreed to continue to work on the code change separately from withdrawals and aim to execute a fast turn-around for Cancun, the name of the upgrade after Shanghai. To this end, Beiko has already posted a new thread on the Ethereum Magicians website to discuss what EIPs along with EIP 4844 should be included in Cancun, which would ideally be executed in May or June 2023.
To EOF or not to EOF
With the decision to exclude EIP 4844 from Shanghai out of the way, developers moved on to discuss whether the scope of Shanghai should include the five EIPs related to EOF implementation. All Ethereum EL client teams including Nethermind, Erigon, Geth, and Besu expressed support for this idea, as did a representative from the Solidity language team. Danny Ryan questioned whether a hard fork in March could be achieved with the additional burden of implementing and testing EOF EIPs along with withdrawals. Andrew Ashikhmin from the Erigon (EL) client team admitted that his team would need an extra week or two to work on EOF implementation alongside withdrawals. To this, Marius van der Wijden of the Geth (EL) client team told the Erigon team to “just put some more resources on it” and aim for being ready with their implementation in early January.
Dankrad Feist expressed frustration at the idea of including EOF EIPs over EIP 4844, especially given that EOF implementation would likely delay Shanghai to some capacity. “Are we really implementing the best version of EOF if we literally make the time pressure to freeze specs basically right now?” said Feist, adding, “It does not feel like this does not delay withdrawals. It seems very likely that this will actually delay withdrawals and so I would be extremely against coupling [EOF implementation] with withdrawals.” Feist later reiterated his frustration at the decision to exclude EIP 4844 from Shanghai on Twitter as well. To mitigate concerns about EOF implementation delaying withdrawals, Beiko suggested sticking to a strict timeline. If EL client implementation for EOF is not ready and tested by the next ACD call on January 5th, then the EOF EIPs should be dropped from Shanghai. Client teams affirmed it would not be a complicated task to remove code related to EOF from their Shanghai implementations last-minute and agreed to revisit the commitment to EOF in Shanghai in January.
More disgruntled developers
During the conversation about the scope of Shanghai, advisor to the Uniswap team, Moody Salem questioned why EIP 1153 was not being considered for inclusion. “[EIP] 1153 is ready to go into testnet, as soon as the testnet goes up. It’s implemented in three of the five clients and one of the PRs is just waiting for clarity that it will be in Shanghai,” said Salem. As background, EIP 1153 proposed the addition of transient storage opcodes. It was presented during a prior ACD call by the Uniswap and Optimism teams as an important code change that would save end-users millions on gas fees. Salem reiterated that he believes EIP 1153 is one of the only EIPs that would not delay withdrawals.
To this, Marius van der Wijden said, “One of the big issues I have with it, EIP 1153, is that from a process perspective, you [Moody] and other people from Uniswap, and Optimism have been pushing very, very hard and I don’t think it’s a very important EIP. It’s a really, really small improvement to the Ethereum protocol.” Andrew Ashikhmin from the Erigon (EL) client team also chimed in explaining that even if including EIP 1153 is not a big technical lift, the code change still takes up “headroom.” Salem later reiterated his frustration at this pushback from Ethereum core developers on Twitter.
Due to limited time on the call, Tim Beiko wrapped up the discussion about the scope of Shanghai. He reiterated the loose consensus between developers to move forward with a leaner vision for the upgrade, which will ideally include: staked ETH withdrawals, EOF implementation, warm coinbase, push0, and limit initcode. For more information about these code changes, read this prior ACD call summary.
Shanghai and Cancun add-in’s
Then developers quickly touched on a few other minor topics related to Shanghai including activating the upgrade based on a timestamp, rather than a block height. This is to ensure that the Shanghai upgrade on the EL of Ethereum does not activate asynchronously from the upgrade on the CL of Ethereum. Marius van der Wijden said he is working on the code specifications for enabling upgrades on Ethereum’s EL by timestamp, which developers can track here. Van der Wijden will also write an EIP based on his implementation in the coming weeks.
Mikhail Kalinin, Lead Researcher at ConsenSys, raised the issue of updating the Engine API’s getpayload request. Developers had discussed making it easier for validators to compare the value of a locally built block with the value of a block built by a third-party block builder. For the full details around this discussion, read this writeup of a prior CL call. Developers agreed generally to include these changes to the Engine API specifications in Shanghai.
In preparation for Cancun, Tim Beiko encouraged developers to start thinking about what outside of EIP 4844 should be included in the upgrade. Participants of the call raised several EIPs for consideration, including:
EIP 663: A clear next step to EOF implementation in Shanghai.
EIP 2537: Adds a BLS precompile to Ethereum for better interoperability with the Beacon Chain and increased functionality of decentralized staking pools. More background on this discussion here.
EIP 6046: Offers an alternative to deactivating Ethereum’s self-destruct that minimizes breakage to existing usage patterns by decentralized applications. More background on this discussion here.
EIP 5988: Adds a Poseidon hash function precompile to Ethereum, which would help zk-rollup functionality.
Progress on staked ETH withdrawals
During the beginning of this week’s call, Barnabas Busa, a devops engineer at the Ethereum Foundation, gave an update about progress for enabling staked ETH withdrawals. His updated was similar to the one he gave last week during CL Call #99. Developers are still testing the code change on two multi-client developer test networks. Withdrawals are working smoothly on both networks. Prysm and Lighthouse (CL) client teams are working towards enabling support for the test network that is based on a post-merge environment. Erigon (EL) and Nimbus (CL) client teams are working towards joining both. They expect to be ready soon. Mario Vega who is on the testing team at the Ethereum Foundation highlighted a new Hive test suite for staked ETH withdrawals, which can be found here. Based on issues discovered on the developer test networks, the Hive test suite for staked ETH withdrawals will continue to be expanded.
As an aside, all validators should specify a withdrawal address for liquid staking rewards to accrue to after Shanghai activation. During the launch of the Beacon Chain, validators were allowed to specify a Beacon Chain address where rewards could accrue. However, as emphasized by Tim Beiko in a recent Twitter thread, all validators are now encouraged to update their withdrawal credentials to an Ethereum EL address, which can be done using certain tools such as this one by Weald Technology. Partial withdrawals for rewards that accrue on top of the base 32 ETH amount will happen automatically for all validators on a periodic basis. To initiate a full withdrawal of rewards and staked ETH, validators must first enter an exit queue. More information about the exit queue can be found here.
Partial and full withdrawals will be processed on Ethereum by validator index number. A bounded sweep of the active validator will occur every block and identify a maximum of 16 withdrawals to process per block. “It will take about 100 hours to complete a full sweep through the full validator set. But many validators have old 0x00 style withdrawal credentials, so they will be ineligible for any kind of withdrawal until those are updated to 0x01. Thus, the withdrawal sweep will be quicker to start with, until most of the validators have been converted over,” explained Ben Edgington, product lead of the Teku (EL) client over Telegram.
Miscellaneous
KZG Ceremony update: The trusted setup ceremony required for implementing EIP 4844 is close to being ready. Trent Van Epps, an ecosystem person for the Ethereum Foundation, talked briefly on the call about preparations for the ceremony and how to get involved. I recently conducted a Twitter Spaces session with Trent and his colleague at the Ethereum Foundation Carl Beekhuizen about this ceremony, which you can listen to here.
Engine API versioning: Mikhail Kalinin shared his proposal about introducing versioning to the Engine API specifications. Kalinin’s proposal has been shared on prior dev calls and it outlines two different approaches to structuring Engine API specification documents. The pros and the cons for each approach are explained in more detail 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.