eth2 update 017: Goerli incoming! Mainnet shortly after?

July 19, 2022

By Ben Rodriguez

Heyo, it’s Bienvenido, Ben, b17z – whatever you want to call me. And we’re back with the Eth2 updates! There’s a lot to talk about so let’s get right into it.

  • The Sepolia testnet merged successfully

  • Which means Goerli is up next and stands as the next and last dress rehearsal with a tentative target date of August 11, 2022

  • The Gray Glacier upgrade that delays the difficulty bomb to Mid September 2022 was successful

  • 20-25% of the validators dropped offline after the Sepolia Merge due to configuration issues 

  • How to avoid TTD being hit too early: Single vs. Dual Merge Release

Beacon Chain Traction

  • 409,107 Active Validators

  • 13,091,313 Staked ETH, or about 10-11% of the total supply, worth roughly $19-20 billion as of Monday, July 18, 2022

  • Average Validator Balance of 33.66 ETH

  • Average Daily Validator Income for July 17: 0.003848 ETH

  • Total Validator Income for July 17: 1575.39 ETH

The Road to Mainnet Merge

Sepolia testnet merged on July 6th, 2022… And then there was one

This marks yet another major milestone on the way to the Mainnet Merge. We’re so close to the end of Proof of Work. Isn’t this exciting?! But don’t you know what this means? It means only a single testnet merge remains: Goerli. If you’re running a Mainnet validator, Goerli will be your final chance to go through the process on a testnet! 

I mentioned in the previous update that “Goerli is the most battle tested so it makes sense for it to be merged after Sepolia, and as closely to before the Mainnet Merge as possible.” Goerli has the most user and dapp activity so it will be as close to a simulation to the Ethereum mainnet as possible. 

Goerli testnet merge: Very tentative timeline

Please, note that this is not set in stone. Take what is coming as a tentative plan to help coordination.

The working theory is that Goerli will Merge on August 11. And barring anything horrible with that, the Mainnet Merge could potentially happen the week of September 19th.

For more information on this, check out Ben Edgington’s PoS Implemeters’ Call Notes for 7/14

It’s happening y’all!

So, what about the difficulty bomb delay? 

Gray Glacier Upgrade Successful

In the last update, we talked about how it was decided to delay the difficulty bomb until mid September 2022. The Gray Glacier Upgrade was done to make that a reality and it went successfully on June 30, 2022. Block times are back to normal at 13 seconds.

I understand there was concern from folks in the community around this. Yet another delay. My take on this? Take a look at all that has been happening in the past couple of months. All the mainnet shadow forks, all the testnet merge dress rehearsals. EF and supporting teams are squarely focused now on Goerli which is as close to a dress rehearsal for Mainnet as possible. And with the tentative timelines being proposed for Goerli and Mainnet, I think it would take a catastrophic cascade of bugs for the Mainnet Merge not to happen before Devcon this year (mid October)

It’s happening y’all!

Revenge of the Ropsten: Sepolia merge could have gone better

An estimated 25-30% of validators went offline post merge because of configuration issues. 

Let’s take a trip down memory lane back to 1.5 months ago, which in the crypto world, is like 10 years: In the previous update, we talked about how Ropsten reached Total Terminal Difficulty (TTD) about 13 days too early. A miner added 20x the hash rate to Ropsten before the Beacon Chain was live at the time the TTD was chosen. 

Let’s recall what TTD is: TTD is the accumulated mining difficulty of all blocks that have been processed by the network. Ropsten was forked using this instead of block number. In addition, the Mainnet Merge will be using TTD as well. 

Why TTD? A predefined block number for the fork is unsafe. A potential attack vector may use minority hashpower to build a malicious fork chain that would satisfy the block height requirement and the first Proof of Stake block may be proposed from the malicious fork. For more information on this, check out EIP-3675

What does this have to do with the Sepolia merge configuration issues? With Ropsten node operators had to manually override the TTD. The thing is, 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. Oopsie.

