Polygon’s major block reorg problem, and why transactions 5 minutes before can be invalidated

TL;DR:

The Polygon PoS network has a unique block production mechanism (of sprintLength = 64) where 128-depth reorgs (5 minute Tx reversals) can happen as easily as 1-depth reorgs on other blockchains. It has more double-digit-depths reorgs than its competitors. Here’s why that’s happening.

There are a lot of things I like about Polygon: it’s fast, it’s cheap, it has a thriving developer community. Like most EVM-blockchains, it has easily-auditable smart contracts.

However, it does have a serious design flaw unique to its blockchain where 10+ depth block reorgs are happening DAILY.

Block reorgs happen when previous blocks are invalidated. Any transactions from those blocks are removed from the blockchain. Most blockchains that have probabilistic finality tend to have these occasionally, but they’re usually only of 1 depths, which means only the previous block was overwritten.

For example, Bitcoin has already had at least two 1-block reorgs in Jan 2023. That’s not a big issue since most clients wait several blocks before assuming probabilistic finality. But when transactions from 30-100 blocks ago get reversed, that’s a big issue.

Reorgs are happening frequently on Polygon at high depths

• Polygon PoS:
  • Polygon PoS has had 654 reorgs in the past 121 days, or about 5 reorgs a day
  • A third of these had double-digit block reorg depth
  • Every week, there’s usually at least one with a reorg depth of 30+ blocks. At 2-second block times, that’s a minute of blocks re-written.
  • Here’s one from a month ago that had a reorg depth of 120 blocks. That’s transactions from 4 minutes before getting re-written. That’s an order of magnitude faster than slow networks like Bitcoin, but bad for a fast blockchain like Polygon PoS.
  • The only other blockchain with more frequent invalid blocks is Solana (by a wide margin)
  • 2/3rds of the reorgs are caused by 1 single validator, which is also number 3 on the list of top validators.

For comparison to similar blockchains:

• Ethereum:
  • Only had 33 reorgs in 121 days, or 1 reorg every 4 days
  • Reorgs are all at 1 depths
  • Thus, you only need to wait 24 seconds probabilistic finality
• BSC:

Faster block times usually lead to more reorgs while more centralization leads to fewer block reorgs. Polygon is closer to BSC with its fast 2s block times and under 100 validators. You would assume that those validators would be of higher quality and not making so many reorgs.

So why is this issue so prevalent on Polygon PoS compared to other chains?

• Polygon uses 2 blockchain protocols for consensus: a GETH-based blockchain (Bor) for block production and a Tenderment-based blockchain (Heimdall) for validation.
• For efficiency, Polygon’s Bor block producers will produce sprintLength number of blocks in a row instead of switching every block before delivering them to Heimdall.
• That means if a validator accidentally missed blocks from the previous block producer’s sprint, they can reorg up to a depth of 2x sprintLength blocks.
• At 64 sprintLength, this means a max of a 128-depth block reorg.

Upcoming PIP-5 update mitigates, but doesn’t eliminate the problem

There is an upcoming update that proposes to reduce SprintLength from 64 to 16. Unfortunately, this only reduces maximum reorg depth from 128 blocks to 32. That means you can still get a reorg from 32 blocks ago, or about 1 minute. Much better, but still ugly.

Until then, please realize that your Polygon PoS transactions are NOT final until waiting about 128 blocks or 4.5 minutes.