What is a chain reorganization (reorg)?
What is a reorg?
A chain reorganization, or “reorg,” occurs when a blockchain produces blocks at the same time, if there is a bug, or due to a malicious attack. This results in a temporary duplicate blockchain. The longer a reorg lasts, the more damage is done to the networks.
Reorgs in the context of blockchains, result in a block being removed from the blockchain since a longer chain has been created. This further results in different miners working on adding blocks of transactions with similar difficulty to the chain simultaneously.
This happens because the miner that adds to the next block has to make a decision on which side of the fork is the correct or canonical chain. Once the miner has chosen the fork or canonical chain, the other chain will be lost.
A reorganization attack refers to nodes receiving blocks from a new chain while the old chain continues to exist. In this case, the chain would be split and create a fork, or a duplicate version of the blockchain.
What causes a blockchain reorg?
A blockchain reorg is caused when two blocks are published at the same time. Short one- and two-block reorgs happen often because of network latency, but when reorgs extend for longer than one or two blocks, they can lead to malicious attacks or even network failure.
What are the consequences of chain reorganizations?
There are four main consequences of chain reorganizations: delays and poor user experience, node costs, uncertainty, and vulnerability to attacks.
1. Delays and Poorer user experience
Along with increased node costs, reorgs increase the chance of delayed transactions. This is a significant problem for exchanges because they have to rely on transactions to be confirmed on time or they may suffer the consequences of waiting longer for a deposit.
Reorgs can increase the number of nodes within a blockchain over time, causing a poorer user experience. When transitioning to a new fork, state updates involve more memory and disc costs.
When reorgs are prominent, users have less guarantees that transactions will be executed on time. Without enough context, DeFi transactions would have far worse results and also lead to harmful MEV extraction.
4. Vulnerability to attacks
When reorging becomes more common, attackers only need to beat a portion of honest miners (due to the “longest chain rule”) rather than all of them. A larger number of reorgs make the attacker’s role much easier.
What is the canonical chain?
The canonical chain is the agreed “main chain.” Therefore, it isn’t considered one of the sidechains which end.
In theory, the network is never 100% sure which chain is the canonical chain. This is because you could still revert block number 1 by continuing its side-chains with enough hashing power.
What is a fork?
A fork occurs whenever a community makes a change to the blockchain’s protocol or basic set of rules and effectively splits (or “forks”) the chain into a new chain that will follow the new rules, and an old one that becomes mostly obsolete.
Because blockchains like Bitcoin and Ethereum are powered by decentralized, open-source software and maintained by community members with vested interests in the network, network participants can propose and vote on changes to the software.
What is the fork choice rule?
A fork choice rule is a function that takes as input the set of blocks and other messages that have been seen and outputs to the client what the “canonical chain” is.
Forks occur when multiple published blocks reference the same previous state. A blockchain might face such an event by accident if two blocks are published at approximately the same time, or could happen on purpose as if a malicious actor were attempting to create a fork in order to "remove" a payment from the chain.
In either case, there needs to be some mechanism that allows users to determine which fork is the correct or "canonical" one. This is referred to as a "fork choice rule."
Fork choice rules are required because there could be multiple valid chains to choose from. This is possible when there are two competing blocks with the same parent chains being published at the same time.
For example, the “longest valid chain wins,” would be a simple fork choice that aligns with the Proof-of-Work mechanism. We can define a fork choice rule that allows a blockchain to serve as the proposal mechanism for a consensus algorithm. They would have such displayed properties as outlined by Vitalik Buterin.
Here are three fork choice rules displayed below in this chart:
What is finality?
Finality is the full guarantee that a crypto transaction won’t be able to be altered, reversed, or canceled in any way after completion. Finality is dependent on the latency of the blockchain itself. Finality is often used to measure the time needed to wait in order for a guarantee that a transaction will be executed.
What happens to a reorg on Ethereum?
Ethereum currently uses a Proof-of-Work consensus mechanism. Ethereum uses a fork chain rule called the “longest chain rule,” meaning that when a client is shown two blockchains, it chooses the one with the most difficulty. This is done by comparing the sum of difficulty within all the blocks in the chain itself.
The Ethereum Beacon Chain recently experienced a reorg that could lead to potential security risks. The Beacon Chain introduces native staking, which is the main component of the Proof-of-Stake consensus model Ethereum is aiming to adopt. The reorg within Ethereum lasted seven blocks, which is one of the longest reorgs in years. Since the Ethereum Merge is a delicate process, a reorg in the Beacon Chain could lead to further delays within the Merge.
Martin Köppelmann, the CEO and co-founder of Gnosis, was one of the people to tweet what he had observed within this seven-block reorg.
A seven-block reorg means that a fork had occurred and dropped seven blocks containing hundreds of transactions. This led to the risk that a user could spend the same assets twice. A reorg of 2-3 blocks could just be a sign of bad luck since blockchains often face network latency. This could be the case for the Beacon Chain as well.
Given that reorgs of five blocks or more is a potential sign of a malicious attack, the recent Ethereum reorg appeared to have faced a low probability event that wasn’t malicious according to developers.
Vitalik Buterin said in a timely response that it could be due to outdated versions of mining software. Preston Van Loon, a core Ethereum developer, said that the reorg of the Beacon blockchain was caused by the deployment of the Proposer Boost fork decision, which had not yet been fully rolled out to the network.
Proposer boosting was introduced to give more weight to proposed blocks that are received in a timely manner. Proposer boosting was introduced to solve the problem of ex-ante reorgs.
Essentially, validators that have proposer boosting enabled the bottom chain to become the canonical chain, but validators that do not have proposer boosting chose the shorter, top chain instead. This leads to each chain continuing to accrue votes from their respective validators.
Furthermore, this reorganization is a non-trivial segmentation of updated versus outdated client software. The reorg itself wasn’t a sign of a bad fork choice.
The validators on the Ethereum Beacon Chain became out of sync after a client update raised specific clients. During the process, validators on the blockchain network were confused and didn't update their clients Which eventually resulted in the seven-block reorg.
The issue would not have happened if all validators were running the same configuration. This highlights that all validators must hard-fork to the Merge updates previous to the Merge, or be kicked out of the consensus.
What happens to reorgs after the merge?
The difficulty of reorging will continue to increase slowly over time. However, as the Ethereum Beacon Chain implements Proof-of-Stake, they will introduce the fork choice rule called Gasper.
The Gasper fork choice rule would make attacking the Ethereum blockchain extremely difficult since attester votes and attestations are introduced, giving "weight" to a block.
Controlling the attesters means controlling the fork choice rule. This makes single block reorgs more difficult since attacks on only a few controlling validators would need to compete with several thousands of attesters.
What are Proposers and Attesters?
Proposers and Attesters are two important roles in the Gasper fork choice rule: Proposers are validators tasked with proposing a new block every 12 seconds into a “slot,” and Attesters are validators that vote on what they consider the head of the canonical chain.
One Proposer validator is usually selected randomly and chosen as part of a committee from about 1/32 of all validators. Within this committee, there are also Attesters.
The votes of Attestors are called attestations and give “weight” to the block, meaning that controlling attesters also grants you the ability to control the fork choice rule.
Since the committees are chosen randomly consisting of Proposers and Attesters, there isn’t a way for attackers to concentrate their validators into a specific slot.
Overall, reorging will become less of a concern since being able to reorg a block as a single or small group of attestors will only become more difficult. In addition, Ethereum developers can make changes to the fork choice rule in order to increase requirements for reorgs or find a solution for moving towards a single slot finality consensus. Single slot finality consensus would make the user experience better, create better MEV reorg resistance, and cut protocol complexity and bugs.