Proposal: Improved UX with Milestones for Polygon PoS
Table of Contents:
- Abstract
- Motivation
- High-Level Overview
- Current Finality Time Breakdown (256 Blocks)
- Proposed Finality Breakdown
- Milestone Lifecycle
- Testing
Abstract
When a user interacts with the Polygon PoS chain, they need to know when the transaction is finalized. In the current architecture of Polygon PoS, a user needs to wait for a few minutes to make sure that their transaction is included in the canonical chain, which is arguably long. To overcome this issue, we introduce the concept of deterministic finality on the Polygon PoS chain. With deterministic finality, a user can be certain that a finalized block will always be in the canonical chain and, hence, all the blockâs transactions are final. This means that the order and inclusion of these transactions cannot be altered under reasonable assumptions.
Motivation
The driving reason behind this proposed change is primarily to improve user experience. The Polygon PoS chain used to face issues with reorgs that were sometimes deep and didnât account for the finality of the chain. After the Delhi fork, a decrease in sprint length has reduced the case of deep reorgs to a very large extent as a single producer will produce fewer blocks consecutively. In this proposal, we propose the addition of deterministic finality, with the implementation of milestones.This will improve the user experience on the Polygon chain.
High-Level Overview
Milestones are a set of continuous bor blocks that are considered final in the canonical chain.
After every milestone length (min 12 blocks), Heimdall would finalize the end block of every milestone on the Bor chain via Tendermint consensus on the Heimdall layer. Bor nodes would regularly fetch this milestone from Heimdall and make sure that their local chain is matching the received milestone.
If the fetched milestone matches with the local chain then bor node would whitelist that milestone in the local datastore. If it doesnât match the local chain, the Bor node would rewind to the last whitelisted milestone stored locally.
This process would ensure that Bor nodes do not follow the wrong fork for a lot of blocks and, as a result, reach finality much sooner than the current implementation. With the implementation of Milestones, we also introduce a finalized tag on Bor, similar to Ethereum, which gives the latest finalized block in Bor chain.
Current Finality Time Breakdown (256 Blocks)
| Block mining in Bor | 576 sec (256*2.25(avg bor block time)) |
|---|---|
| Total time | 576 |
Proposed Finality Time Breakdown
| Block mining in Bor | 27 sec (12 (sec milestone length) * 2.25 (avg. bor block time) |
|---|---|
| Bor block confirmation | 36 sec (16 block confirmations * 2.25 (avg. bor block time) |
| Milestone proposal in Heimdall | 8 sec (heimdall block time) |
| Passing of Milestone proposal | 24 sec (3 heimdall blocks) |
| Milestone fetch interval in bor | 10 sec (timer interval in bor) |
| Total (Average case scenario) | 105 sec |
Milestones reduced total time to finality by 471 seconds.
Milestone lifecycle
The below image represents the lifecycle of a milestone and interactions between the bor and heimdall client during the process:
Testing
For simulating the network, we created multiple devnets of different validator node counts (3, 5, 7 etc.). Below is a sample of finality block confirmations, obtained on a 7-node network:
Currently, dapps are using high block numbers as the limit for bor chain confirmations to make sure that the bor chain no longer reorgs and the transactions and blocks are considered finalized. Based on our findings from the tests performed on devnets, after the introduction of milestones, we have seen much faster finality (~5 to 6 times faster) being achieved on the network. Ranging from 33 blocks to 48 blocks in different scenarios (network delays taken into account), resulting in a better user experience.
