eth2 update 019: We’re so close!

Heyo! It’s Ben or b17z (bits) here again with the final edition of the eth2 updates. Once this releases, we’ll just be about a few days away from the expected Mainnet Merge date (which you can keep track of at Bordel) and we’ll be in a new world! The eth2 updates will transition to be a series of posts about life after the Merge, the Ethereum Roadmap and whatever folks want to see!

Today we’re talking about two things

• The Bellatrix Upgrade

• And potential risks surrounding the Merge

• 425,425 Active Validators as of Monday, September 12, 2022

• 13,613,484 Staked ETH, or around 11% of the total supply, worth roughly $23 billion as of Tuesday September 12, 2022

• Average Validator Balance of 33.8 ETH

• Average Daily Validator Income for Monday, September 11: 0.003829 ETH

• Total Validator Income for September 11: 1631.58 ETH

Figures are from Beaconchain and Beaconscan.

Let’s recall what the Bellatrix Upgrade is one last time.

This is a Consensus Layer upgrade that will enable Ethereum to accommodate blocks containing transactions from the Execution Layer. However, unless the TTD (accumulated mining difficulty of all blocks that have been processed by the network) is reached on the Execution Layer, it will not let the Consensus Layer start filling up Beacon blocks with transactions from the Execution Layer. Once the hard fork is completed, the Consensus Layer nodes will begin listening for a TTD via the Engine API. 

So, how’d the upgrade go? 

Pretty well! Participation rate went from around 99% to 95%. But that’s about it. This does suggest that Bellatrix gave some validators some issues such as not upgrading their clients. But as you can see from the chart that I linked, the participation rate has come back up. This is great. 

Should we be worried about the drop in participation? I don’t think so. First, this wasn’t that big of a drop. Second, participation popped right back up. This means that validators have been hard at work trying to fix any associated issues. 

But since we’re already talking about risks, what are some of the risks associated with the Merge? Disclaimer: The risks we are about to talk about are not indicative of all the potential risks out there. These are just some that we wanted to highlight. There may be other risks that aren’t captured on this list. 

As mentioned many times before, this is the most technically complex upgrade to have ever happened in crypto. And we’ve observed many instances throughout all of tech and software that bugs and technical glitches happen. 

In the case of Ethereum, that situation is more complicated because there are different client implementations. And on top of that, there are two types of clients that need to be run for the Merge: a consensus layer client and an execution layer client that communicate via the Engine API. So there's a lot of surface area for things to glitch. Just recently, Geth had a release that was “borked” because it contained a regression that caused the state to go bad. But they quickly found the issue and released a fix.

Scary stuff but not really.

I want to remind everyone that there has been extensive testing, Merge ‘simulations’ on testnets, and shadow forking. You can read all about a lot of these in our previous posts.

• Eth2 update 018, which contains info about the Goerli Testnet Merge

• Eth2 update 017, which contains info about the Sepolia Testnet Merge

• Eth2 update 016, which contains info about the Ropsten Testnet Merge

Recall: A shadow fork is conceptually similar to a "production parallel" or devnet environment. The idea here is that a chain is forked, but instead of it having its own state, it inherits the state of the canonical network without affecting the canonical network. This shadow forking allows for more realistic stress testing of developer assumptions on syncing and state growth.

Mainnet Shadow Fork #12 recently merged perfectly. No issues. No missed proposals. Attestation rate stayed steady. All rainbows and ponies for that one. 

Client. Teams. Get. The. Job. Done.

Also, check out all the checkmarks in this checklist that outlines the tasks the dev team had to work through to make the Merge ready for Mainnet release. You don’t have to check it out since it’s all checked out (I actually cringed when I wrote this but it’s staying).  

Which brings us to operational risk. 

Hey validators and node operators. Watch your setups! Update your clients. Update your configurations. Let’s also get the job done! 

Here’s a Merge readiness checklist for y’all to double check.

Here’s another for good measure!

The participation rate going down from the Bellatrix hard fork is an operational risk. And we’ve seen a few of those in the past. Remember Revenge of the Ropsten?