Rightfully so, this raised some concerns from the community that if professional node operators have problems configuring the Merge, then what will happen when we finally get to Mainnet, especially with home stakers? My take? I don’t think it’s that big of a deal. This would have affected folks who went through the Ropsten Merge. And since it was caught on Sepolia, then this scenario is unlikely to happen again for Goerli and even less likely to happen on Mainnet because there is absolutely no scenario in which we would use the TTD override to set a temporary TTD.

However, I also think that there needs to be better awareness and tighter processes around configurations. Speaking for myself, when I was a Software Engineer, configurations were one of the many banes of my existence. But I digress. Parithosh said they’ll be working on a list of common pitfalls as well as a checklist of a properly configured node and it will be available before Goerli. I’m personally a fan of the idea of building a script that auto checks the node configuration. With that being said, Ropsten Staking Launch Pad has a Merge Readiness Checklist that you should check out!

Shadow forks

Mainnet Shadow Fork #8 merged successfully on July 5. 

Mainnet Shadow Fork #9 merged with some issues on July 14.

  • TTD was hit earlier than estimated

  • Lighthouse nodes were falling out of sync and not catching up until the next epoch, but a fix was being implemented and is currently deployed.

  • There was a configuration issue with Nimbus nodes

For more info on some of the issues, check out Ben Edgington’s notes from the PoS Implementer’s Call. 

Recall the convenient Shadow Fork Tracker to check out the details of current and past shadow forks. 

Avoiding TTD being hit too early

That’s twice we’ve talked about TTD being hit too early. We want this exact scenario to be avoided before the Bellatrix hard fork. Bellatrix will merge the current chain with the new PoS Beacon Chain. 

The Bundle: Bundle Bellatrix and TTD in one release

What happens if TTD is hit too early on Mainnet? Well, the Merge breaks. The Execution Layer will halt when it reaches the TTD until the Consensus Layer activates Bellatrix. This scenario may pop up if the Bellatrix fork and the true TTD were bundled together in a single release. 

Sounds pretty bad, doesn’t it? Well, there are two other ways to get about it.

The Ropsten Special: Single release with TTD override

There would be a single client release with a very high TTD and then once Bellatrix is activated, tell users to do a TTD override. This would provide certainty that TTD wouldn’t be hit before Bellatrix. Sounds familiar? Yeah, I called it, “The Ropsten Special” because that’s exactly what had happened during the Ropsten Merge. We also just discussed in this same post that Sepolia had configuration issues that caused 25-30% validator drop off because of accidentally setting the TTD override from Ropsten.

The Guarantee: Have one release for Bellatrix and another to specify TTD

I call this “The Guarantee” because it takes the “The Ropsten Special” further by having another release to specify TTD instead of doing a manual override. This is a super safe way to go about guaranteeing that TTD isn’t hit before Bellatrix. The problem with this scenario is that the surface area of something goes wrong in the coordination process essentially doubles. Both the Execution Layer and Consensus Layer clients each have to update twice instead of once. This also would be harder to coordinate in general. 

Every single way has some pros and cons. But let’s discuss “The Bundle” part a little further. “The Ropsten Special” only came about because a bunch of hashpower was added to Ropsten thus leading to the TTD being hit 13 days too early. I had mentioned in the previous update that this scenario would not happen on Mainnet because if any entity can add that much hashpower to mainnet, they would have the power to 51% attack Ethereum.

I think “The Bundle” is the way to go. Prioritizing simplifying user experience is more important here. Complicated user experiences are their own class of risk. I also think the risk of adding that much hashpower is infinitesimally small. If that risk was significantly higher, I would say to weigh the other options more. 

For more info on this, check out Tim Beiko’s discussion document.

That’s it for now folks! We’re so close to the Mainnet Merge! In subsequent updates, I’ll start talking about life post Merge and other innovations happening in the ecosystem. I’ll see you in a few weeks with another update. 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.