Bridge is unnecessarily waiting for 13 blocks of confirmation from Ethereum and other L2 or PoS/PoA chains

Analysis from AI:

Ethereum PoS Reorganization Risk Post-Merge: Confirmations vs. Security

Introduction

Ethereum’s post-Merge Proof-of-Stake (PoS) consensus brings deterministic finality after 2 epochs (~64 blocks, about 13 minutes) . Before finality is reached, however, there is a non-zero risk that recent blocks could be reorganized (reverted) by an alternate fork. We analyze how waiting for additional block confirmations (1 to 100 blocks) increases the security of a transaction. We present a simplified probabilistic model of reorg risk at various confirmation depths and compare it with empirical data from Ethereum mainnet. Two scenarios are considered: (a) an honest majority with no malicious actors, and (b) an adversary with <33% of stake attempting to cause a reorg. We then quantify the incremental security gained per additional confirmation leading up to finality.

Probabilistic Model of Reorg Risk per Confirmation Depth

Reorg Risk Basics: In Ethereum PoS, one validator is randomly chosen to propose a block each 12-second slot, and committees of validators attest to the chain’s head. Forks (temporary chain splits) can occur due to network delays or malicious withholding of blocks. The fork-choice rule (LMD-GHOST) selects the branch with the heavier weight of accumulated attestations . Thus, a block becomes harder to revert as more subsequent attestations and blocks build on top of it. Finality (via Casper-FFG checkpoints) then cements blocks irreversibly once two consecutive supermajority votes (2/3 of stake) occur .

• Honest Majority (No Malicious Actor): With all validators honest, unintentional forks are rare. Only network latency or simultaneous block proposals can cause a short reorg. In PoS Ethereum, accidental reorgs are far less frequent than under PoW . The vast majority of fork resolutions affect at most the latest block. Each additional confirmation (block deeper in the chain) dramatically lowers the chance of a reorg, since it would require multiple consecutive slots of network failure or coincident forks, which is extremely unlikely. In a simplified model, if the probability of a one-block fork in a given slot is p (very small), the probability of a fork spanning 2 consecutive blocks is on the order of p² (nearly zero for small p). In practice, no reorg deeper than 1 block has been observed on Ethereum mainnet post-Merge under normal conditions. Thus, under honest operation, the risk after 2+ confirmations is negligible.

• Attacker with <33% Stake: Now consider an adversary controlling a fraction f of total stake (e.g. 10%, 20%, or up to just under 33%). This attacker cannot finalize a malicious chain (since finality requires ≥66.6% vote), but they can attempt to temporarily outrun or outweigh the honest chain before finality. The attacker’s strategy would be to withhold blocks they are scheduled to propose and later release a competing fork. To successfully revert a chain of length N (i.e. cause an N-block reorg), the attacker needs to accumulate comparable weight (attestations) on an alternate chain. In simple terms, this often means the attacker must be lucky enough to control a significant fraction of the next N block proposals – effectively outpacing the honest chain in that window . We can model the chance of a reorg of depth N as roughly the probability the attacker produces >50% of blocks in that span (since >50% of proposal power would likely lead to their fork becoming heavier in votes). For an attacker with stake fraction f, the probability of controlling more than half of N slots is the upper tail of a Binomial(n=N, p=f). This probability drops exponentially as N grows when f < 0.5. For example, if f = 30%, the attacker’s chance to dominate even a 6-block window is on the order of a few percent, and it falls to under 0.1% beyond ~30 blocks. By the time you approach 64 blocks, an attacker with <33% would need an extraordinarily implausible streak of successes to still pose a risk. In practice, each additional confirmation makes it exponentially harder for a <33% attacker to succeed in a reorg, long before finality kicks in .

Empirical Reorganization Data on Ethereum Mainnet

Real-world data from Ethereum post-Merge confirms that chain reorganizations have been extremely shallow and infrequent:

