TL;DR
Merge
Mainnet-Shadow-Fork 9
Mainnet-Shadow-Fork 8 was successful on July 5 and Mainnet-Shadow-Fork 9 took place today, although TTD calculation was incorrect. Before demolishing it, Nethermind would like to keep it intact for a few days. They are seeking to identify the cause of the network's poor finalisation.
Nethermind is inactive on MSF9. They encountered a problem on MSF8 that they had seen on Ropsten. So, in an effort to reproduce, they ran a bunch of different configurations on MSF9, achieved this success. The rare problem with Nethermind was supposed to be resolved. However, saw it again on MSF8 after 12 days. Reduced pruning cache tends to make the problem worse more quickly, investigating but may have a fix.
Lighthouse nodes were slowing up and wouldn't catch up until the next epoch. Already in process, a solution has been deployed. The invalid block hit 4 out of 5 Besu nodes and resembled a prior problem. Erigon nodes did not timely synchronised.
The configuration had been messed up by Nimbus nodes. It took the network roughly 60 epochs to finalise.
As the Goerli shadow fork syncs significantly more quickly than the mainnet, they intend to implement it next. The aim is Wednesday of the next week, or July 20.
Prater to Goerli naming
Goerli as an alias for Prater might be introduced by consensus layer clients, may or may not deprecate in the future. There is no need for coordination on this, it is only a client UX problem. It must be stated clearly that the name is the only change, resyncing is not required.
Single vs Dual Merge Release
For The Merge on the mainnet, developers discussed client release strategies proposed by Tim Beiko. They prefer not to have Bellatrix go active on the beacon chain after TTD is hit. They discussed three strategies for doing this:
- Single release: There may be a very slight chance that a hash rate increase impacts TTD too early. This would take the same amount of hashing power as a 51 percent attack and be highly obvious. It provides the easiest user experience.
- Dual releases: It is extremely secure, but requires more work for users. Potentially increases the Merge's timeline.
- Single release plus TTD override: Even this is secured in terms of TTD, but complicated for users.
According to the common opinion, user experience simplification is important, and the possibility of reaching the TTD too soon has no impact on our security model under PoW. They'll use the Goerli Merge to test this strategy.
Geth is altering the EngineAPI to start earlier so that Bellatrix consensus clients won't complain about it being inaccessible. In order to enable users to quickly set up their development environments, it would be beneficial if all execution clients could do the same. This topic is to be brought up on the next ACD call as well.
TTD for Goerli
The primary testnets for community testing are Goerli and Prater, so users must have enough time during Goerli Merge and mainnet Merge to validate their infrastructure. In approx 4 weeks, Nethermind would be prepared to plan the Goerli TTD, you can check the estimated block and time here.
Tim Beiko suggested time-line for discussion:
- Goerli/Prater client releases 27-28 July.
- Announce 28-29 July.
- Prater Bellatrix on 8 August.
- Goerli Merge on 11 August.
- ACD 18th August plan mainnet Merge.
- Bellatrix early September.
- Merge two weeks later (around 19 September).
As next steps, Tim will make TTD proposal for Goerli on Monday. Will create a PR for comments/objections and merge it if no push-back.
MEV-Boost (Merge transition delay on builder network)
Everyone believes that delaying the Merge transition is the ideal way to implement the initial MEV-Boost embargo since clients are confused by the existing specifications since they don't know when checkpoints were initially finalised. When they reach +16 epochs from the first finalised Merge epoch, they must be aware of this. The information won't be in the database if the node is restarted soon after the merge, which is a problem. Danny said:
"Probably fine to use some heuristics to work around the issue."
They want to choose the easiest plan of action in this situation since the MEV-Boost delay is intended to simplify the engineering over the merging. Consider simply counting on relayers staying offline for a few epochs after finalization. The most straight-forward approach is to begin MEV-Boost at finalization. Relays don't have to rely on this; they may be asked to wait for longer times.
Other Reads
- Ethereum Bulletin
- Russian Bank executes first Digital Asset transaction
- Highlights of the ACD Meeting 142
- Binance enters the Spain market
- US Treasury designed the Framework for International Crypto Regulation
- Highlights of Ethereum Consensus Layer meeting 90
- ConsenSys’ partnership with StarkWare
- SwaySwap launch on Ethereum's Modular Execution Layer
Disclaimer: The information contained on this web page is for education purposes only. Readers are suggested to conduct their own research, review, analyze and verify the content before relying on them.
To publish press releases, project updates, and guest posts with us, please email at contact@etherworld.co.
Subscribe to EtherWorld YouTube channel for ELI5 content.
Share if you like the content. Support us at Gitcoin
You've something to share with the blockchain community, join us on Discord!
