skip to content

Ethereum Consensus Layer Call #87


As part of Galaxy Digital Research’s ongoing coverage of Ethereum, we will periodically provide updates and overviews of important developer activity, including recurring meetings and calls among developers.

Key Takeaways

Ethereum core developers working on consensus layer (CL) software clients such as Prysm, Teku, Lighthouse, Lodestar, and Nimbus gathered for their 87th bi-weekly Zoom meeting on Thursday, May 19. On the call, developers discussed:

  • Preparations for Ethereum’s forthcoming transition to proof-of-stake (PoS) dubbed the Merge

  • General client team updates about the features they are working on

  • Research related to improvements and optimizations of Ethereum’s CL code specifications.

The Merge

Starting with the discussion on the Merge upgrade, developers discussed the 5th mainnet shadow fork, which was executed a few hours before the livestreamed Zoom call, and the upcoming real fork of the Ethereum Ropsten testnet. (For more information about shadow forks, read this blog post.)

Ethereum Foundation’s Parithosh Jayanthi explained on the call that the latest shadow fork was designed with an equal software client team split, meaning each of the four CL clients ran 25% of validators and connected to an equal distribution of four execution layer (EL) clients. This ensures testing between multiple different EL/CL combinations. Developers also intentionally paused certain EL and CL clients before Merge activation on the shadow fork to test the robustness of chain syncing post-Merge.

Mid-way through the call, Jayanthi updated developers about the early results of the shadow fork and said all client combinations has successfully transitioned through the Merge and were in sync with the canonical chain. The shadow fork saw 97% participation from test validators. (The 3% of validators that went offline were caused by an issue with the CL client Besu that occurred before Merge activation and was noted to be unrelated to the Merge upgrade itself.) Final results from this shadow fork are expected to be shared during next Friday’s All Core Developers’ (ACD) meeting, which like today’s CL call will be livestreamed.

Ropsten Fork

Next, developers will be activating the Merge upgrade on the Ropsten testnet, which is the first of three testnets that will be upgraded before Ethereum mainnet. Developers decided on the ACD meeting last Friday on May 13 that the Ropsten testnet would be forked around June 8. However, the total terminal difficulty (TTD) that was set during last Friday’s call was announced on today’s call to be inaccurate and likely to occur later in June. (For more information about what TTD is click here.) Chair of the ACD meetings, Tim Beiko, offered three suggestions:

  1. Developers could keep the TTD the same and simply dedicate more hashpower to the Ropsten testnet such that the Merge still activates around the time of June 8.

  2. Revise the TTD value to be lower. This creates the risk of the Merge activating on Ropsten too early.

  3. Do a mix of both Options 1 and 2, which means setting a lower TTD value but one that is expected to hit only a few days after June 8. In this case, developers would in theory need to dedicate extended amounts of hashpower to the Ropsten testnet for a shorter period than Option 1 alone.

CL developers agreed that this was a decision they would table for the ACD call next Friday. Related to this discussion, Beiko said that he plans on publishing a blog post on the Ethereum Foundation website formally announcing the Ropsten fork in June with general instructions on how testnet users can upgrade their nodes and help test the Merge. Ideally, Beiko said, all client CL teams should aim to release software updates for the Ropsten fork by next Wednesday. This gives users the following weekend to configure their nodes for the Ropsten fork, Beiko mentioned on the call. Representatives of the CL client teams including Prysm, Besu, Lighthouse, and Nimbus all concurred.

Client Updates

Developers also discussed the latest updates and projects each CL client team is currently working on.

  • Nimbus’ latest software release includes support for proposer boosting and BLS threshold signatures. For more information about the former, read this blog post. About BLS threshold signatures, the representative on the call explained that this new feature was designed primarily with staking pools in mind. Instead of allocating a single cryptographic key required for signing off on all validator responsibilities, staking pools can use BLS threshold signatures to raise the security of validator operations by requiring 5 out of 8 or some other threshold to approve validator operations on-chain.

  • The Lighthouse team is working on improvements to Ethereum’s proof-of-stake message propagation protocol known as gossipsub. For more information about that, read this Twitter thread. Michael Sproul on the Lighthouse team has also been publishing new updates to his methodology for identifying CL client types known as blockprint. For more information on blockprint, click here.

  • The Teku team is working on optimizations related to memory consumption of their software and the proposer-builder API, which is an interface for CL clients to source blocks built by external entities such as Flashbots. For more information, click here.

  • The Prysm team has recently released a new version of their client with important bug fixes and code optimizations. They are working with the Optimism team on Ethereum’s short-term scalability roadmap post-Merge. For more information, click here.

  • Lodestar is working on implementing light client specifications and preparing for an audit of their code repository. They aim to have a new version of their software released sometime next month.


Developers discussed two ongoing areas of research for Ethereum’s CL specifications: deprecating the step parameter and enabling validator exits through withdrawal credentials.

As proposed by Jacek Sieka, head of research development at Status, the step parameter used to return data about finalized blocks on the Beacon Chain will be deprecated because of a lack of use by clients and complications to client implementations that are created when it is supported in terms of block data storage. This was widely agreed on during the call. Relatedly, Sieka will speak next Friday during the ACD call about a new addition to returning data about finalized and non-finalized blocks from EL clients, which is explained in more detail here.

The second research topic that was discussed was about validator deposits and withdrawals. There was some discussion about how to simply the stake depositing process post-Merge, though nothing firm was decided on. In addition, developers discussed how to enable validator exits using validator withdrawal credentials. Currently, Beacon Chain validators are operated by two cryptographic public-private key pairs; one set, called the signing key, allows a user to operate the validator and sign off on validator attestations and block proposals. The other set, which is called the withdrawal key, will be required by a user to transfer their validator’s balance once staked deposit withdrawals are enabled on the network.

However, at present, only the signing key is required to initiate a validator exit and halt validator operations. The withdrawal keys can then be used to transfer a validator’s exited balance from the Beacon Chain to a user-controlled account. As such, for delegated staking solutions where users staking 32 ETH retain control of their withdrawal keys but hand over control of the signing keys to a third-party staking service provide, the power to trigger an exit is not necessarily held by the owner of the funds holding the withdrawal credentials. Developers discussed on the call ways to rectify this issue such that hostage situations with users’ stake on delegating staking platforms can be avoided.

Developers ultimately agreed to keep discussing the matter and research potential solutions.