An estimated 25-30% of validators went offline post Sepolia Merge because of configuration issues. This was because the Ropsten Merge TTD was reached too quickly: A miner added 20x the hash rate to Ropsten before the Beacon Chain was live at the time the TTD was chosen. Sepolia didn’t have this issue so when operators downloaded the client releases with the correct configurations, they accidentally ran the release with the TTD override, which set it back to the wrong value. 

But as mentioned before, this shouldn’t happen for Mainnet since we wouldn’t need to manually override the TTD for Mainnet and, for Ropsten, the Beacon Chain wasn’t live whereas, for Mainnet, it has been live since December 2020. But this was a bit of a breakdown in communication which is also an operational risk. 

In the September 9 Ethereum Core Devs Meeting, developers talked about having last-minute client releases for the Merge. This was in addition to the client upgrades that were officially announced on the Ethereum Foundation Blog on August 24. Remember: The Merge is set to happen sometime in the next few days with Bordel showing September 15. 

The last-minute client releases may cause confusion since it’s so close to the Merge. Part of the Merge being successful is making sure client teams and node operators are on the same page. Failure to upgrade on time can cause similar participation drop off as what happened with the Bellatrix upgrade as well as observations from previous testnet Merges and shadow forks.

Scary stuff but not really.

All the testing from everyone involved has hardened us up until this point. We got this! 

The thing about economic risk is that it leans, in part, on the technical and operational risks. If either of those two things are “borked” (I will start using this more instead of the expletives I say in everyday conversations), then we may experience an economic “borking.” But as I said above, the Merge wouldn’t be happening in a few days if there hadn't already been extensive testing and high confidence in its execution. 

Miners

This brings up the topic of miners. Miners will have to go somewhere and it might not be Bitcoin. The difficulty bomb should make sure mining becomes impossible on Ethereum after the Merge. Most Ethereum miners use GPUs whereas Bitcoin uses ASICs, more powerful processors geared towards Bitcoin mining. GPUs are too weak to profitably mine Bitcoin. According to Chainalysis, Ethereum makes up 97% of all GPU mining activity and all remaining GPU-mineable coins have a collective market cap of $4.1 billion which is 2% of Ethereum’s. 

But I haven’t really talked about the supposed Proof of Work fork(s). Note:, this has no bearing on whether or not the Merge actually happens. But it does bring up some potentially economically risky scenarios on the dApp layer. 

Potential Proof of Work Fork(s)

But before we get into that, what is the supposed Proof of Work fork? At high level these forks will be an exact duplicate of the main Ethereum chain where the transaction history, token balances, etc are preserved. So, when the Merge happens users should have access to two or more different blockchains with everything about them identical. So, does that mean money will double? Highly unlikely, because there has been very little to no signal that the dApps built on Ethereum will support anything but Proof of Stake Ethereum. The lack of support and lack of an active community should prevent these forked dApps from having any meaningful value. 

Let’s take a look at a hypothetical example using a stablecoin like USDC. USDC is pegged to USD so each USDC is intended to be worth $1 because Circle should have $1 in the bank for every USDC they put into circulation. Logically, this same value cannot be magically duplicated on a supposed PoW chain. The USD collateral backing will only exist for the officially recognized instance of USDC which is on the PoS chain. Eventually, those tokens wouldn’t be honored on a potential PoW fork. And since USDC is used as collateral in DeFi, this would likely also have a cascading negative effect on the value of those DeFi tokens. 

Dapp Layer

But back to the economically risky scenarios regarding dApps. If you’re a lender or borrower in Ethereum markets, this part would be for you. Because of the potential of getting “free” PoW Ethereum if the network forks, there are people who are borrowing ETH with the hopes of getting more “free” PoW. But as we all know, that’s not “free” because borrowing ETH costs ETH – your ETH. 

But regardless, this has driven up borrowing rates for ETH causing Aave to put out a governance proposal that was overwhelmingly supported to temporarily pause ETH borrowing. High utilization of ETH means that most of the ETH has been loaned out thus leaving little for liquidators as collateral to process liquidations of ETH borrowed position. This could increase the potential for an insolvency event. 

However, that’s just one protocol. Compound is proposing to raise max interest rates. And Euler is proposing doing nothing. 

