Ethereum Consensus Layer Call #94 Writeup
On Thursday, August 25, Ethereum core developers concluded their 94th 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 of Ethereum. Over the last several months, these bi-weekly calls and the All Core Developer (ACD) calls, which occur every other Thursday, 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 94th CL call, developers discussed the challenges and common points of confusion for end-users configuring software for the Merge. As background, in preparation for the Merge, users running computers connecting to the Ethereum blockchain will need to configure two software clients, one for the Ethereum mainnet, also called the execution layer (EL), and a second for the Beacon Chain, also called the consensus layer (CL). To secure communication between these two clients, users must generate a JSON web token (JWT) for authenticating an application programming interface known as the Engine API. Finally, for users running validators, they must set a fee recipient address to which transaction fees and maximal extractable value (MEV) can accrue after the upgrade is activated on mainnet.
Since Tuesday, the final client releases for all EL and CL client teams have been released. However, Raul Jordan from the Prysm (CL) client team mentioned on the call that many of their users preparing for the Merge on mainnet with the newly released software had been unaware of the need to run a second client for the EL of Ethereum. Tomasz Stańczak from the Nethermind (EL) client team echoed these sentiments sharing that he also had received negative user feedback when it came to the complexities around configuring nodes for the Merge. The more education material for node operators in lead-up to the Merge the better, said Stańczak. To this, Chair of the CL calls Danny Ryan highlighted a few resources for users to rely on when setting up for the Merge. They were:
A few other resources for node operators were discussed on the call. Ryan added that developers would be hosting their 7th Merge Community Call on Friday, September 9th. While node operators can attend this call to ask questions around node configurations, ideally users should aim to resolve issues before the activation of the Bellatrix hard fork on September 6th, which is when the first part of the Merge upgrade is scheduled to activate. Technically, the Bellatrix hard fork only requires node operators to upgrade their CL clients. However, a little over a week later, the Paris upgrade, which is the second part of the Merge, is scheduled to activate on Ethereum and this does require the full dual client set-up for node operators to follow along. As such, Micah Zoltu emphasized that waiting until the 9th may not leave enough time for syncing newly configured EL clients. The Nethermind (EL) client team is working on a one click node setup tool for Ethereum node operators called Sedge. The project is still in beta mode, though some parts of it may be stable enough for solo stakers to use for their Merge preparations. Developers also discussed potential changes to the Engine API to make it easier for users to locate their JWT and use it for authenticating communication between their EL and CL clients.
Other Merge Updates
Ethereum Foundation’s Parithosh Jayanthi said on the call that developers had successfully completed their 11th mainnet shadow fork. For details around what a shadow fork is and how it is used to test the Merge upgrade, click here. While the shadow fork went well overall, Marius van der Wijden from the Geth (EL) client team mentioned that there were still issues with the blocks produced by the Erigon (EL) client team on the shadow fork. Jayanthi said that the Erigon team is aware of the issue and is actively trying to identify and patch the bug.
Speaking of bugs, between now and September 8th, the Ethereum Foundation’s bug bounty program is quadrupling in value. Depending on the nature of the bug discovered and its impact to the live network, bounty hunters can earn up to a million dollars for identifying issues with the Ethereum Merge code in advance of the upgrade.
The Nethermind (EL) client team said that they were continuing to face issues with empty blocks when paired with the Lodestar and Nimbus (CL) clients. The Lodestar and Nimbus teams are working on a fix but Nethermind’s Łukasz Rozmej said his team plans to implement a hot fix for the issue from their end in case the fixes from Lodestar and Nimbus are not ready in time for the Merge. This hot fix can then be reverted in a new release after the Merge, said Rozmej, adding that he didn’t want Nethermind to be discarded as an option for node operators to run in lead-up to the Merge because of the issue around empty blocks. While final client releases for 4 EL clients and 5 CL clients have been released for the Merge, these clients vary in terms of reliability and functionality. As such, it is important for node operators to choose their EL and CL clients wisely taking into consideration the performance of these clients on prior Ethereum testnets and shadow forks.
Developers are planning on executing their 12th mainnet shadow fork with the latest mainnet releases from all EL and CL client teams. It is likely that the Erigon and Nethermind client teams will have another release for users to run as an option for the Merge in addition to the releases that were put out this week.
MEV-Boost Updates
Raul Jordan from the Prysm (CL) client team mentioned an ongoing research initiative to remove the need for trusted relays in MEV-Boost. As background, MEV-Boost is a three-part software that connects external block builders to Ethereum validators for the purposes of decentralizing and distributing MEV rewards. Using a threshold encryption scheme, third-party block builders may be able to directly sign and propose blocks to validators in a private manner such that centralized relays are not able to censor blocks or steal the MEV in blocks. This would be an intermediary measure before enshrined proposer builder separation (PBS) is ready for activation on Ethereum. Enshrined PBS is the long-term goal for upgrading MEV-Boost. It would remove the need for centralized relays entirely from Ethereum. Developers agreed to keep the discussion going around how to use threshold encryption in MEV-Boost in communication channels like EthResearch.
CL client teams also gave an update on Thursday’s call about their circuit breaker functionality for MEV-Boost. For more background on this conversation, read our prior developer call writeup here. Both Prysm and Teku client teams have implemented circuit breaker functionality. For Prysm, validators who fail to propose blocks for 3 slots consecutively or fail to propose blocks for 8 slots within an entire epoch will automatically disconnect from using MEV-Boost. For Teku, validators that miss 8 slots within an epoch automatically disconnect from MEV-Boost. Lodestar’s circuit breaker functionality remains a work in progress while the Nimbus team will likely not have an implementation for an MEV-Boost circuit breaker.
EIP 4844 Updates
Ethereum Improvement Proposal (EIP) 4844 is a code change envisioned for inclusion in the hard fork upgrade following the Merge. It is designed to improve Ethereum’s scalability by making the cost of processing transactions through Layer-2 rollups cheaper. To learn more about rollups, read this Galaxy Digital report. Developers discussed two outstanding questions related to activating EIP 4844 on Ethereum post-Merge. The first was related to Etheruem’s fee market. Under EIP 4844, a new transaction type would be created and the fee market for these types of transactions would be different from that of user-initiated transactions. The fees for rollup-initiated transactions is envisioned to be dynamically calculated on Ethereum similarly to the base fee for regular transactions. However, it remains unclear whether the base fees for roll-up initiatied transactions would be better calculated and optimizied for short bursts of rollup-initiated transactions or a constant stream of them. More context on this discussion here. Developers agreed to continue thinking through this question in the coming weeks.
The second outstanding question around EIP 4844 that was discussed on Thursday’s call was on whether syncing rollup-initiated transactions, also called “blobs,” should be coupled with block syncing. Danny Ryan’s preference was to keep these two syncing activities separate. This would ensure one syncing process does not hold up the other and introduce greater forward compatibility for future scalability improvements to Ethereum related to rollups. This preference however does introduce more complexity to the network since syncing Ethereum blocks will not necessarily mean that nodes are also syncing rollup-initiatied transactions. Even so, developers seemed more in favor of tackling the cumbersome solution for syncing blobs sooner rather than later. Developers were encouraged to continue thinking about the sync strategy for EIP 4844 in the coming weeks.
Social Slashing Updates
Finally, Micah Zoltu, founder of an Ethereum customer service application called Serv.eth, raised his concerns around censorship resistance on Ethereum. He once again pleaded with developers to help spread the word about the potential for retroactively punishing validators on Ethereum that go against the rules of the protocol. To be clear, validators already can be automatically penalized and slashed under certain conditions by the Ethereum protocol. However, the protocol is not able to immediately detect all types of malicious validator behavior, such as the activity of transaction censorship. In the event of transaction censorship, Ethereum core developers could in theory support a user activated fork of the network that retroactively removes the stake of offending validators. This capability called “social slashing” was discussed in detail during last week’s ACD call. To read the writeup of last week’s call, click here.
During the ACD call last Thursday, Zoltu had floated the idea of Ethereum core developers preparing and writing the software needed for social slashing in advance. During this week’s CL call, Zoltu said that his plea was for developers to simply raise awareness about the potential for this kind of activity to happen on Ethereum if staking providers do start censoring user transactions. The concern around staking providers censoring user transactions stems from the fact that already several decentralized finance applications, Ethereum infrastructure providers, and most notably the largest Ethereum mining pool, Ethermine, has started to proactively censor user transactions. This behavior was in response to recent sanctions placed against the Tornado Cash privacy tool on Ethereum. Stablecoin issue Tether announced this week that it would not be prematurely freezing user addresses that interact with the Tornado Cash protocol.
Instead of preparing the software for social slashing, developers reaffirmed the conditions that would provoke such activity. In short, any activity from validators that go against the fork choice rule of Ethereum and intentionally reorganizes blocks to censor out certain transactions is a slashable offense. However, it remains unclear how much support there would be for social slashing in the event that compliance with U.S. sanctions does become a requirement for regulated staking providers and other Ethereum-based services. Given that user transactions on Ethereum already are to a large extent censored on different levels of user interaction with the network, it is unclear that censoring activity by staking providers would indeed provoke social slashing. It is more likely that compliant and non-compliant staking providers co-exist on Ethereum without pushback. It will likely fall upon end-users and the broader Ethereum community to uphold the censorship resistance of the protocol by proactively choosing and supporting permissionless applications and services built atop Ethereum.
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.