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:
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.
Revise the TTD value to be lower. This creates the risk of the Merge activating on Ropsten too early.
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.
Research
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.
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.