A hard fork happens when the node software changes in such a way that the new version is no longer backward-compatible with earlier blocks. This is usually the result of a change in the consensus logic, meaning that blocks validated using the latest software will produce a different hash.A block number is selected before which all nodes in the network should have upgraded to the new version. Nodes running the old version will be disconnected from the canonical chain after the hard fork block.Should there be staked POL in disagreement with the fork, two canonical chains will temporarily form until the end of the current span. Afterwards, Bor will stop producing blocks, and the chain will halt until consensus is reached.In contrast, a soft fork is backward-compatible with the pre-fork blocks. This type of protocol change does not require nodes to upgrade before a deadline, so multiple versions of the node software can run simultaneously and still validate transactions.
- Users
- Token holders
- Validators
- Infrastructure providers
- Full nodes
- Core developers
Ecosystem consensus
The preliminary ecosystem consensus takes place through an off-chain process involving key stakeholders, including users and core developers. The framework accommodates different perspectives and provides a platform for constructive discussion and community cohesion. The framework has three key components:- Polygon Improvement Proposals (PIPs): Outlined in PIP-1, PIPs are formal proposals that enable the community to put forward protocol upgrades. The framework is modeled on Ethereum’s EIP process, with guiding principles from the IETF and the broader open-source community.
- Polygon Protocol Governance Call (PPGC): Synchronous discussions where “rough consensus” is established. The technical community uses these calls to decide which PIPs are included in a given upgrade and the rollout schedule.
- Polygon Community Forum: A space for long-form discussions ranging from high-level meta discussions to low-level technical details.
Implementation
The PoS network runs two clients simultaneously:- Heimdall: the consensus layer client. See GitHub.
- Bor: the execution layer client. See GitHub.
- The protocol decision is ratified on a PPGC, and implementation begins in the relevant GitHub repositories.
- Core developers create pull requests containing the changes, which are merged into the codebase, and a new release tag is created.
- Core developers test new releases on local devnets. If everything functions normally, the tag is marked as beta (pre-release).
- The changes are deployed to the Amoy testnet and left to run for at least one week. The Amoy Testing Committee reports on stability in the PPGC.
- Once confirmed stable, the upgrade is scheduled for mainnet release on a PPGC. The tag version is marked final.
- Validators upgrade their nodes to the latest version. The upgrade becomes canonical through onchain consensus of the validating stake, including delegated stake from token holders.
Onchain consensus
Onchain consensus parameters are inherited from CometBFT, which requires at least of the total validating stake to be in favor of the upgrade. For the chain to remain stable after the change becomes canonical, non-validating full nodes must also upgrade to the latest version. Key ecosystem stakeholders such as dApps, exchanges, and RPC providers run full nodes. These nodes propagate transactions and blocks, and can accept or reject blocks. This makes them enforcers of the network consensus rules and vital to the onchain governance process. If these nodes are incompatible with the changes, users and dApps would find their transactions invalid.Onchain governance module
The Heimdall client has an in-built governance module that can carry out consensus parameter changes across the network without a full client upgrade:- Proposals are submitted to the onchain module along with a deposit containing the proposed changes.
- Each validator tallies votes cast by the validator set.
- When the defined voting parameters are met, each validator applies the upgrade with the proposal data.
| Parameter | Value |
|---|---|
| Quorum | 33.4% |
| Threshold | 50% |
| Veto | 33.4% |