Ethereum researcher illustrates blockchain reorganization event, why won't it happen again after the merge?

Ethereum's beacon chain experienced 7 block reorganizations on 5/25. Researcher Barnabé Monnot synthesized insights from multiple analysts and developers to illustrate the reasons for the reorg in a visual manner. It was emphasized that all validating nodes will be using the same client software after the merge, preventing future block reorganizations.

This excerpt is from Barnabé Monnot's article. For any doubts, please refer to the original text: https://barnabe.substack.com/p/pos-ethereum-reorg

In summary, the reorganization was not anticipated on the beacon chain, primarily due to some clients not updating for Proposer Boost to defend against ghost attacks, leading to node divergence. Monnot also stressed that the reorg did not cause delays or errors in finality verification.

Advertisement - Continue scrolling for more content

Ethereum Consensus Mechanism

The reason for this reorganization is related to the fork selection rule LMD GHOST Last Message Driven Greediest Heaviest Observed SubTree adopted by the Ethereum consensus layer.

Before analyzing the reasons for the reorganization, it is necessary to understand the operation mechanism of LMD GHOST and Slots.

LMD GHOST

When a blockchain operates honestly, only one new block should appear on the chain at a time and receive support from all validators. However, due to network delays or disagreements among Block Proposers, clients need an algorithm to determine which chain to support. The algorithm used by Ethereum is called LMD GHOST, which allows users to identify which chain contains the most validator proofs.

Slots

In Ethereum's consensus mechanism, time is divided into Slots, with each Slot being 12 seconds and selecting a Block Proposer, who is then voted on by Attesters.

The Block Proposer, based on the LMD-GHOST fork selection rule, constructs the next block on the chain that they believe has the most validator proofs. The "Proposer" is expected to release a block at the beginning of the Slot, while "Attesters" should vote at 4 seconds into the Slot, allowing enough time for the block to be seen by the Attesters.

With the introduction of Proposer Boost, the weight of the Proposer voted by the Attesters is increased, leading to a tendency for more immediate block proposals. The author then illustrates the reorganization process with diagrams.

How Did the Fork Happen?

In the diagram, rectangles represent the seven blocks of the reorganization, and circles represent proof votes, with larger circles indicating higher weights.

Blocks 74 and 75 simultaneously form a fork, with multiple Block Proposers building blocks on 75, but block 74 accumulates more weight on the competing chain. Ultimately, Block Proposer of block 82 constructs a block on top of block 74, ending the fork by reorganizing blocks 75 to 81.

Fork Steps

Slot 73

At Slot 73, Attesters voted for block 73 and completed it promptly, everything was normal at that point.

However, no block appeared at Slot 74, so Attesters continued to vote for block 73, increasing its weight.

Blocks 74, 75

The sequence of events is as follows:

1. Block 74 is delayed.
2. As a result, blocks 74 and 75 appear almost simultaneously at the start of Slot 75.
3. Proposer Boost gives block 75 more weight.
4. Therefore, Slot 75 tends towards block 75 instead of block 74.

It is important to note that not all Attesters' clients have upgraded to Proposer Boost, resulting in a roughly equal split of votes between the two chains:

• Clients without activated Proposer Boost lean towards block 74.
• Clients running Proposer Boost lean towards block 75.

However, the diagram shows that the weight of block 74 is slightly higher than block 75, indicating a higher proportion of clients not running Proposer Boost.

Block 76

Since block 74 had higher weight, why did the Block Proposer of block 76 choose block 75?

This is because Proposer Boost applies to the Proposer executing the fork selection at that moment. Therefore, the Block Proposer of block 76 mistakenly chose block 75 as the parent block because from their perspective:

Weight of block 75 Attesters + Proposer Boost on block 75 > Attesters of block 74

Blocks 76-81

Simultaneously, Attesters of blocks 75-81 continue to allocate votes between blocks 74 and 75, with validators who do not run Proposer Boost continuing to vote for block 74, increasing its weight.

Finally, a Block Proposer who does not run Proposer Boost appears and needs to decide on which chain to build a block. The Block Proposer of block 82 believes that block 74 has higher weight than 81. The author emphasizes that the weight of block 74 is higher than any of blocks 75-81.

Thus, blocks 75-81 are effectively reorganized, and even validators running Proposer Boost consider block 82 as the winner, with no more split in validation votes.

Conclusion

The author believes that while block reorganizations are theoretically possible, they are difficult to achieve in practice, emphasizing that the reorganization event on the Ethereum beacon chain was purely accidental.

Currently, Ethereum developers have a clear understanding from the reorganization event that there is a possibility of disagreement among validators, where a group of validators may see things differently from other nodes, realizing that these disagreements may delay blocks, with the imbalance of Proposer Boost possibly being the cause of the disagreement.

Furthermore, the author also believes that after the Ethereum merger, where all nodes must update due to a hard fork upgrade, all validating nodes will run the same client software post-merger, preventing similar reorganization events caused by the same factors.

In conclusion, while similar failure events are frustrating, block reorganizations did not render the consensus mechanism of the Ethereum beacon chain ineffective. On the contrary, this event has made Ethereum developers more cautious and motivated to create a more robust protocol that is stable both in theory and in practice.