Network
Launch Date
Consensus
Note
Sepolia
Oct 2021
PoW
Like-for-like representation of Ethereum
Görli
Jan 2019
PoA
Proof-of-Authority
Kiln
Mar 2022
PoS
Post-Merge (for ETH2), shadow fork of the mainnet
Kintsugi
Dec 2021
PoS
DEPRECATED, use Kiln; post-Merge (for ETH2)
Ropsten
Nov 2016
PoW
DEPRECATED, use Sepolia; the Merge to happen on Jun 8, 2022
Rinkeby
Apr 2017
PoA
DEPRECATED, use Görli and Görli Faucet
Kovan
Mar 2017
PoA
DEPRECATED, use Sepolia or Görli
List of active and deprecated Ethereum testnets, including Kintsugi.
Features
Optimistic rollup 
ZK-rollup 
Proof
Uses fraud proofs to prove transaction validity. 
Uses validity (zero-knowledge) proofs to prove transaction validity. 
Capital efficiency
Requires waiting through a 1-week delay (dispute period) before withdrawing funds. 
Users can withdraw funds immediately because validity proofs provide incontrovertible evidence of the authenticity of off-chain transactions. 
Data compression
Publishes full transaction data as calldata to Ethereum Mainnet, which increases rollup costs. 
Doesn't need to publish transaction data on Ethereum because ZK-SNARKs and ZK-STARKs already guarantee the accuracy of the rollup state. 
EVM compatibility
Uses a simulation of the Ethereum Virtual Machine (EVM), which allows it to run arbitrary logic and support smart contracts. 
Doesn't widely support EVM computation, although a few EVM-compatible ZK-rollups have appeared. 
Rollup costs
Reduces costs since it publishes minimal data on Ethereum and doesn't have to post proofs for transactions, except in special circumstances. 
Faces higher overhead from costs involved in generating and verifying proofs for every transaction block. ZK proofs require specialized, expensive hardware to create and have high on-chain verification costs. 
Trust assumptions
Doesn't require a trusted setup. 
Requires a trusted setup to work. 
Liveness requirements
Verifiers are needed to keep tabs on the actual rollup state and the one referenced in the state root to detect fraud. 
Users don't need someone to watch the L2 chain to detect fraud. 
Security properties 
Relies on cryptoeconomic incentives to assure users of rollup security. 
Relies on cryptographic guarantees for security. 
Start building
on Alchemy.
Sign up for free
Start building on Optimism.
Sign up for free
Start building on Arbitrum.
Sign up for free
Start building on Ethereum.
Sign up for free
Start building on Polygon.
Sign up for free
Start building on Starknet.
Sign up for free
Start building on Flow.
Sign up for free
kiln faucet
Get free Kiln ETH.
Start building today
Goerli faucet
Get free Goerli ETH.
Start building today
mumbai faucet
Get free Mumbai Matic.
Start building today
rinkeby faucet
Get free Rinkeby
ETH.
Start building today
Start building on Ethereum.
Get started for free
Start building on Ethereum.
Get started for free
Start building on Flow.
Get started for free
Start building on Polygon.
Get started for free
Start building on Starknet.
Get started for free
Start building on Optimism.
Get started for free
Start building on Solana.
Get started for free
Start building on Solana.
Sign up for beta access
Start building on Solana.
Join the waitlist
Arbitrum logo
Start building on Arbitrum.
Get started for free
Learn
Solidity at
Alchemy
University
Get started today
curl 
https://release.solana.com/v1.10.32/solana-install-init-x86_64-pc-windows-msvc.exe 
--output 
C:\solana-install-tmp\solana-install-init.exe 
--create-dirs
Ethereum
REORG OVERVIEW

What is a chain reorganization (reorg)?

What it Is, How They're Caused, and What Happens Next
Last Updated:
June 21, 2022

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. 

2.Node Costs 

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. 

3. Uncertainty

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?

Image from Preethi Kasireddy

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:

  1. Nakamoto
  2. GASPER
  3. Tendermint
Image from Paradigm

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.

Image from Terrence Tsao

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.

Post-merge Problem?

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.

ALCHEMY SUPERNODE - ETHEREUM NODE API

Scale to any size, without any errors

Alchemy Supernode finally makes it possible to scale blockchain applications without all the headaches. Plus, our legendary support will guide you every step of the way.

Get started for free
Supernode footer
Ethereum
REORG OVERVIEW

What is a reorg?

What it Is, How They're Caused, and What Happens Next
Last Updated:
June 21, 2022
Don't miss an update
Sign up for our newsletter to get alpha, key insights, and killer resources.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

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. 

2.Node Costs 

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. 

3. Uncertainty

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?

Image from Preethi Kasireddy

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:

  1. Nakamoto
  2. GASPER
  3. Tendermint
Image from Paradigm

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.

Image from Terrence Tsao

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.

Post-merge Problem?

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.

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. 

2.Node Costs 

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. 

3. Uncertainty

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?

Image from Preethi Kasireddy

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:

  1. Nakamoto
  2. GASPER
  3. Tendermint
Image from Paradigm

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.

Image from Terrence Tsao

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.

Post-merge Problem?

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.

Build web3 with Alchemy

Alchemy combines the most powerful web3 developer products and tools with resources, community and legendary support.

Get started for free