Conclusion
The recent Ethereum ‘reorg’ is nothing to panic about – this appears to have been a low probability event that was not malicious, and is not likely to delay the merge.
Ultimately, what is needed to solve this is for a minority (but significant) proportion of validators to update their consensus client software; something likely to happen before the merge anyway, resulting in a diminishing (0.02% and decreasing) likelihood of a beacon chain ‘reorg’ happening in the future.
Here is a great explanation from terence.eth at Prysmatic labs.
So, What Happened?
At a very high level, two groups of validators had a different view of the ‘correct’ chain. The reason they had differing views is that some were running consensus client software with proposer boosting, while the others were not. Ultimately one group “won out” and the chain they voted for became canonical, with the other being abandoned.
What’s Proposer Boosting?
Proposer boosting gives more weight to proposed blocks that are received in a timely manner. Proposer boosting was introduced to solve the problem of ex ante reorgs (see here for an explanation; for more on proposer boosting see here).
(reference: https://github.com/ethereum/consensus-specs/pull/2730)
What Happened? (Part Two)
Block 3887074 arrived late and 3887075 arrived in a timely manner, i.e., block 3887075 received a boost; as did blocks 3887076 to ‘081 (i.e., bottom chain).
As a result, validators with proposer boosting (‘boosting’) enabled the bottom chain to be the canonical chain. However, for validators that didn’t have boosting enabled, the shorter, top chain appeared to be canonical, with each chain continuing to accrue votes from their respective validators.
The numbers worked out in such a way that the top chain “won” on a purely LMD GHOST fork-choice basis (see here for more information), while the bottom chain “won” on a ‘boosting’ basis. Then a validator without boosting enabled proposed block 3887082 adding onto block 3887074. The result was a reorg that saw blocks 3887075 to ‘081 effectively eliminated from the canonical chain.
This was deemed to be an unlikely event by terence.eth because he estimated that the proportion of validators running ‘boosting’ enabled clients is 75%. This means that enough of the remaining 25% of validators (i.e., non ‘boosting’ enabled) voted for the top chain so that it was canonical from an LMD GHOST basis. This happened over six slots, yielding a probability of 0.256= 0.02% for this event to have occurred. This number is likely to drop orders of magnitude lower as clients continue to update to the most recent CL client version.
Again, this issue doesn’t warrant panic, nor does it support this conclusion:
At no point were the reorged blocks above finalized (or justified for that matter). Validators disagreed on the current head of the Beacon Chain – this “disagreement” took place over the course of about a minute.
Typically, it takes the Beacon Chain fourteen minutes to reach finality. The point is that the entire discussion above relates to casting an LMD GHOST vote, related to the head of the Beacon Chain; validators also cast an FFG vote (not discussed above) – this is the vote that is related to finality and justified checkpoints. (you can look here for more.)