• Frequency of Reorgs: According to one analysis (Jump Crypto, Mar 2023), Ethereum’s PoS chain experienced around 90 short reorgs in the months following the Merge, none deeper than 1 block . These were likely due to benign causes like network asynchrony or two validators proposing near-simultaneously, and the fork choice quickly resolved them in the next slot. In other words, a block occasionally gets orphaned by a competing block in the next slot, but a two-block sequence has not been reversed. This is a stark improvement over the PoW era, where minor forks (including uncles) were much more common .

• No Known Deep Reorgs: Aside from test scenarios and a 7-block reorg on the early Beacon Chain in 2022 (pre-merge incident due to client software discrepancy) , Ethereum mainnet has not seen deep reorg events under PoS. Even during the finality lapse in May 2023 (when many validators went offline temporarily), the network continued producing blocks on a single chain—finality was delayed but not reversed . This suggests that under honest conditions, the probability of a reorg deeper than 1 block is so low that none have occurred over millions of slots .

• Attacks in Practice: Thus far, no adversarial reorg attacks have been observed on mainnet (likely due to strong economic disincentives — attackers would get slashed and lose stake). However, academic work has demonstrated theoretical attack strategies. For instance, the “Avalanche attack” shows how an attacker could use withheld blocks and equivocation to amplify their effective weight and cause deeper reorgs than their stake alone would suggest . Simulations with ~33% malicious stake have managed to revert dozens of blocks in a private setting . Ethereum has added mitigations (e.g. ignoring equivocated votes and proposer boost to honest head starts) to make such attacks harder . Importantly, these attacks remain theoretical on mainnet – they require a very large (yet <1/3) attacker and precise coordination. So while the empirical reorg rate on Ethereum is virtually zero beyond 1 block in honest conditions, an active attacker could still, in theory, attempt a multi-block reorg before finality. This is why confirmation depth (or explicit confirmation rules) still matter for high-value applications that can’t wait for finality .

Security vs. Number of Confirmations (1–100 Blocks)

Each additional block added on top of a transaction before finality provides an incremental increase in security. The table below summarizes how the reorg risk diminishes as confirmations accumulate (from 1 block up to 100 blocks), under both honest and adversarial scenarios:

Confirmation Depth | Reorg Risk (Honest Majority) | Reorg Risk (Attacker <33% Stake) -- | -- | -- 1 block (~12s) | Moderate: 1-block forks observed occasionally (e.g. ~0.0075% chance) . Not final – can be orphaned by a competing block in next slot. | Highest: If attacker controls the proposer, they can replace this block. Up to ~30% chance an attacker with 30% stake was the proposer (and could attempt a double proposal or withholding attack). 2 blocks (~24s) | Low: Practically no 2-block reorgs seen on mainnet . The second block building on the first makes it much less likely to be reversed. | Significantly Lower: Attacker needs 2 consecutive proposals to beat 2-block chain. For 30% stake, ~9% probability of controlling both slots (0.3²) – otherwise the honest chain wins. 6 blocks (~72s) | Extremely low: No 6-block reorgs ever observed. At this depth the block is very likely to remain canonical absent malicious interference. | Small: The odds that a <33% attacker can reorganize 6 blocks are tiny. E.g. ~7% for a 30% attacker to control ≥4 of 6 slots (a rough requirement for a successful 6-block fork). For an attacker with 20% stake this drops below 2%. Empirically, even under adversarial testing, 6+ block attacks haven’t been seen on mainnet . 12 blocks (~2.5 min) | Virtually zero: The block now has a ~2-minute chain built on it. It’s highly likely to be included in the final history. | Tiny: For 30% attacker, probability of reorging 12 blocks is on the order of 3–4% or less (and would require risking many validators in an attack). Any attacker much below 30% has <1% chance at this depth. 32 blocks (~6.4 min, 1 epoch) | Zero in practice: After one epoch, the entire validator set has attested at least once, anchoring this block in a supermajority vote context. The chain is very stable. | Near-impossible: An attacker around 30% would need an extraordinarily lucky streak to fork 32 blocks. Rough calculation: ~0.5% chance for a 30% attacker to dominate an epoch’s worth of slots. For 20% or less, it’s effectively 0%. 64 blocks (~13 min, ~2 epochs) | Finalized: By around 64 blocks, Ethereum’s consensus will finalize the block (2 epochs of voting) . At this point, reorg risk is essentially zero – reverting it would require >1/3 of stake attacking and causing catastrophic finality failure . | Finalized: Once final, not even a 32% attacker can revert the block without breaking protocol assumptions (and getting slashed). The security is equivalent to the full economic security of Ethereum. 100 blocks (~20 min) | Finalized + beyond: Blocks older than finality are absolutely immutable under the protocol (barring an improbable network partition or social consensus override). Waiting longer than finality does not meaningfully increase security. | Finalized + beyond: Same as honest case – after finality, the attacker’s window to cause reorgs has closed. Any additional blocks are simply overkill for confirmation purposes.

