Note: the original author is Ben Edgington, the developer of consensys, and the translation has been deleted.
Code named gray glacier（ Grey Glacier ）The hard bifurcation of the Ethereum main network is coming. This is a bifurcation to delay the difficulty bomb. The time is very urgent. Therefore, please be sure to update your eth1 node as soon as possible. The bifurcation is expected to occur around June 29, or maybe a day or two in advance.
We have successfully completed the POS merger of the ropsten test network.
You have been waiting for a long time due to the fluctuation of computing power. You can EthStaker partyWatching our merging time on, ropsten finally completed the merging at 16:08:08 world standard time and generated its first merging block.
Is the merger perfect? Pari provides a goodsummaryIn short, we lost about 14% of our participation, of which about 9% was caused by a simple misconfiguration in the nimbus team node, which is easy to fix, 1.8% was caused by a known problem in nethermind, which was fixed by restarting, and 2.5%-3% was caused by the communication problem between besu and nethermind (WebSockets), which was fixed by switching to http.
Tim is in his ACD notesMore details on these issues are available in.
Good enough? Absolutely, apart from the engineering and configuration problems that are easy to repair, it can be said that the integration of the ropsten test network is perfect. There are no problems with the specifications and methods, no incompatibilities, and no chain downtime. Within a few hours, the participation rate rose again to more than 99%. There is no doubt that this merger is a great success.
At the all core devs conference call last week, we agreed to postpone the Ethereum difficulty bomb by 700000 blocks.
It takes about 15 days for 100000 main network blocks, so this is a 105 day delay (3.5 months), which will delay the difficulty bomb until the end of September. Although I personally hope that we are bold and committed to merging as soon as possible, rather than delaying the difficulty bomb, it is probably the right way to delay. As the block time increases, the consolidation risk will be greater, and the block size may expand to compensate.
In fact, the difficulty bomb delay gives us a strong indication of when the teams expect to merge. If we are not confident that the merger will be completed by mid September, then we will postpone it for a longer time (no one likes to postpone it twice). Of course, the merger still depends on whether there is anything bad in the testing process.
To be honest, don't worry about the difficulty bomb. I think DevCon in early October may be the strongest motivation for all teams to implement the merger. We would rather strut and be welcomed like heroes. If we fail to achieve the merger, I suspect that none of us would like to show up, because it is shameful!
We have agreed to merge sepolia test network in the next step, and then merge goerli test network in July.
Sepolia beacon chain will be launched on Monday. It will have only a small number of validators, mainly controlled by the development team, and a licensed deposit contract. This makes it easier to coordinate interesting test scenarios and to run them over time.
As discussed in the developer consensus teleconference this week, we will select a TTD in about a week to merge the sepolia test network around June 29.
The main network shadow bifurcation has now become a routine. Msf7 (the seventh shadow bifurcation) is expected to be carried out on Wednesday, the 22nd.
You can track progress through the following websites:
Consolidation preparation listIt is already on the Ethereum launchpad. The time has really come!
MIGA labs has completed another report on consensus client performanceIn depth reportIn addition, they also uploaded more eth2 clients plots and more content, which is very interesting. In a word, they have finished a lot of work.
It is difficult to fairly evaluate the performance of the client. On the one hand, the objectives are constantly changing: since the report was released, we have reduced the CPU utilization of teku by 25% and the output bandwidth by nearly 40%. On the other hand, things that are easy to measure are not always important. 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 whole lives in the asynchronous mode. It is actually dangerous to synchronize from Genesis under the proof of interest. This is why we didn't bother to optimize synchronization in teku at all, so we have reservations about these figures. But to be fair, this report by MIGA labs does try to extend their measurement to more realistic scenarios.
This week's stacking theme seems to be MeV boost. Its more neutral name is builder API. Flashbots think that MeV boost is good for us. Pledgers should run it after the merger. Hasu has a discussion on this topicsummary。
In addition, lightclients made a lot of changes on twitterIn depth discussionLast, we talked about what will be involved when the pledgor runs the builder API (MeV boost).
Finally, the ethstack group composed of R é my, Yorick and Ladislaus provided the verifier with information about MeV and MeV boostDiscussion video。