Ethereum All Core Developers Execution Call #176 Writeup
On December 7, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) Call #176. Chaired by the Ethereum Foundation’s Protocol Support Lead Tim Beiko, the ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers discussed ongoing testing efforts for the Cancun/Deneb upgrade on Devnet #12. They agreed to coordinate an activation date for the upgrade on the Ethereum Goerli test network after the holidays in early January. Additionally, they agreed to begin discussions in early January on what code changes should be included in the next Ethereum upgrade, Prague/Electra.
Devnet #12 Updates
Testing for the Cancun/Deneb upgrade is well underway on Devnet #12. Parithosh Jayanthi, a DevOps Engineer at the Foundation, said that bugs have been discovered in two clients, Reth and Lighthouse, so far. Both client teams are in the process of patching. The DevOps team is focusing more testing efforts on the MEV workflow by activating MEV-Boost software across more validators on Devnet #12. Jayanthi said that his team has found at least one bug in the Flashbots’ MEV relay implementation. Danny Ryan, an Ethereum Foundation researcher, stressed that additional tests will be needed to check the fallback mechanisms for validators to local block building in the event of relay failures.
Moving on to client team specific upgrades, Terence Tsao, a developer for the Prysm client, said that his team is working on the revamped design for blob propagation discussed on ACDC #122. Tsao affirmed that the Prysm client will be ready to join Devnet #12 for testing next week, potentially the week after next. Justin Florentine, a developer for the Besu client, said that Besu is ready to move on from Devnet #12. Representatives from the Nethermind, Erigon, Lodestar, and Teku client teams echoed the same readiness to move ahead to testing the upgrade on public Ethereum testnets.
Based on client readiness, Beiko recommended coordinating a hard fork date as soon as developers return from the holiday break. Assuming no major bugs are discovered in clients on Devnet #12 in the coming weeks after the addition of the Prysm client, Beiko said Cancun/Deneb activation on Goerli could tentatively happen some time by mid-January. Ben Edgington from the Teku team asked developers whether they were confident about the change to target blob count per block from two blobs to three. Ryan suggested additional testing for the increased blob target on a large-scale shadow fork and during Cancun/Deneb activation on Goerli. Beiko affirmed that upgrade activation on Goerli would be “the last significant test” for the three blob per block target. Assuming no issues are discovered, developers will move ahead with the increased blob count for mainnet activation.
In summary, Beiko said that developers will continue to test the upgrade on Devnet #12 between now and the end of the holiday season. The DevOps team will launch at least one shadow fork of Goerli before the end of December in preparation for the real hard fork on Goerli some time in January. Once developers have reconvened in the new year, they will discuss a date for Goerli hard fork activation.
Builder Override Flag
Then, Tsao asked the status of client teams on their implementation of the builder override flag. The builder override flag is a new Boolean field in the Cancun upgrade that execution layer clients can use to indicate to consensus layer clients that validators should fall back on local block production instead of a third-party builder due to the detection of censoring activity by builders. As highlighted by Tsao, the implementation details for how to detect censoring activity by builders is subjective and intentionally left up to client teams to design. For more information on the builder override flag, refer to prior call notes here and here.
A pseudonymous developer for the Geth client team by the screen name “Lightclient” said that his team had implemented to the flag but would not be merging it in an official release any time “in the near future.” Representatives from the Besu and Nethermind teams indicated that they had not implemented the optional flag within their clients. Tsao highlighted that the flag could be a useful tool to implement sooner rather than later to dissuade and discourage staking pools or large validator node operators from engaging in certain “timing games.” Tsao explained that validators can earn more MEV, maximal extractable value, from delaying block propagation and with the introduction of blobs post-Cancun upgrade, delays to block propagation will be created. Instead of including blobs in blocks during these delays, validators may choose to include more lucrative MEV transactions, which is suboptimal for timely blob propagation.
Affirming that blob transactions will have to compete with regular transactions for inclusion in a block, a developer from the Prysm team with the screen name Potuz added, “Blobs not only need to compete with fees, but they also need to compete with that delay itself and all the MEV that you can get out of delaying your block. This is a market that I think wasn’t prevented or thought of when the fee mechanism for blobs was designed.” Tsao said that he would resurface this issue for further discussion in the Ethereum Research Discord. Additionally, Ryan highlighted a recent post on the Ethresearch site about the topic of timing games by Ethereum Foundation researchers Caspar Schwarz-Schilling and Mike Neuder.
Process Items
Next, Beiko shared three updates related to the Ethereum upgrade planning process. First, as discussed on ACDC #123, Beiko has created a Meta EIP document for the Cancun/Deneb upgrade, which lists all of the Ethereum Improvement Proposals (EIPs) that have been included in Cancun/Deneb. It has been created on GitHub with an EIP number of 7569. Additionally, Beiko has created EIP 7568 as the Meta EIP documents for all prior upgrades for which developers did not create a dedicated document tracking the list of EIPs included in an upgrade. EIP 7568 will link to upgrade code specifications.
Second, Beiko announced that he has created a new discussion thread on the Ethereum Magicians site to scope out the next network upgrade, Prague/Electra. He asked that developers think critically about whether to couple the EL and CL upgrades together as they have for the last two hard forks. The activation of certain code changes such as EIP 7002 will require changes on both the EL and CL and thus, will require coordinating Prague and Electra upgrades at the same time. However, for other code changes such as Verkle trees, there are ways to re-work the implementation to only require an upgrade to the CL.
Ryan notes that CL developers in parallel to Verkle trees are also working on code changes to support data availability sampling. Rather than going into the details of all the EIPs that developers would like to see in the Prague/Electra upgrade, Beiko recommended that developers review all candidate code changes over the holidays and be ready to discuss them in earnest in January. Potuz agreed with this sentiment and added that an EIP to address Ethereum’s validator set size growth issue would be an important code change to add to Prague/Electra. Based on the complexity of a code change, Beiko recommended that for certain EIPs such as Verkle or data availability sampling, developers organize dedicated meetings after the holidays to discuss these larger protocol changes in detail.
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 2023. All rights reserved.