Estimated reorg probability vs. confirmation depth under an attacker scenario (30% stake). Each additional block added before finality sharply reduces the likelihood that an attacker’s fork can outrun the canonical chain. By ~64 blocks (finality), the attacker’s success probability drops to effectively zero.

As shown above, security improves with each block confirmation, but with diminishing returns. The first few blocks (e.g. 1→2→3… up to ~6-12) provide the largest drop in risk, eliminating nearly all accidental-fork scenarios and making even coordinated attacks very unlikely. Beyond about 12 confirmations, the probability of a revert is already microscopic for honest conditions, and even a 30% adversary would find it exceedingly difficult to overturn the chain. By the time you reach 2 epochs (64 blocks), the block is finalized and economically final – an attacker would have to burn a third of all staked ETH (an astronomically costly attack) to even attempt a reorg at that point. In short:

• Under honest operation: waiting just a couple of blocks (e.g. 2+ confirmations) makes a transaction extremely safe, and beyond a dozen blocks the risk is for all practical purposes zero (until finality formally occurs) . Ethereum’s PoS design has dramatically reduced random reorgs compared to PoW .

• Under a <33% attacker scenario: each extra confirmation exponentially decreases the attacker’s odds of success. For example, an attacker with 30% stake has a sizable chance to mess with a 1-block confirmation, but by ~6 blocks their chances are under 10%, and by 12+ blocks it’s under a few percent or less. With dozens of confirmations, the attack becomes nearly impossible without exceeding the 1/3 threshold. Waiting for 2 epochs of confirmations (finality) yields absolute security guarantees, as expected . Notably, research into fast confirmation rules (using observed attestations to confirm blocks quicker) found that even with a 30% adversary, confirmed blocks (at ~6+ block depth) remained canonical despite a 2-block reorg occurring in the network – illustrating that a moderate number of confirmations can withstand even deliberate attacks in practice.

Conclusion

Ethereum’s PoS reorg risk drops off rapidly with each confirmation. In an honest setting, one confirmation is usually enough to avoid any issues (though one should be cautious with critical transactions until at least a couple of blocks deep). In adversarial settings, additional confirmations provide strong compounding security: the difference between 1-block and, say, 12-block depth is the difference between a plausible small attack and an almost infeasible one. Ultimately, finality at ~64 blocks provides an ironclad guarantee, but waiting that long (~13-15 minutes ) is not always necessary for most use cases. Many applications find a sweet spot (e.g. 6 or 12 block confirmations) that balances user experience and security, given that empirically no reorgs of that depth have been seen and theoretical risks at that depth are extraordinarily low. In summary, each block added before finality materially increases security, and by the time you approach finality, the risk of reorganization has been minimized to near zero . This layered security model — gradual finality — is a key strength of Ethereum’s PoS: it offers both fast probabilistic security that improves with time and eventual absolute finality for complete certainty.

Sources: Key insights were drawn from Ethereum’s consensus specs and research, Jump Crypto’s analysis of post-Merge reorgs , and studies on confirmation rules and attacks , as cited throughout.

harmony-one / layerzero-bridge.frontend

Bridge is unnecessarily waiting for 13 blocks of confirmation from Ethereum and other L2 or PoS/PoA chains #34