In front of the Merge tentatively penciled set for August, Ethereum’s Beacon Chain possessed a seven-block reorganization (reorg) yesterday.
Based on data from Beacon Scan, on May 25 seven blocks from # 3,887,075 to three,887,081 were knocked from the Beacon Chain between 08:55:23 to 08:56:35 AM UTC.
The word reorg describes a celebration where a block which was area of the canonical chain, like the Beacon Chain, will get pushed off the chain as a result of competing block beating it.
It may be the effect of a malicious attack from the miner rich in sources or perhaps a bug. Such occurrences begin to see the chain unintentionally fork or duplicate.
At this juncture, developers think that the problem is because of circumstance instead of something serious like a security issue or fundamental flaw, having a “proposer boost fork” being highlighted particularly. This term describes a method that specific proposers receive priority for choosing the following block within the blockchain.
Core Ethereum developer Preston Van Loon recommended the reorg was as a result of “non-trivial segmentation” of old and new client node software, and it was not always anything malicious. Ethereum co-founder Vitalik Buterin labeling the idea a “good hypothesis.”
Martin Köppelmann, the co-founding father of EVM compatible Gnosis chain was among the first to focus on the occurrence via Twitter yesterday morning, noting it “shows the current attestation technique of nodes ought to be reconsidered to hopefully create a more stable chain! (proposals already exist).”
As a result of Köppelmann, Van Loon tentatively attributed the reorg towards the proposer boost fork which hadn’t fully been implemented yet:
“We suspect this is because the implementation of Proposer Boost fork choice hasn’t fully folded to the network. This reorg isn’t an indicator of the problematic fork choice, however a non-trivial segmentation of updated versus outdated client software.”
“All from the details is going to be published once there exists a high amount of confidence concerning the real cause. Expect a publish-mortem in the client development community!” he added.
We suspect this is because the implementation of Proposer Boost fork choice hasn’t fully folded to the network. This reorg isn’t an indicator of the problematic fork choice, however a non-trivial segmentation of updated versus outdated client software.
— prestonvanloon.eth (@preston_vanloon) May 25, 2022
Earlier today, another developer Terence Tsao echoed this hypothesis to his 11,900 Twitter supporters, noting the reorg appeared to result from “boosted versus. non boosted nodes within the network and also the timing of the really late coming block.”
“Given the proposer boost is really a non-consensus-breaking change. Using the asynchronicity from the client release schedule, the roll-out happened progressively. Not every nodes updated the proposer boost concurrently.”
As the reorg will certainly raise questions of the potential timeline, Van Loon and yet another developers haven’t yet outlined whether it’ll have any impact whatsoever.