Ethereum “Gray Glacier” hard fork to merge at the end of June or drag it to September-October

The Ethereum mainnet hard fork codenamed Grey Glacier is coming. This is a fork that delays the difficulty bomb. Time is tight, so be sure to update your Eth1 nodes as soon as possible. The fork is expected to take place on June 29 Occurs around the day, or maybe a day or two earlier.

Ethereum "Gray Glacier" hard fork to merge at the end of June or drag it to September-October

About the Ropsten Testnet Merge

We have successfully completed the PoS merger of the Ropsten testnet.

After a long wait due to hash rate fluctuations, you can watch our merge time at the EthStaker party‌, Ropsten finally completed the merge at 16:08:08 UTC and produced its first merged block.

Is this merger perfect? Pari provides a good summary‌, in a nutshell, we lost about 14% of our engagement, of which, about 9% was due to a simple misconfiguration in the Nimbus team node, which was easily fixed, 1.8% Was due to a known issue in Nethermind, which was fixed by restarting, 2.5%-3% was due to a communication issue between Besu and Nethermind (caused by websockets), which was fixed by switching to HTTP.

Tim has more details on these issues in his ACD Notes‌.

Is it good enough? Absolutely, aside from the easy-to-fix engineering and configuration issues, it’s fair to say that the Ropsten testnet merger was flawless. There are no issues with specs and methods, no incompatibilities, and no chain downtime. Within a few hours, engagement was again above 99%, and there is no doubt that the merger was a huge success.

Difficulty bomb delayed

We agreed to delay the Ethereum difficulty bomb by 700,000 blocks on our All Core Devs conference call last week .

100k mainnet blocks take about 15 days, so that’s about a 105 day delay (3.5 months), which pushes the difficulty bomb to the end of September, although I personally would prefer that we be bold and committed to merge as soon as possible, Instead of delaying the difficulty bomb, but delaying is probably the right thing to do. Merge risks are greater when block times increase, and block sizes may inflate to compensate.

In fact, the difficulty bomb delay gives us a strong indication of when teams expect a merger to happen. If we don’t have the confidence to get the merger done by mid-September, then we’ll delay it even longer (nobody likes delaying twice). Of course, the merging thing still depends on whether there is anything bad in the testing process.

To be honest, don’t worry about the difficulty bomb, I think the DevCon in early October was probably the strongest motivation for the teams to execute the merger. We’d rather walk with our heads held high and be welcomed like heroes. If we fail to achieve the merger, I doubt any of us want to show up because it’s shameful!

test merge

Sepolia Testnet

We have agreed to merge the Sepolia testnet as the next step, and then the Goerli testnet in July.

The Sepolia Beacon Chain, which will go live on Monday, will have only a small number of validators, be largely controlled by the development team, and have a permissioned deposit contract. This makes it easier to coordinate interesting test scenarios and to run it long term.

As discussed in this week’s Developer Consensus call, we will be selecting a TTD within a week or so to merge for the Sepolia testnet around June 29th.

The seventh shadow fork of the mainnet

The mainnet shadow fork has now become routine, and MSF7 (the seventh shadow fork) is expected to take place on the 22nd (Wednesday).

You can track progress through the following websites:



The Merge Prep Checklist‌ is already on the Ethereum Launchpad, and the time has really come!

Miga Labs has completed another in-depth report on consensus client performance‌, and they have also uploaded more graphs and more of the Eth2 Clients Plots, which is interesting. All in all, they’ve done a lot of work.

It’s difficult to fairly assess client performance, and on the one hand, goals are constantly changing: since the report was published, we’ve reduced Teku’s CPU usage by 25% and output bandwidth by nearly 40%. On the other hand, what’s easy to measure doesn’t always matter. Miga Labs does a lot of work to test synchronization because it’s easy to measure and compare, but it’s almost completely irrelevant. Clients spend almost their entire lives in out-of-sync mode, and syncing from genesis under proof-of-stake is actually dangerous. That’s why we didn’t bother to optimize sync in Teku at all, so we take these numbers with a grain of salt. But to be fair, this report from Miga Labs does make an effort to expand their measurements to more realistic scenarios.


This week’s staking topic seems to be MEV-Boost, a more neutral name for it is the Builder API, Flashbots think MEV-Boost is good for us, and stakers should run it after the merger, Hasu summed up this topic ‌.

In addition to that, Lightclients did a very in-depth tweet on what it would involve for stakers to run the Builder API (MEV Boost).

Finally, the EthStaker trio of Rémy, Yorick, and Ladislaus provided validators with a discussion video on MEV and mev-boost‌.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-06-20 12:02
Next 2022-06-20 12:03

Related articles