skip to content

Ethereum All Core Developers Call #143 Writeup

Ethereum ACD Call -143

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.


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.