Inborg Upgrade for Polygon PoS Network through two proposals

Inborg Upgrade for Polygon PoS Network through two proposals Inborg Upgrade for Polygon PoS Network through two proposals

The Polygon Improvement Proposal (PIP) infrastructure, which is similar to the EIP infrastructure, sets in place a coordination layer in the case of all upgrades carried out on the Polygon PoS. This provides the opportunity for the ecosystem consensus to be introduced in the forum and the Polygon Protocol Governance Calls. 

In the case of the upgrade of Inborg, which is activated by the PIP infrastructure, there are two proposals. The first is Indore (PIP-12), a suggested upscale for the State Sync system for furthering the network balance and doing away with BADBLOCK errors. The second is the Aalborg (PIP-11), which brings in the idea of milestones for quicker finality on the Polygon PoS network. 

The Polygon PoS network depends on a double consensus framework: Heimdall, which is an authenticator layer, and Bor, which is a block producer layer. Heimdall is responsible for activating the State sync system, through which the network can read data derived from Ethereum. The data is then shifted to Bor. Bor brings the State Sync Ethereum from Heimdall at the beginning of each sprint.   

Advertisement

This is done through “fromID”, which is a value that is unlike any other and an added identity of the state. The other is “to”, a value that is a timestamp. In other words, at the beginning of each sprint, Bor calls for all State Sync events that have taken place between two separate points, fromID and value, at a certain time. 

In this phase, the data from Ethereum is collected and read in Heimdall. The calculation of the value is determined by considering the current block at the beginning of the sprint and taking away the recent sprint length. 

There is a time when some of the blocks created in the Bor layer disintegrate into multiple worlds. For the Polygon network, it suggests that a node is offline and creating blocks by itself. After a while, it comes back online. In this case, two parallel partitions, chain A and chain B, are built, having two different truths regarding the status. 

With the two dimensions overlapping, there is uncertainty about the real-time spelling out of an array of retrieving State Sync events from Heimdall. Here, PIP suggests a fresh root parameter known as stateSyncConfirmationDelay that is instrumental in altering the way to gauge the “to” time value.

Advertisement

In the scenario of a parallel dimension, there is a shared timeline, which improves the balance of the network and does away with BADBLOCK errors. Through SyncConfirmationDelay, similar State Sync events will come back from Heimdall in every case.