Ethereum Consensus Layer Call #93
On Thursday, August 11, Ethereum core developers concluded their 93rd fortnightly Consensus Layer (CL) call. Chaired by Ethereum Foundation researcher Danny Ryan, the CL calls are one of two recurring meeting series where Ethereum developers discuss and coordinate upgrades to the protocol layer of Ethereum. Over the last several months, these calls and for that matter, the All Core Developer (ACD) calls, have focused primarily on preparations for Ethereum’s Merge upgrade. For more information about what the Merge upgrade is, read this Galaxy Digital Research report.
On the 93rd CL call, developers picked a tentative date for mainnet Merge activation. They agreed on the call to aim for releasing final software, also called client versions, for the upgrade by August 23, 2022. Thereafter, they discussed scheduling the first of two hard forks, the Bellatrix hard fork, to activate at epoch 144896 on the Beacon Chain, which is Ethereum’s proof-of-stake blockchain. Epoch 144896 is expected to hit around September 6, 2022. Finally, developers also agreed that 10 days would be a sufficient window for the second hard fork, called Paris, to activate on Ethereum mainnet at a total terminal difficulty value (TTD) of 58750000000000000000000. While TTD is an extremely hard value to estimate, it is currently expected to hit around September 16, 2022. For more background on what TTD is, read this Galaxy Digital Research report.
Other discussion items raised during the call included:
Goerli Merge post-mortem
MEV-Boost
EIP 4844
Goerli Merge Post-Mortem
The Goerli testnet was the third and final major Ethereum testnet to undergo the Merge upgrade. Developers had discussed during last Thursday’s developer call that if all went well with the Goerli Merge activation, they would feel confident about picking a tentative date for mainnet Merge activation this week. The Merge activated on Goerli roughly 12 hours in advance of the call on August 11th. Ethereum Foundation’s Parithosh Jayanthi gave a recap of what he saw on-chain. “One of the things that was peculiar about the Merge this time is that we had two terminal blocks,” said Jayanthi on the call. “We were looking at about 90% participation before the Merge and then we dropped to roughly 70% and for a couple of epochs we were below the required 66% so we didn’t finalize [the chain] for about 4 or 5 epochs.”
The activation of the Goerli Merge was less than ideal. Some nodes on the network were confused as to which block was the terminal block, that is the block created after the TTD threshold is met. In addition, the participation rate of validators dropped significantly through the upgrade causing chain finalization to be delayed for about 25 to 30 minutes. Part of the issue around validator participation rate was due to wrong node configurations. Jayanthi said that the Nimbus (CL) and Lodestar (CL) client team running nodes had not upgraded their software to the latest client release versions. In addition, there were a handful of other client-related issues impacted other nodes such as Nethermind (EL) and Erigon (EL) nodes. Further investigation is still needed on the root causes of these issues with the Nethermind and Erigon clients. For a more detailed explanation of the issues, watch the livestream of the developer call here.
On the positive side, Paul Hauner from the Lighthouse (CL) team noted that regarding his investigation of Ethereum’s fork choice rule under a PoS consensus protocol, validators had no issues sorting themselves out amid a low turnout and continued to correctly progress and build atop a canonical chain. There were some concerns around peer scoring, which is the mechanism that helps nodes judge other nodes based on their health and quality and connect to the ones with a high peer score. But overall, developers agreed the Goerli Merge was a success given that the chain did end up reaching finalization, which is a technical term to describe the completion of 2 epochs in a row, with at minimum 66% participation from validators in each epoch. It is likely that minor issues like the ones seen during the Goerli Merge activation will be seen on mainnet Ethereum. However, these issues that were identified did not prevent the chain from finalizing and as such are not expected to cause major disruptions when activated on Ethereum in September.
Following the post-mortem on Goerli, developers discussed their expectations around timing for mainnet Merge activation. As mentioned at the top of this writeup, developers ultimately agreed on a September 6th date for activating the Bellatrix hard fork and a September 16th date for activating the Paris hard fork. However, it is important to note that not all client teams felt comfortable with this decision. Andrew Ashikhmin from the Erigon (EL) client team said that he would appreciate more time to work on final software releases. To this, Chair of the CL call Danny Ryan said that EL client teams could issue a second release after the Bellatrix hard fork. This would give EL client teams at least four weeks, instead of two to prepare final releases. They would still be required to put out a feature-complete release as suggested by August 23. However, they could then release a second version in time for the Paris upgrade that is “strongly suggested” to users running the former client version. Ashikmin did not object to this strategy and other Ethereum client teams were in favor of preparing their releases for mainnet Merge by August 23.
Developers will reconfirm the values for mainnet Merge during next Thursday’s ACD call. In preparation for final releases, developers also briefly discussed the Hive test suite for Ethereum clients. These are custom-made testing environments for double-checking the behavior of Ethereum clients under specific edge case scenarios. Developers on the call noted that there were aspects of the Hive test suite that needed updating for clients such as Nethermind to use. In addition, developers briefly discussed setting a placeholder value for TTD in execution layer clients even before August 23 so that node operators could start setting up their infrastructure for mainnet Merge in advance. This is an issue that Paul Hauner from the Lighthouse team has raised on previous developer calls. However, given that a tentative TTD value has been picked. It may be more likely that certain EL client teams simply update their releases with the actual mainnet Merge TTD. However, for any EL client teams planning on releasing version before August 23, Hauner encouraged them to use the placeholder TTD value already coded into consensus layer client software for consistency in the meanwhile until the tentative TTD value picked during Thursday’s call is confirmed.
MEV-Boost
Previously, developers discussed implementing a circuit breaker design to MEV-Boost. MEV-Boost is an optional software that validators on Ethereum can run post-Merge to earn additional revenue in the form of maximal extractable value. To learn more about MEV on Ethereum, read this Galaxy Digital report. To mitigate the impact of a malicious relay intentionally withholding blocks at the last moment from validators, certain Ethereum client teams such as Lighthouse and Prysm have moved forward with implementing a circuit breaker. For validators running a Lighthouse node, 8 missed slots will trigger the validator to start relying on their own block-building process as opposed to that from a third-party relay. Prysm has left the exact number of missed slots needed to automatically disable MEV-Boost undetermined but potentially randomizable. To prevent anyone from taking advantage of a circuit breaker function, developers agreed that the exact threshold for missed slots should be different across each Ethereum CL client team. Ethereum Foundation researcher Alex Stokes emphasized that it would be ideal to have this functionality implemented before the Merge date. In addition, Stokes pointed out one minor change that would be added to the code specifications of MEV-Boost. Specifically, the specifications for third-party builders will state explicitly that the validator should be building their own block locally in parallel to the blocks they are expecting to receive from an external builder network, that is a relay.
EIP 4844
Developers ran out of time during Thursday’s call to discuss Ethereum Improvement Proposal 4844 in depth. However, it was raised as a discussion item for future calls. EIP 4844 is a code change that will likely be included in the hard fork following the Merge called Shanghai. It is designed to improve Ethereum’s scalability through the use of rollups and more specifically, by making the cost of using rollups cheaper on Ethereum. To learn more about rollups, read this Galaxy Digital report. The items for discussion were around how the network would handle the new transaction types introduced by EIP 4844. In specific, how these new transaction types should be synced and priced through Ethereum’s fee market.
Miscellaneous
One other area of discussion on today’s call was on the terminal block hash override. This was a minor change to the specifications of Ethereum execution layer clients proposed by developer Mikhail Kalinin. Most EL teams including Geth, Nethermind, and Erigon have not yet implemented the code change. As such, Danny Ryan suggested that this code change not be pushed into final client releases for the Merge. Rather, the code change should be ready for implementation in case of a network emergency. For more background on the edge cases around terminal blocks at the time of the Merge, refer to the call notes from CL call #92.
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.