Faster Finality with the Aalborg Upgrade for Polygon Proof-of-Stake Network

Right now, the Polygon proof-of-state (PoS) network has slow deterministic finality. 

In other words, a transaction is final for users and dApps based on the number of confirmed valid blocks on top of the block with the transaction. It’s a waiting game until enough blocks have passed that the transaction is considered final (and ultimately checkpointed to Ethereum).

A new proposal for Polygon PoS would significantly speed up this process, by about 5 or 6x–and in so doing, decrease the probability of deep reorgs, while also improving user experience.

A Polygon Improvement Proposal (PIP), PIP-11, outlines an upgrade to the Polygon PoS protocol that will speed up time to finality by introducing a concept called “milestones.” Should the community approve, milestones mean block finality will become deterministic after a certain (variable) number of blocks–and mirror similar architecture found in the Ethereum network.

Why does this matter? 

Because it means both users and developers can identify finality much sooner than before the upgrade. The chance of deep reorgs decreases, leading to a healthier, more predictable network.

This post breaks down how milestones utilize network architecture to improve time to finality and further reduce the possibility of deep chain reorgs. Right now, the Aalborg upgrade is scheduled for block number 15,950,759, which is estimated to be on October 11th based on average block time, with a variable of plus or minus a couple days.

Okay, so what are milestones?

Every milestone is actually a length of continuous Bor blocks, capped by an “endBlock,” and agreed upon by consensus. 

These sets of continuous blocks introduce finality much faster than prior to the upgrade.  

How does this all happen? 

Remember that Polygon PoS uses a dual-chain architecture: a validator layer, Heimdall, and a block producer EVM compatible layer, Bor.

Heimdall does the tricky stuff of validating Bor blocks by using an implementation of the Tendermint consensus engine. Periodically, Heimdall “checkpoints” to Ethereum, which means aggregating Bor blocks and posting the Merkle root to L1, thereby providing finality for the root chain. 

Checkpoints are basically a way of saying, “Here is all the activity that has occurred on the side chain nodes, fyi.” 

In the context of the Aalborg upgrade, Heimdall will be the source of truth. Milestones are to Heimdall what checkpoints are to Ethereum: code that signals finality. 

A new MilestoneValidatorSet will be defined to select, based on weighted stake, a milestone proposer. This proposer will be responsible for fetching the endBlock root hash and broadcasting to all Heimdall nodes. Other Heimdall nodes vote and if 2/3+ majority agree, the milestone has passed.

Doing so signals a milestone, and reaches deterministic finality. 

Bor, meanwhile, is a VM that is EVM-compatible. This is where transactions on the Polygon network are aggregated into blocks by Bor producers. 

In context of the milestone upgrade, Bor nodes will constantly be checking in with Heimdall to make sure the hash of their local node matches up with that of the canonical and most recently whitelisted milestone. 

Assuming the fetched milestone data match that of a node’s local chain–that the blocks and state transitions and all the stuff of Polygon PoS are the same–then that milestone is whitelisted. It becomes final. 

But if there’s a mismatch, if there’s a discrepancy between what a block producer sees locally and the milestone that has been fetched, then the node rewinds to the last whitelisted milestone. A failsafe.

With this new architecture, finality becomes fast, while at the same time ensuring that the wrong chain isn’t followed for too many blocks. In fact, there’s a cap for the automatic rewind feature in the case of a mismatch milestone, a hard limit of 255 blocks. After that, it’s not possible to go farther back.

Simulated tests indicate a big increase in finality speed, like ~5 to 6x.

Put it all together, you get:

• Fast finality
• Fewer reorgs
• Better UX

Researching and deploying software updates is like tuning a radio station, requiring finesse to get the sound just right. 

That’s why this proposed upgrade has been through audits, with all suggestions already incorporated. Additionally, the PIP has been discussed at length and multiple times in the forum, with robust feedback from the community. This upgrade will help the Polygon PoS network feel that much better for users.

Consensus + Backwards Compatibility

In a decentralized network like the Polygon PoS chain, governance requires buy-in of network operators–e.g. the validators, node operators, and RPC providers. 

Already, the community has been active in forum discussions around PIP-11. Any community member has had the chance to hop onto the forum and leave feedback and thoughts about the proposal. 

Still, because the upgrades in this PIP are not backward compatible, this will result in a hard fork.

Note that all upgrades reach consensus through “rough consensus” on-chain–not unlike Ethereum, which underwent two major upgrades recently: the Merge and the Shapella hard fork. 

Feeling like learning more? There’s even more technical detail in the PIP. Be sure to check it out, follow our blog, and stay tuned on socials!

Website | Twitter | Developer Twitter | Forum | Telegram | Reddit | Discord | Instagram | Facebook | LinkedIn

‍