An Unknown Miner Commands More Than 51% of BSV’s Hashpower, Consecutive Strings of Empty Blocks Makes Chain Unreliable

block reorg

“This reorg is not an indicator of a flawed fork choice, but a non-trivial segmentation of updated vs out of date client software” suggested Core Ethereum developer Preston Van Loon.

Ahead of the Merge tentatively penciled in for August, Ethereum’s Beacon Chain experienced a seven-block reorganization (reorg) yesterday.

According to data from Beacon Scan, on May 25 seven blocks from number 3,887,075 to 3,887,081 were knocked out of the Beacon Chain between 08:55:23 to 08:56:35 AM UTC.

The term reorg refers to an event in which a block that was part of the canonical chain, such as the Beacon Chain, gets knocked off the chain due to a competing block beating it out.

It can be the result of a malicious attack from a miner with high resources or a bug. Such incidents see the chain unintentionally fork or duplicate.

On this occasion, developers believe that the issue is due to circumstance rather than something serious such as a security issue or fundamental flaw, with a “proposer boost fork” being highlighted in particular. This term refers to a method in which specific proposers are given priority for selecting the next block in the blockchain.

Core Ethereum developer Preston Van Loon suggested the reorg was due to a “non-trivial segmentation” of new and old client node software, and was not necessarily anything malicious. Ethereum co-founder Vitalik Buterin labeling the theory a “good hypothesis.”

Martin Köppelmann, the co-founder of EVM compatible Gnosis chain was one of the first to highlight the occurrence via Twitter yesterday morning, noting that it “shows that the current attestation strategy of nodes should be reconsidered to hopefully result in a more stable chain! (proposals already exist).”

In response to Köppelmann, Van Loon tentatively attributed the reorg to the proposer boost fork which hadn’t fully been implemented yet:

“We suspect this is caused by the implementation of Proposer Boost fork choice has not fully rolled out to the network. This reorg is not an indicator of a flawed fork choice, but a non-trivial segmentation of updated vs out of date client software.”

“All of the details will be made public once we have a high degree of confidence regarding the root cause. Expect a post-mortem from the client development community!” he added.

We suspect this is caused by the implementation of Proposer Boost fork choice has not fully rolled out to the network. This reorg is not an indicator of a flawed fork choice, but a non-trivial segmentation of updated vs out of date client software.
— prestonvanloon.eth (@preston_vanloon) May 25, 2022

Earlier today, another developer Terence Tsao echoed this hypothesis to his 11,900 Twitter followers, noting that the reorg seemed to be caused by “boosted vs. non boosted nodes in the network and the timing of a really late arriving block.”

“Given that the proposer boost is a non-consensus-breaking change. With the asynchronicity of the client release schedule, the roll-out happened gradually. Not all nodes updated the proposer boost simultaneously.”

Van Loon spoke at the Permissionless conference last week and said that the Merge and switch to Proof-of-Stake (PoS) could come in August “if everything goes to plan.”

While the reorg is sure to raise questions of this potential timeline, Van Loon and the other developers have not yet outlined whether it will have any impact at all.

block reorg