Ethereum All Core Developers Call #145 Writeup
Ethereum core developers concluded their 145th All Core Developers (ACD) call on Thursday, August 18. Developers reconfirmed the schedule for mainnet activation of the Merge upgrade which will fully transition Ethereum from a proof-of-work (PoW) to a proof-of-stake (PoS) consensus protocol. For more information about this transition and its importance on Ethereum, read this Galaxy Digital research report. The latest projections for the Merge upgrade estimate its activation on mainnet around September 15. However, this date may fluctuate in accordance with changes to network hashrate and as such, it will be important for developers to keep an eye on hashrate in the coming weeks. Next Tuesday, an official blog post from the Ethereum Foundation will be published containing the final software releases for the Merge.
In addition, developers discussed at length on this call mitigation strategies around network censorship by state sized actors. This conversation was sparked in light of recent U.S. sanctions placed against Tornado Cash, a smart contract privacy tool on Ethereum. To read more about the regulatory action taken against Tornado Cash and the fall out from this event, read this Galaxy Digital Research report. Micah Zoltu, founder of an Ethereum customer service application called Serv.eth, raised two specific issues related to network censorship. First, Zoltu raised the concern around censorship of transactions on Ethereum by MEV relays. MEV relays are software that connects validators to third-party block builders. For more background around the MEV infrastructure on Ethereum post-Merge, click here. Second, Zoltu raised the concern around censorship of transactions on Ethereum by large staking as a service providers such as Coinbase and Lido.
Censorship by MEV-Boost Relays
To kick off the discussion, chair of the ACD calls Tim Beiko emphasized that several people on the call may not feel comfortable sharing their opinions around censorship resistance publicly or live during a recorded meeting. As such, silence from participants on the call should not be taken as a stance on the topic at hand. In addition, Beiko said that the purpose of the ACD calls is to discuss potential code changes to the Ethereum protocol and their technical merit, not necessarily debate the philosophical or ethical merit of these code changes. Finally, Beiko asked all developers to be respectful and charitable to one another when debating each other’s views on the topic of censorship resistance.
With that disclaimer out of the way, developers first discussed the importance of encouraging validators to connect to relays that are not censoring transactions. Since the sanctioning of Tornado Cash, it has become more widely known and understood by the Ethereum community that Flashbots, a relay operator, has and will continue to censor transactions that it processes from MEV searchers. Currently, searchers propose transaction bundles containing MEV rewards to the Flashbots relay. Miners connect to Flashbots using specialized software called MEV-Geth and includes bundles from Flashbots when building blocks on Ethereum. Miners still have the power to include other transactions directly from the Ethereum mempool in the blocks they are building.
However, post-Merge, the Flashbots relay will start to connect to validators instead of miners. Validators will be the main stakeholder on Ethereum for proposing and processing transactions on Ethereum. Instead of processing transaction bundles, the Flashbots relay will only accept entire blocks built by third-party block builders. This means that validators connecting to Flashbots will not have a choice when it comes picking and choosing which transactions to include in a block. They will hypothetically only be able to accept or reject a block containing only transactions Flashbots has deemed as compliant with their rules and guidelines, which do include abiding by U.S. law and sanctions.
A member of the Flashbots team acknowledged on the call that flexibility around appending new transactions to a block created by a third-party block builder could be a new feature added to the MEV-Boost software on Ethereum post-Merge. However, in lieu of such a solution, Flashbots has open-sourced this week their software for running a relay. The hope is that this will encourage more relays to be built and operated on Ethereum post-Merge, some of which may not censor their block builders and transactions. Zoltu highlighted on the call that Bloxroute, a blockchain infrastructure company, will be running a MEV relay for validators to connect to that will not censor its users or transactions. In addition, MEV protocol Manifold Finance is reportedly also working on building a relay for validators that is censorship resistant though it is unclear how close the team is to being able to launch the software.
Zoltu said on the call that developers should exert their social influence and promote the use of relays that do not censor transactions post-Merge. Marius van der Wijen, developer on the Geth (EL) client, agreed with this sentiment and added that he encourages users not to run MEV-Boost software at all. While this would mean forgoing profits that validators could earn through MEV, this would help validators avoid the problem of relays that censor transactions such as Flashbots. Still, this type of behavior is asking validators to act altruistically, which is not what most validators will likely do in practice, especially staking providers that have promised users to maximize yields from staking.
Ethereum Foundation developer Danny Ryan noted that solutions to the problem of relays that censor transactions should not include removing the optionality of running MEV-Boost software in general. Ryan noted that this would simply result in different versions of MEV-Boost software being run by different validators without any standardization and could introduce more risks to the Ethereum protocol. On the topic of censorship resistance from the protocol level, founder of Ethereum Vitalik Buterin explained there are two types of censorship attacks with differing degrees of probability. The first is censorship through a soft fork of the network. 51% of active validators could start to validate an alternative version of the Ethereum blockchain that does not contain certain transactions. This would require a significant amount of coordination and effort by validators. The second is censorship through excluding transactions from individual blocks. This is the more likely possibility on Ethereum because of relays like Flashbots. Validators connecting to Flashbots may only process blocks that do not contain certain transactions. However, so long as there are even a few active validators that do not run Flashbots or connect to a censorship-resistant relay then even non-compliant transactions on Ethereum would still be able to get processed eventually. As such, Buterin emphasized that the more likely concern around censorship on Ethereum would not be easy to pull off and would require all active validators on Ethereum to become compromised.
In summary, developers generally agreed that competition between relays and the fact that there will be a relay run by Bloxroute that does not censor transactions like the Flashbots relay will help preserve Ethereum’s censorship resistance post-Merge. In addition, it was mentioned on the call that relays choosing to censor transactions may face social backlash from the Ethereum community and be less competitive in comparison to other relays that process all Ethereum transactions and therefore have more opportunities for creating MEV.
Censorship by Staking Providers
In the event of transaction censorship not by MEV relays but large staking as a service providers such as Coinbase or Lido, Zoltu explained on the call that one course of action developers could take to punish such behavior is social slashing. This refers to coordinating a hard fork on Ethereum that causes offending validators to lose their locked collateral of 32 ETH. To be clear, there are certain behaviors on-chain that will cause validators to get slashed and lose a portion of their collateral. For example, proposing competing blocks is a slashable offense. However, there are certain behaviors that the Ethereum PoS protocol does not automatically penalize and the Ethereum community could mobilize to manually penalize through a hard fork.
Łukasz Rozmej, developer from the Nethermind (EL) team, pushed back on this idea as potentially setting a dangerous precedent. While such a capability could be used to halt bad actors on the Ethereum network, it could also potentially be used to force validators to comply with any host of other rules not directly built into the protocol. Zoltu agreed with this sentiment and suggested that developers coordinate a clear statement around when social slashing would be appropriate. Ansgar Dietrichs and Dankrad Feist, both Ethereum Foundation researchers, agreed that this kind of clarity would prevent social slashing from being used inappropriately. However, other developers believed social consensus should be the primary defense against censorship by major staking providers. Similar to how validator node operators will be encouraged to choose censorship resistant relays and the competition between these relays would ideally favor the ones that are not censoring transactions, Tomasz Stanczak of the Nethermind (EL) team said that it should be up to users to support the staking providers that do not censor transactions. Unfavorable legislation that forces staking providers to censor transactions should cause staking providers to relocate to other parts of the world. It is unclear at the moment whether legislation in the U.S. will require staking providers to censor transactions on Ethereum but this is a possibility that developers agreed on the call they should prepare for.
Some developers on the call were in favor of building the software in advance for social slashing. However, there was not complete consensus around this idea. In lieu of a formal statement or action from developers on the call, certain developers gave their individual perspectives on censorship by large staking providers. Marius van der Wijden, developer from the Geth (EL) client team, said, “I think it’s very important for each and everyone to form their own opinion and say, ‘Okay, this is what I want Ethereum to be like.’ My personal opinion is if we allow censorship of user transactions on the network, then we basically failed, and this is the hill I’m willing to die on. If we start allowing users to be censored on Ethereum then this whole thing doesn’t make sense and I myself will be leaving the ecosystem and maybe start something different that provides these guarantees and I think there are a lot of people that think the same thing. I think censorship resistance is the highest goal of Ethereum and of the blockchain space in general so if we compromise on that there’s not much else to do in my opinion.”
Miscellaneous
The Sepolia testnet, which was the second major Ethereum testnet to undergo Merge activation in July, was expected to undergo a minor hard fork upgrade this week. However, due to the low amount of validator participation on Sepolia the network has yet to reach the required block height to upgrade. The network will upgrade at block #1735371. The updated estimation for when this block height will be reached is on August 21. All node operators on Sepolia are encouraged to upgrade their software to the latest release before August 21. The upgrade is designed to improve node discovery on Sepolia and ensure that any non-upgraded nodes are forcefully removed from the network. Further background on this upgrade here.
Ethereum developers concluded their 11th mainnet shadow fork testing the Merge upgrade. For more background on what a shadow fork is, click here. Parithosh Jayanthi, developer at the Ethereum Foundation, said on the call that this was one of the “nicest” shadow forks that the developers have executed. Validator participation rate only dropped slightly from 99.8% before the Merge upgrade to around 96% after the upgrade was complete. There was only a single node that was not able to follow along with Merge upgrade. This node simply did not have sufficient time to sync to the network during the upgrade, according to Jayanthi. There were a handful of invalid blocks produced by the Erigon (EL) software client. The Erigon team said on the call that they were still investigating this issue.
Parithosh Jayanthi, developer at the Ethereum Foundation, proposed on the call deprecating the Kiln testnet slightly earlier than expected to save on costs and resources going into maintain the network. Originally, developers had agreed to deprecate Kiln as a testnet for Ethereum during or shortly following the Merge upgrade on mainnet. Developers agreed on today’s call to deprecate the testnet during the Bellatrix hard fork on Ethereum, which is expected to activate on September 6. Jayanthi highlighted that there was no meaningful transaction activity on the chain or decentralized applications actively testing software on Kiln. As such, he felt confident about suggesting a slightly earlier deprecation to save on money and time going into maintaining the Kiln testnet. Chair of the ACD calls Tim Beiko affirmed that he would include the announcement around the Kiln testnet deprecation in next Tuesday’s blog post, along with all the final client release for the Merge upgrade on mainnet.
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.