Ethereum All Core Developers Call #143 Writeup
Ethereum core developers concluded their 143rd bi-weekly Zoom meeting on Thursday, July 21. Unlike the Consensus Layer (CL) calls, which are attended primarily by developers building the consensus layer software of Ethereum, the All Core Developers (ACD) calls are attended by developers building either the consensus or execution layer of Ethereum. For more information about what the EL and CL of Ethereum is, read this Galaxy Digital Research report.
On Thursday, developers discussed:
Preparations for Goerli Merge activation
Shadow fork updates
Preparations for mainnet Merge activation
MEV-Boost
EIP 4444 and EIP 4844
Preparations for Goerli Merge activation
Developers have picked an activation schedule for the Merge upgrade on Goerli. The Merge is expected to activate on the Prater Beacon Chain at epoch 112260, which is expected to hit around August 4 at 12:24PM (UTC). Thereafter, the Prater Beacon Chain will merge with the Goerli testnet at a total terminal difficulty (TTD) threshold of 10,790,000. TTD is expected to hit a week after the Bellatrix upgrade is activated on the Prater Beacon Chain, so roughly sometime between August 8th and 10th. For more information about the step-by-step procedure for the Merge, click here.
Goerli will be the last major test network to undergo the Merge before mainnet Ethereum. While node operators can still practice activating their Merge set-up on any of the prior testnets including Ropsten and Sepolia, both of which have already transitioned to a fully proof-of-stake (PoS) consensus protocol, the Goerli Merge activation will be the last chance for node operators to practice running through the Merge upgrade in real time. Tim Beiko, chair of the ACD calls, said on Thursday that all client teams should aim to cut releases for the Goerli Merge by early next week so that an information blog post containing links to these releases can be published late next week.
On the CL side, Lighthouse is expected to cut a new release with Goerli Merge parameters tomorrow. Teku has already cut their release for the Goerli Merge. Updates from the Prysm and Nimbus teams will likely be shared during next Thursday's CL bi-weekly CL calls.
Developers on Thursday's call also agreed to include in the Goerli Merge client releases instructions for activating an empty hard fork upgrade on the Sepolia testnet. As explained by Geth developer Marius van der Wijden, the "mergeNetsplitBlocks" fork on Sepolia will make discovery of peers easier for node operators by ensuring that Sepolia nodes can easily verify whether or not the other peers they are connecting are on the same version of the chain as they are. This upgrade does not change anything else about the Sepolia testnet. It simply verifies the correct chain fork ID that all nodes should be connecting to. For more context about this procedure, read this tweet thread.
The mergeNetsplitBlocks fork on Sepolia is expected to activate a week after the Goerli Merge activation. The Goerli testnet will also undergo the same hard fork as Sepolia verifying the chian fork ID roughly a week after the Merge is activated on mainnet Ethereum. Ropsten will not undergo this upgrade because it is a testnet that will soon be deprecated by core developers.
Shadow fork updates
Developers activated a shadow fork of the Goerli testnet a few minutes before Thursday's call. For more information about what a shadow fork is, click here. Parithosh Jayanthi said on the call that the participation rate from validators on the shadow fork dropped from 98% to around 86% as a result of the Merge upgrade. He and other developers are still looking into what caused the nodes to drop off from the network. Jayanthi said that he doesn't believe the issues to be client software related and perhaps not even related to EL/CL client pairs but rather issues with specific instances of an EL/CL client pair such as their sync state before the Merge TTD was hit.
Near the end of Thursday's call, Jayanthi gave an update on the Goerli shadow fork state and said that certain validator nodes were able to self-heal and come back online. There will be another mainnet shadow fork to test the Merge upgrade next week. In addition, developers will be testing MEV-Boost software on the latest Goerli shadow fork over the weekend.
Preparations for mainnet Merge activation
As raised by Lighthouse developer Paul Hauner, it is important that EL client teams open up communication channels between CL and EL nodes through the Engine API well before the parameters such as TTD for mainnet Merge activation are set. This is because for security reasons mainnet Merge parameters may not be communicated to node operators earlier than 2 weeks from the expected activation date. To give more than a 2 week window for node operators to start preparing for the Merge on mainnet and set up their EL and CL client combination, it is important that EL client software enable the appropriate channels for the CL node to communicate with the EL node.
Geth, Erigon, Nethermind, and Besu, which are all four EL client teams, were in agreement about making sure this functionality is ready as soon as possible, ideally as part of the Goerli Merge client releases.
MEV-Boost
Leo Arias from the Flashbots team gave an update on MEV-Boost software development on Thursday's call. For more information about what MEV-Boost is, click here. Arias explained that the focus on MEV-Boost testing is now on preventing liveness failures as a result of the software. "The main priority," said Arias, "is not to break the blockchain." To this end, Arias gave a call for more brainstorming around the factors that could affect blockchain liveness post-Merge as a result of validators running MEV-Boost to earn MEV.
Because MEV-Boost is software that runs alongside the core EL/CL software, the impact of it on network liveness should be limited. If MEV-Boost stops working for whatever reason, then validator nodes should be able to revert back to local block building. However, there is a lack of testing around this assumption at present. In addition, MEV-Boost does rely on a trusted relay to connect validators to block builders and searchers. Flashbots will be running a trusted relay post-merge but in the case that Flashbots becomes "evil," there may be a need for a handful of third-party individuals to have the executive power to shut the Flashbots relay off.
These questions around safeguards and mitigations to preserve network liveness are posted in this GitHub repository. Discussion is encouraged. Several assumptions around how MEV-Boost should work, what happens when a trusted relay is shut down for several hours, and other extreme conditions will be tested on the Goerli shadow fork and Goerli testnet. I will say as a personal note, this is one area of testing that I think has not gotten the amount of attention and preparation as it deserves. MEV-Boost is a core software for validators post-Merge that lacks production-readiness and remains in an experimental state. Given that Merge mainnet activation may be just around the corner, possibly in late September, it's concerning to me how little MEV-Boost has been tested.
Given that MEV-Boost is added complexity to the Merge upgrade, developer Alex Stokes has been making progress on implementing an embargo on using the software alongside CL/EL software until after the Merge is considered finalized. For more context on this discussion, click here. Developers were in agreement that while the embargo should be put in place for CL client software, it does not mean there should be an embargo on Flashbots spinning up their relay. This given that some validators may override the MEV-Boost embargo and still try connecting to the Flashbots relay. Further discussion on the activation process for MEV-Boost is expected during next Thursday's CL call. Until then, Stokes requested feedback on his current embargo proposal, which is detailed here.
EIP 4444 and EIP 4844
Ethereum Improvement Proposal (EIP) 4444 seeks to limit how EL nodes store and access historical data. The main developer behind this proposal, "Henri DF", gave an update around the encoding of historical chain data in a SSZ format, which is a format used extensively already for encoding data on the Ethereum Beacon Chain. A full export of uncompressed historical chain data on Ethereum requires roughly 300GB of storage space. This EIP would rely on multiple places to host and distribute historical chain data. Beiko encouraged Henri DF to move forward with testing this encoding and decoding process using an SSZ format with the Goerli testnet especially as it undergoes the Merge upgrade. There were a lot of technical nuances to this discussion I'm probably missing. For the full details, I'd recommend checking out the livestream and these two links:
EIP 4844 introduces a new transaction type on Ethereum for supporting rollups and making the cost of rollups much cheaper on the network. There are ongoing breakout sessions for learning more about EIP 4844 development. The next session open to anyone to join will be on July 29th at 14:00 (UTC). In addition, one of the key components to enabling EIP 4844 on Ethereum is doing a trusted setup ceremony which will generate a random number for implementing in EIP 4844. To coordinate the details around this ceremony, there have been several ongoing calls. The fourth one will be held on July 21st at 11:30 (UTC). For more information about EIP 4844, click 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 endorsement of any of the stablecoins 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.