The Ethereum beacon chain, which will be crucial to the Ethereum Merge scheduled for later this year, today experienced a potentially high-level security risk known as a blockchain “reorganization.”
A reorganization, or reorg, can happen either through a network failure, such as a bug, or a malicious attack, temporarily resulting in a duplicate version of a blockchain. The longer a reorg lasts, the more serious the consequences.
Today’s reorg on the Ethereum Beacon Chain lasted seven blocks—the longest such reorg in years, according to Martin Köppelmann, CEO and co-founder of DeFi service provider Gnosis.
The Beacon Chain, which launched on December 1, 2020, introduced native staking to the Ethereum blockchain. Staking, which involves pledging assets to a network, is how validators will become eligible to add blocks to the chain, a main tenet of the proof-of-stake consensus model.
The Ethereum Merge, previously referred to as “proof of work to proof of stake. The merge, scheduled for August, will combine the Beacon Chain with the Ethereum mainnet. That means problems with the Beacon Chain could potentially further delay the merge. ,” is a significant and long-awaited upgrade to the current network and will mark its transition from
Köppelmann noted today’s Ethereum reorg in a Twitter thread, saying that it’s evidence there’s more work to be done ahead of the merge.
“This shows that the current attestation strategy of nodes should be reconsidered to hopefully result in a more stable chain,” he wrote.
The Ethereum beacon chain experienced a 7-block deep reorg ~2.5h ago. This shows that the current attestation strategy of nodes should be reconsidered to hopefully result in a more stable chain! (proposals already exist) pic.twitter.com/BkQrKuUlw1
— Martin Köppelmann 🇺🇦 (@koeppelmann) May 25, 2022
A reorg occurs when two different miners start working on adding blocks of transactions with similar difficulty to the chain at the same time. That creates a fork, or a duplicate version of the blockchain.
A miner adding the next block has to choose which side of the fork is the correct, or canonical, chain. Once they’ve done that, the other one is lost.
A seven-block reorg means that the fork that was eventually dropped had seven blocks worth of transactions added to it before the network decided it wasn’t the canonical chain. Every block on the Ethereum chain contains roughly anywhere between 200 to 300 transactions and has a value of about 2 ETH, or roughly $4,000, according to Etherscan.io.
When there are two competing versions of a blockchain, even if only for a little while, there’s risk that someone will be able to spend the same assets twice.
When this is done maliciously, like with the ZenGo wallet attack in 2020, it's known as a double-spend attack. In such an attack, fraudsters send a transaction with a minimum fee and then immediately override it by increasing the fee (so miners will be incentivized to verify the more profitable new transaction first) and redirecting funds to a different address.
But in this case, the cause of the reorg and potential for double-spend seems to have been benign.
The software that miners use has a method for determining which side of the fork to choose—that’s the attestation strategy Köppelmann was referring to.
The Twitter thread eventually drew the attention of some of Ethereum’s core developers. Ethereum founder Vitalik Buterin himself chimed in to add some weight to a theory that the problem was caused by miners running outdated versions of mining software.
In this case, client teams have been scrambling to understand the situation so they can figure out what to fix for the last couple of hours! Already some good hypotheses:https://t.co/VbgjWloK8c
— vitalik.eth (@VitalikButerin) May 25, 2022
It was a timely response.
Last year, Buterin and Georgios Konstantopoulos, the chief technology officer at Paradigm, tackled the issue of reorgs in a blog post. In it, they said that a reorg of more than five blocks could be a sign of a malicious attack.
They explained that short one- and two-block reorgs happen all the time because of network latency.
“Occasionally, bad luck can lead to 2-5 block reorgs,” Buterin and Konstantopoulos wrote in the post. “Reorgs longer than that are almost always due to extreme network failure, client bugs, or malicious attacks.”
But as Prysm developer Terrence Tsao explained in a Twitter thread, today's reorg, even though it lasted long enough to raise serious concerns, may have just been another case of bad luck.