Yesterday, people focused not only on the falling price of Ether but also on the Beacon Chain. There, a so-called 'block reorganization' of no less than seven blocks deep took place. Such reorganizations occur occasionally on proof-of-work chains but the hope was that they would be a thing of the past on Ethereum's proof-of-stake chain. Should we be worried?

Ethereums Beacon Chain is the parallel chain on which Proof-of-stake is being thoroughly tested. After the merge of (hopefully) second half of 2022, Ethereum will then really run on what is currently a proof-of-stake test network. So there is still time to detect vulnerabilities. The block reorg was one of those moments when developers DM'd each other: what's going on here? Can this hurt? It seems not.

Reorganizations are not abnormal

When concatenating transaction blocks, it is normal for a fork to occur for a short period of time. How does this happen? In Proof-of-work chains like Bitcoin, it is because two miners have completed their 'puzzle' at almost the same time and are allowed to mine a block. They send this block to the nodes. If this happens almost simultaneously, some nodes are more likely to approve one block, and other nodes another. A fork (split) will then occur. This is usually resolved with the next block, after which the winning chain is the only one left. The chance that almost simultaneous block creation will happen again is very small - let alone that it happens three or four times in a row. (This possibility of forking is the reason why many crypto exchanges and wallets wait for a number of confirmations/blocks. Only when a transaction is tucked away four, five, six blocks deep is there near zero chance that it can be reversed).

Different versions of the software in circulation

How could it happen that Ethereum's Beacon Chain had this conflict for as many as seven blocks (incidentally, Ethereum's block time is only about 12 seconds)? It has to do with the different Ethereum clients (versions of the Ethereum software) that were in circulation. Some nodes were running clients on which a protocol change had already been made - others had not yet made that update.

The protocol update in question had to do with a so-called boost function. This ensures that quickly created blocks are distributed extra quickly - precisely to prevent conflicting versions of the chain from circulating. As not every client had implemented this boost feature, different nodes drew different conclusions as to what the right block was to base the rest of the chain on.

This is what seems to have happened. The exact post-mortem will no doubt follow later. As mentioned, the occurrence of temporary forks and subsequent reorganizations is not in itself a problem. And no doubt all clients will start implementing this boost feature, after which this type of block reorganization will no longer occur.

Conclusion: Ethereum's transition to proof-of-stake comes with risks

The block reorg had nothing to do with an attack on the system, double spend attempt - not even a bug, really. So there was nothing too serious going on. But the fact that this type of event was not anticipated by Ethereum developers says something about the complexity of the transition to proof-of-stake. It is a system of transaction validation that is much, much more complex than proof-of-work. The coming months and years - even after the merge - should reveal what surprises are still in store.