Ethereum All Core Developers Execution Call #152 Writeup
On January 5th, Ethereum developers reconvened after a two week break for their first All Core Developers (ACD) call of 2023. Starting in 2023, ACD calls will be renamed to ACD Execution (ACDE) calls to reflect their focus on changes to the execution layer of Ethereum. They will also be live streamed from the @EthereumProtocol YouTube channel, instead of the @EthereumFoundation YouTube channel. Chaired by the Ethereum Foundation’s Tim Beiko, the ACDE calls are one of two bi-weekly meeting series where Ethereum developers discuss and coordinate changes to the protocol of Ethereum. The other meeting series, which developers have renamed to ACD Consensus (ACDC) calls, focus on topics related to the development of the consensus layer of Ethereum.
On the 152nd All Core Developers Execution (ACDE) call, developers agreed to remove code changes related to EOF implementation from the Shanghai upgrade. For more information about EOF, read prior call notes here. They also agreed to reject any additional Ethereum Improvement Proposals (EIPs) from Shanghai in place of the EOF EIPs. This was primarily to ensure that the timeline for staked ETH withdrawals does not get delayed. As the only major code change in Shanghai, staked ETH withdrawals are currently being tested on a developer-focused test network. Developers aim to launch public testnets for the Shanghai/Capella upgrade next month and tentatively schedule a mainnet launch for the upgrade sometime in March 2023. Developers then briefly discussed the issue of different serialization methods between the EL and CL of Ethereum, as well as a new EIP to introduce the Poseidon hash function as a precompile to the EVM.
Shanghai planning
Barnabas Busa, a DevOps Engineer for the Ethereum Foundation, gave an update about the status of staked ETH withdrawals testing. He said that the current developer test network for Shanghai, which was launched just before Christmas, has already progressed to block 4,000. All EL and CL client combinations are currently running on this testnet. A few client combinations such as Teku-Erigon and Lighthouse-Erigon are experiencing issues. Busa mentioned that developers are working to launch a new developer testnet as soon as possible with the help of client teams.
Then, Marius van der Wijden, a software developer for the Geth (EL) client at the Ethereum Foundation, presented a small design change to EIP 3860, one of the smaller EIPs in Shanghai. The proposed change corrects a confusing failure mode in the EIP where an initcode limit violation results in a zero-address error instead of an OOG error. The initial motivation for this according to Pawel Bylica, a developer for the Ipsilon team at the Ethereum Foundation, was to promote user-friendliness. However, developers agreed that changing the failure mode to an OOG error, which terminates and aborts the execution instead of returning a zero-address, would create less confusion and bugs in client implementations.
EOF no more
Next, a software developer for the Geth (EL) client at the Ethereum Foundation, who goes by the pseudonym of “lightclient”, gave an update on progress around EOF implementation. As background, EOF stands for the EVM Object Format which introduces several changes to the code execution environment of Ethereum. Among other changes, the EIPs related to EOF implementations would revamp Ethereum transaction formats to differentiate between smart contract code more explicitly from data and help the EVM become more easily upgradeable in the future. Over the holiday break, lightclient said that developers working on EOF implementation met twice to discuss EIP specifications. During these sessions, developers agreed to remove one of the EIPs, EIP 6206, due to its complexity and make the data section in these EIPs mandatory, instead of optional, to marginally improve the simplicity of data parsing. Testing for EOF EIPs is also making progress, according to lightclient. Reference tests for the EOF EIPs have yet to be officially released but Martin Holst Swende, Security Lead at the Ethereum Foundation, has already started differential testing, also known as differential fuzzing, across different client implementations of EOF. “It’s not so easy to create an effect best [test] case for EOF. The problem is that there are a lot of pitfalls. For example, if you want something to fail in a certain way, in EOF, you have to be very specific and you have to make sure that the test doesn’t fail somewhere else before reaching what you really want to test. So, I think it will be really valuable [if] we centralize the errors, somehow,” said Mario Vega from the testing team at the Ethereum Foundation.
Based on the status of EOF implementation and testing, Tim Beiko raised the question of whether it was still prudent for developers to include these EIPs in the next Ethereum upgrade, Shanghai. On this topic, founder of Ethereum Vitalik Buterin expressed his worries about rushing EOF implementation without a clear roadmap for how to ensure that future upgrades to the EVM are not more cumbersome and do not add to the technical debt of Ethereum. “In the EVM it’s much hard to remove things than it is to remove other features,” said Vitalik, adding, “You have applications that are written in EVM code and if the EVM changes, then those applications can’t change. …. One of my big worries is with improvements to the EVM in particular is basically that because it’s much harder to deprecate and to actually remove stuff, a philosophy of EVM developments that allows for basically large amounts of ongoing improvements and doesn’t commit to something really close to ossification fairly soon would risk us basically creating an [EVM] V2 and then creating a V3, and then creating a V4, but still requiring V1, V2, and V3, to be part of the consensus code because we don’t have good ways of removing them.”
To this, Andrew Ashikhmin from the Erigon (EL) client team said that he was afraid that if developers delayed EOF implementation until it was “perfect”, they would also lose the momentum and opportunity to test out the implementation and get real feedback on the proposed code changes. “If we try to make it perfect, then it will be like a never-ending super project,” said Ashikhmin on the call. In response to the ongoing uncertainty around EOF implementation, Ansgar Dietrichs, a researcher for the Ethereum Foundation, suggested that developers pull the EIPs from Shanghai and commit to actively resolving these issues around implementation and the path forward for EVM upgrades over the next few weeks. Van der Wijden said that from his opinion trying to decide on EOF implementation during this week’s call felt rushed. “I feel kind of pressured into making a decision on EOF now and I don’t think that’s good,” he said. To this, lightclient admitted that based on the progress of EOF testing over the holiday break, its inclusion in Shanghai would delay the upgrade by roughly a month. “If we’re trying to do mainnet testnet upgrades in the beginning of February, I don’t think we’ll be ready by then,” said lightclient on the call.
Once developers agreed on excluding EOF implementation from Shanghai, Beiko proposed waiting another two weeks before deciding on whether EOF should be included for the upgrade after Shanghai, dubbed Cancun. During prior calls, developers had agreed to center the Cancun upgrade around EIP 4844, proto-danksharding and from Beiko’s perspective, including EOF in Cancun as well prematurely may result in confusion if EOF is again rejected from the upgrade. Lightclient pushed back on this idea and argued that if developers do not commit to EOF implementation in an upgrade like Cancun, then it will delay work towards its implementation and further take away from its development momentum. Beiko responded by saying that revisiting the issue around when to include EOF implementation, if not in Shanghai, in two weeks’ time at the next ACDE call should not significantly impact EOF development momentum. More details around the proposals from different core developers about the path forward for EOF implementation and EVM upgrades can be found here and here.
With EOF implementation out of Shanghai, Marius van der Wijden tentatively proposed the inclusion of EIP 1153 in the upgrade instead. Several developers on the call strongly opposed adding new EIPs to Shanghai to reduce the risk of delaying staked ETH withdrawals. Developers reaffirmed their commitment to try and target early February for launching public Shanghai testnets.
To RLP or SSZ
Developers also discussed a proposal by Etan Kissling, a developer of the Ethereum Nimbus (CL) client team. Kissling shared this proposal during a prior ACDC call, which is summarized here. In short, there are two fields that are encoded using different serialization formats between the EL block header and the CL execution payload header. Because these two fields are encodeddifferently, it creates additional overhead and complexity for building wallets and Ethereum light clients. One of the solutions proposed by Kissling was to add a new serialization format used in the CL known as SSZ to the EL. Alternatively, the CL client could incorporate ways to support code formatted in the serialization format found in the EL known as RLP. However, this is not ideal as the SSZ format is a more modern and updated serialization format for encoding structured data. In either case, the encoded data fields in question are relevant to staked ETH withdrawals and therefore, any changes on either the EL or CL side to ensure data formatting consistency will require additional work from Ethereum client teams. Andrew Ashikhmin emphasized that the decision around this issue is “urgent” because it pertains to Shanghai.
To give client teams more time to think about the tradeoffs between Kissling’s proposed solutions, which can be read about it more detail here, Beiko suggested that developers revisit this topic next week during the ACDC call and make a decision on what to do at the latest during the next ACDE call on January 19. The agenda for next Thursday’s ACDC call on January 12 can be found here.
EIP 5843 & EIP 5988
Finally, developers briefly discussed two new EIPs. EIP 5843 introduces efficient modular addition, subtraction, and multiplication to the Ethereum Virtual Machine (EVM). It is an EIP proposed by Jared Wasinger, a software developer for the Ethereum Foundation. Jared was not present on this week’s call, which is why developers agreed to revisit discussions around the EIP at a future date. Then, Abdelhmaid Bakhta, an Exploration Lead at StarkWare, presented EIP 5988, which introduces a new precompile to Ethereum that improves the efficiency of running zero knowledge proofs on the network. “Basically, each time we want to prove a storage proof like a Merkle proof, it’s very expensive on Ethereum because we don’t have any ZK friendly hash functions,” explained Bakhta. About this EIP, Dankrad Feist, a researcher for the Ethereum Foundation, said that in his view, it is premature to enshrine any type of arithmetic hash function to the protocol due to their contemporary nature and the unknown ramifications they could have on the security of Ethereum.
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.