Ethereum All Core Developers Consensus Call #103 Writeup
On February 23, 2023, Ethereum developers gathered for their 103rd All Core Developers Consensus (ACDC) call. Chaired by the Ethereum Foundation’s Danny Ryan, the ACDC calls are one of two bi-weekly meeting series where Ethereum developers discuss and coordinate changes to the protocol of Ethereum. ACDC calls focus primarily on development for the consensus layer of Ethereum, while the other meeting series, All Core Developers Execution (ACDE) calls, focuses on coordinating code changes to the execution layer of Ethereum. To read a summary of last week’s ACDE call, read this Galaxy Research report.
This week, consensus layer (CL) client teams discussed progress on testing for the Shanghai and Capella upgrade. Developers have started to test MEV-Boost, builder, and relay software a few test networks where the Shanghai upgrade has been activated like the Zhejiang testnet and Devnet 7. Tim Beiko, Chair of the ACDE calls, has published the official blog post announcing the date and final client releases for the upcoming Shanghai activation on the Sepolia testnet. Beiko also shared that next week EIP 4844 Implementers’ Call will be cancelled. This bi-weekly meeting series which focusses on development for the Deneb upgrade will reconvene on March 7.
Testing Shanghai & Capella
Barnabas Busa, a DevOps Engineer at the Ethereum Foundation, said Devnet 7 was deprecated Thursday morning, February 23, after processing 359,000 validator withdrawal credential changes and testing a number of different client releases. He stressed that the client versions running on Devnet 7 were not the final versions put out by the various CL and EL teams. Therefore, Busa recommended spinning up Devnet 8 in early March after the Shanghai upgrade on Sepolia to test final client releases. Busa also mentioned that Devnet 7 was useful for catching minor issues and bugs in the clients.
Then, Paritosh Jayanthi, another a DevOps Engineer for the Ethereum Foundation, gave an update on how testing is going on the Zhejiang testnet. He highlighted that MEV-Boost software is being tested alongside staked ETH withdrawals and so far, no issues have been identified. The next step, according to Jayanthi, is to test MEV-Boost software under edge case conditions on a dedicated devnet. To that end, Mainnet Shadow Fork #2 (MSF#2) for Shanghai testing was launched yesterday, February 22, and sometime next week, Shanghai will be activated on MSF#2, where developers will start to stress test MEV-Boost software under more extreme network conditions.
More MEV-Boost Testing
Mario Vega who is also employed by the Ethereum Foundation and assisting with the testing efforts for the Shanghai upgrade shared an update on new Hive tests for Ethereum clients. As background, Hive is a system for running integration tests or simulations to test client logic and behavior under specific conditions. During last week’s ACDE call, Vega had said he would work on creating Hive tests to assess the behavior of clients in the event MEV-Boost software fails. Vega affirmed that the circuit breaker mechanism, which is the mechanism that ensures validators can fall back on local block production in lieu of MEV-Boost blocks, for the Lighthouse, Teku, and Prysm (CL) clients were working. However, there were issues with this logic when tested on the Nimbus and Lodestar (CL) clients. Full results from Vega’s Hive test can be read here.
Danny Ryan highlighted that the issues could be because technically the circuit breaker logic of falling back on local block production after a certain number of consecutively missed slots is not implemented uniformly across all clients. “We decided before Bellatrix that the circuit breaker logic would be left client to client on the parameters and how they perform that. So, it’s not specified that it is a must and it’s not specified exactly how many slots [before the circuit breaker logic kicks in],” said Ryan on the call. A representative from the Lodestar team affirmed that the Lodestar client does implement circuit breaker logic for MEV-Boost and would investigate why they still failed to pass Vega’s Hive test. A representative from the Nimbus team affirmed that the Nimbus client does not implement the circuit breaker logic as of yet.
Terence Tsao from the Prysm (CL) client team said that it would be useful to also create Hive tests for assessing client logic in block value comparisons. “For Prysm, we’re currently comparing block value that [if] they use MEV-Boost, we’ll compare the block value from your local block and the builder block and then choose the one that’s the highest value. I’m wondering if any other [client] plans on doing that and whether we can actually integrate this type of test case into Hive because I think this is a great test,” said Tsao. A representative of the Teku (CL) client team affirmed that their client also compares local and MEV-Boost builder block values. The Teku client team is also looking at extending this logic to include multipliers that allows validators to choose MEV-Boost builder blocks only if the block value is two times or some multiple higher than a local block’s value. Based on the amount of support for this type of logic in CL clients, Vega agreed to add a new Hive test for assessing the logic in block value comparisons.
Chris Hager from the Flashbots team also gave an update on new releases of MEV-Boost software for validator node operators in lead-up to Shanghai. The primary maintainer of MEV-Boost software is Flashbots. Hager said his team was wrapping up minor updates and pull requests to the MEV-Boost relay repository and a final release for the software would be ready by early next week. He encouraged client developers on the call to take a look at their documentation. Hager said the final releases for MEV-Boost would be tested on both the Sepolia and Goerli testnets before Shanghai activation on mainnet Ethereum.
Planning Cancun & Deneb
After discussions on Shanghai and Capella testing, developers briefly discussed confusion in the versioning for Beacon API specifications. Paul Harris, a blockchain protocol engineer at ConsenSys, posted on the meeting agenda saying he’d like to release a checkpoint for Beacon API specifications for the Capella upgrade but several changes to those specifications for the Deneb upgrade are already bleeding into the documentation. Danny Ryan said that he would reach out to Harris separately and discuss the matter further.
On the topic of planning for Deneb, the next upgrade after Shanghai & Capella, CL client teams have put out a new release for the upgrade, which includes cryptography and naming updates, as well as new test cases. Danny Ryan also highlighted ongoing work on PR 3242 which aims to remove extra code logic for handling empty blob transactions. Ryan encouraged developers on the call to chime into the discussion if the logic around empty blob transactions should be changed. Finally, Beiko reminded developers that the next EIP 4844 Implementers’ Call would be cancelled and reconvene on March 7.
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.