A blockchain reorganization attack refers to a chain split in which nodes receive blocks from a new chain while the old chain continues to exist.
On May 25, the Ethereum Beacon chain suffered a seven-block reorg and was exposed to a high-level security risk called chain organization. Validators on the Eth2 (now consensus layer upgrade) Beacon Chain became out of sync after a client update elevated specific clients. However, during the process, validators on the blockchain network were confused and didn’t update their clients.
Seven-block reorganization means that seven blocks of transactions were added to the eventually discarded fork before the network figured out it wasn’t the canonical chain. Therefore, blockchain reorganization happens if some node operators are faster than others. During this scenario, faster nodes will be unable to agree on which block should be processed first and they’ll continue to add blocks to their blockchain, leaving the shorter chain when the next block is created.
For instance, miners X and Y may both locate a valid block at the same time, but due to the way the blocks spread in a peer-to-peer network, a portion of the network will see X’s block first, followed by Y’s block.
If the two blocks are of equal difficulty, there will be a tie, and clients will be given the option of picking at random or selecting the previously seen block. When a third miner, Z, creates a block on top of either X’s or Y’s block, the tie is usually broken, and the other block is forgotten, leading to blockchain reorganization.
In Ethereum’s Beacon chain reorganization case, up-to-date nodes were around 12 seconds faster than validators that hadn’t updated their clients at block 3,887,074. Ethereum chain reorganization occurs when updated clients submit the next block before the rest of the validators. This confused validators about who should submit the initial block.
Preston Van Loon, a core Ethereum developer, stated that the reorg of the Ethereum blockchain is due to the deployment of the Proposer Boost fork decision, which has not yet been fully rolled out to the network. Furthermore, this reorganization is a non-trivial segmentation of updated versus outdated client software, not a sign of a bad fork choice.
