TL;DR
Merge
There are no significant concerns with Goerli-Shadow-Fork-5. With around 30% of the network tested so far, MEV-Boost is working well. There will be a Goerli-Shadow-Fork-6 next week.
There are no client compatibility concerns with Mainnet-Shadow-Fork-10. Besu needed update, some Erigon nodes lost peers, but everything else was more-or-less expected.
Goerli/Prater Merge is also announced. On August 4, Prater will undergo the Bellatrix upgrade, and from August 6 to 12, Prater and Goerli will merge.
Execution style in relation to terminal blocks
With Nethermind, a GSF5-related issue surfaced. By means of rumour, terminal block "A" was imported. Following that, the terminal block "B" moved. The block "B" was added to the block tree but not processed since Nethermind does not process blocks that won't be the head of the chain. The transition block built on "B" was the reason why Nethermind returned "SYNCING" rather than validating the payload. Node got stuck since it was unable to switch to the new branch for the 128 "safe slots to import" slots. If the EL has enough information to validate the transition block, it must do so regardless of what occurs with numerous terminal blocks. Nethermind seemed to have processed "B" in this case. Erigon has a quick fix. Geth is anticipated to be alright.
Exchange configuration before Mainnet TTD is implemented
Users can set up their Beacon Node and Execution Client in advance for Merge by configuring the Exchange before Mainnet TTD is implemented. What value to use for before TTD is set is uncertain from the execution side. The behaviour of the consensus side is well-defined. Although probably unnecessary, it is unclear whether to include this in the specifications.
Expand the definition of optimistic nodes
When a node's head is positive, the node is also optimistic. This PR deals with the situation in which a new checkpoint is justified in the block store due to a branch of optimistic blocks. The EL is catching up to the payloads in parallel. They could find themselves in a situation where there is no tip that corresponds to the justified checkpoint in the store if any payloads are invalid and we have to remove the branch from the block store. There are several methods to approach this. Rollback is risky since it could result in surrounded votes. It is probably best to maintain a positive attitude and wait for more information from peers.
Currently, consensus clients use several techniques. After a reset, Teku and Lighthouse could find themselves discussing about invalid blocks. Prysm hasn't settled on a solution yet.
Dankrad asked, "Should blocks from an optimistic sync actually be justified and taken into consideration?" Danny answered to this, "This failure event, which was caused by an attack or breakdown, has to be fixed manually. Validators shouldn't cast votes for anything with an optimistic outlook. A node in this state should not attest in any way, hence it would be ideal not to rely on slashing protection. If they are going to act on a justified checkpoint and it must be completely confirmed."
An attacker just needs two blocks to cause trouble if they can activate optimistic mode. Prysm may use Lighthouse's strategy of retaining a "invalid head" on the fork. All of the strategies, including Teku's, sound acceptable. AdrianS said: "Not a big fan of "invalid head" - difficult to reason about. But staying in optimistic mode seems reasonable." Everything should be well if a node does not distinguish between optimistic and invalid data. As it eliminates all invalid blocks and would do away with an optimistic head, this is ineffective for Prysm.
MEV-Boost (Circuit breaker proposal)
The issue of delaying MEV-Boost during the transition is still open for dispute. If there are no last-minute objections, this PR appears to be approved. An illustration of a proposal to deal with the situation when a Relay refuses to deliver the signed block data.
What are the drawbacks of having a greater value rather than a smaller value, and how about a recovery time that is lengthening exponentially? Danny replied:
"That's reasonable, but also want to keep things simple. Could also do threat modelling - how likely is it for an adversary to trigger the mechanism at will give a certain threshold?"
Lighthouse has this integrated, however the user can customise it. This makes gaming more difficult. Users could have various defaults. It is indeed a good idea to make it a client implementation detail. If MEV-Boost is inaccessible, everything should still function. On the basis of it, an increase in complexity is acceptable. A great concept is a circuit breaker. Random client-selected values may be beneficial. A circuit breaker could be easy to use. Concerned that they may significantly influence the network with just 1 or 2 relays. The side-car MEV-Boost design can assist in encapsulating mitigations. The MEV Boost spec PR is almost ready to be merged with other MEV topics like Lighthouse and Nimbus.
Other Reads
- Ethereum Bulletin
- Understanding the concept of Ethereum Virtual Machine
- Polygon, zkSync and Scroll independently launched the first zkEVMs
- Polygon and Flickplay selected for Disney Accelerator 2022
- MetaMask memorializes its sixth anniversary.
- US Treasury designed the Framework for International Crypto Regulation
- ConsenSys’ partnership with StarkWare
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!