I won’t go through all the proposals or the scenarios that have been brought up, but I will say that we don’t know how these proposals or the related impacts on the lending and borrowing markets will play out. Because Ethereum has such a robust ecosystem sitting on top of it, this presents an endless maze of scenarios and outcomes. If you’re into game theory, you’re in for a treat.

If you want to read more on this in addition to the linked proposals, here’s a tweet thread from Michael Bentley, the co-founder of Euler. And here’s a research post done by Maker that goes through market impacts. 

I will reiterate once again that this should have no bearing on whether or not the Merge actually happens and these scenarios live on the dApp layer.

Replay Attacks

However, one thing that everyday users, custody and infrastructure providers should be aware of is replay attacks. A replay attack allows for transactions or messages signed on one chain to be “replayed” on another chain. This is done through the chain ID, which is an identifier for the Ethereum network that transaction signatures use. The chain ID parameter was introduced in EIP-155. There is no guarantee that a PoW fork would adopt a different chain ID from Ethereum Mainnet so transactions intended for Mainnet could be replayed on the other chain unless the transaction nonces don’t align. Generally interacting with forked networks or airdropped tokens from them or manually trying to connect to the potential fork are a few ways you can increase your chance of falling victim to a replay attack. So, unless you know what you’re doing, it’s better not to play around with things you don’t understand. But your typical behavior on Ethereum will stay the same. This is just letting you know of a potential scenario if you choose, at your own risk, to interact with any forked networks.

I want to note that this is not necessarily a direct risk related to the Merge but more of the architecture setup. In the technical risk section, I talked about how Ethereum adopts a multi-client approach and how that may increase the surface area of potential bugs and issues when working with different clients. But a multi-client approach to validating blocks is actually a good thing. This approach makes Ethereum most resistant to potential issues, including incorrect block proposals. However, there is a risk associated with lack of client diversity where any one client may retain a super majority. 

If any one consensus layer client retains a super majority (66%) and that client incorrectly proposes a block for whatever reason, that block would be validated as ‘correct’ and all the opposing minority clients would be slashed for violating consensus even though they proposed the correct block. The chain would shortly finalize a broken version of Ethereum. 

So, the takeaway here is that you should run a minority client. Right now, it’s not at that point and it was much worse earlier in the year. As of September 8, Prysm has around a 44% stake while Lighthouse has 34%. Coinbase Cloud is committed to client diversity. Back in May, we distributed validators across roughly evenly between Lighthouse and Prysm. In the broader Coinbase organization, client split is ~31% Prysm, ~39% Lighthouse, and ~30% across other clients. It also bears noting that no one has a super majority right now or crossed the 50% danger zone. Ideally, though, every client has less than 33%. 

For a deep dive on diversity and the different scenarios, check out the Upgrading Ethereum Technical Handbook written by Ben Edgington – more specifically the Client Diversity Section.

Depending on what day the Merge happens in the next few days, I may be able to squeeze in another post (it would also be nice if we got 020), but we’ll assume this is the final edition of the eth2 updates. Thank you all for reading as I took over this a few months ago! And if you liked my content and/or writing, don’t worry! post-Merge, I will be starting off a new series on life after the Merge. Series name is still TBD. 

B17Z signing off!

This document and the information contained herein is not a recommendation or endorsement of any digital asset, protocol, network, or project. However, Coinbase may have, or may in the future have, a significant financial interest in, and may receive compensation for services related to one or more of the digital assets, protocols, networks, entities, projects, and/or ventures discussed herein. The risk of loss in cryptocurrency, including staking, can be substantial and nothing herein is intended to be a guarantee against the possibility of loss.This document and the content contained herein are based on information which is believed to be reliable and has been obtained from sources believed to be reliable, but Coinbase makes no representation or warranty, express, or implied, as to the fairness, accuracy, adequacy, reasonableness, or completeness of such information, and, without limiting the foregoing or anything else in this disclaimer, all information provided herein is subject to modification by the underlying protocol network. Any use of Coinbase’s services may be contingent on completion of Coinbase’s onboarding process and is Coinbase’s sole discretion, including entrance into applicable legal documentation and will be, at all times, subject to and governed by Coinbase’s policies, including without limitation, its terms of service and privacy policy, as may be amended from time to time.