Agenda and Meeting Overview

The 25th Polygon Protocol Governance Call covered four main areas. Firstly, debriefing the progress and status of the mainnet implementation of the Ahmedabad hard fork. Secondly, a retrospective on the testnet phase of the Ahemdabad Hard Fork. Thirdly, an update on PIP-36 which involves replaying failed state syncs. Lastly, PIP-47 which pushes upgrades to the Polygon Protocol Council.

PIPs discussed 

• PIP-36: Replay Failed State Syncs
• PIP-47: Multi-threshold multisig system to the Protocol Council

Ahemdabad Hard Fork Debrief

Earlier on September 26th the Ahmedabad hard fork landed on mainnet successfully. In this section Sandeep Sreenath from the Polygon team debriefed the current status of the hard fork. 

Overall the Polygon PoS network parameters are stable and 100% of validators signed checkpoints right after the hard fork reached mainnet. All the changes and new PIPs that needed to be implemented have been re-verified after the hardfork was implemented on mainnet. These changes include PIP-30, which increases the max code size limit to 32 KB from the current 24 KB, PIP-36, which adds a feature to replay failed statesync transactions, and PIP-45 which is the ticker change from MATIC to POL. 

There was a minor issue found after the Ahmedabad hard fork where the wMATIC to wPOL migration was not effective which was identified immediately when the hard fork went live on Amoy testnet. It was fixed prior to the hard fork being implemented on to Polygon mainnet. The fix was in the form of Gandhinagar hard fork on the Amoy testnet. The team prefaced that when a hard fork goes through there is a contract change and bytecode change in the contract. There was a bug in this change that resulted in the “init code” not working. There are several key functions in the hard fork that require the “init code” to function. The issue was that the hard fork only replaced the byte code but did not run the “init code” so the team rolled out a quick fix and the hard fork on mainnet went smoothly.

PIP-36: Replaying Failed State 

Simon Dosch from the Polygon Labs team discussed how PIP-36 makes the state-sync mechanism more robust by allowing for failed state syncs to be replayed. There were a few cases of state sync failing due to an old change that used the “dot transfer” method in solidity which has a fixed gas limit. This resulted in some cases of smart wallets being unable to receive any tokens. 

An example of what would happen: If you sent a token to Polygon mainnet and the receiver was a smart contract wallet, any additional computations done by the smart contract wallet resulted in a failed transaction. This indicated that the state sync failed and there was no way of replaying the state sync and retrieving those stuck funds until this change. This upgrade not only solves this particular problem but also allows for funds to be retrieved in the future if there are any bugs that result in failed transactions from failed state syncs. The last step they are implementing is to upload a merkle route against which one can prove that their state sync is part of the list of failed states that was identified. And then if that's the case, the contract will attempt to replay it, and if it works, the transaction will go through.

Retrospective on The Testnet Phase of The Ahemdabad Hard Fork

Stake Vault, a member of the Amoy Committee, discussed a few key bug fixes for Polygon’s block production layer known as Bor along with a bug with the Ahmedabad Hard Fork that was caught and fixed on Polygon’s Amoy testnet. 

There were several bug fixes to Bor ranging from 1.3.4 to 1.3.7 within a month's time. Bor 1.3.6 was formally released for a security bug with the help of both mainnet and testnet validators who got the fix up and running quickly. There was also the 1.4.1 Bor Release which was a fix to a security bug with parallel execution that was released on September 18th. All these new releases are stable and have seen fast adoption from testnet and mainnet validators. There were some issues in the 1.3 upgrades where testnet and mainnet validators were seeing an “Out-of-Sync Error” but the team has created fixes for that as well. 

The Ahemdabad hard fork on Amoy testnet was the 1.4.0 beta release which was upgraded successfully without error. As mentioned earlier, there was a 1.4.0 beta two release to fix the wMatic to wPol issue on September 18th on the Amoy testnet which also went smoothly. There was minimal downtime and the only downtime was fixed quickly. Most validators have been running with 100% uptime for the past 2 weeks.

Heimdall, which monitors contracts on Polygon, has not changed. The latest versions for the various Polygon protocols for both mainnet and Amoy testnet go as follows: Version 1.0.7 is the latest for Heimdall, version 1.4.1 is the latest for Bor and version 2.60.8 is the latest for Aragon. 

PIP-47: Upgrades to the Protocol Council 

Mateusz the Governance lead at Polygon, along with Carlos the CTO of Aragon, ran through PIP-47 and how it expands the capabilities of the Polygon Protocol Council. PIP-47 is a recently proposed upgrade that is closely related to PIP-29 which was proposed and implemented late last year. PIP-29 introduced a Protocol Council that would govern upgradeable system smart contracts for Polygon PoS. When first introduced the council was limited to two execution tracks. The first was a seven out of thirteen consensus requirement with a ten day time lock that would be the general track and the second was an emergency track which was a ten out of thirteen consensus requirement with no time lock. 

The first instance where the Protocol Council voted to execute occurred with the implementation of the POL token contract. The limitation of PIP-29 meant that only one upgradeable component could be assigned to the multisigs. PIP-47 addresses this and in partnership with the Aragon team, the Protocol council would not be as limited in the number of upgradeable components that could be assigned to the mulisigs.   

For Polygon in PIP-47 they have implemented a feature in Solidity known as “DAO.sol” which is not a DAO in a traditional sense but a contract that allows for executions for certain governance decisions which is then connected to the Polygon Protocol Council Multisig via a plugin known as a “Governor”. Anything that the council wants to come to a decision on is passed to the “Governor” that sits as a middleman function and the proposal based on the vote is passed by the “DAO.sol” executor. Something specified was the process of setting permissions which is predetermined by specifying where one wants to put a permission, who has the permission and what they have permission to do. 

There is also the implementation of a “Failure Map” which is essentially a way for the Protocol Governance Council to set up multi-step executions. An example is if there are five actions the Protocol Governance Council is voting on they can vote for the first three to fail, the fourth to execute with no chance of reversion and the fifth to execute with the opportunity to revert if needed. 

There are three main permissions assigned between the “DAO.sol” executor and the multisig plugin. The first is the permission for “DAO.sol” to update the multisig plugin settings. An example of this is if the seven out of thirteen multisig wants to vote to increase the threshold to eleven out of thirteen they can vote, execute the proposal and it will update the settings. The second permission has two parts, one is to do with upgrading the multisig plugin itself. The second is the execution permission assigned to ‘DAO.sol” which gives ownership over contracts executed through the governance process such as the POL token smart contract. This allows for seamless community involvement and ownership over key upgrades without having to change the address of the executor. The third permission is the ability to create proposals. There is some defined data that is hosted on IPFS along with some defined actions which is execution that comes from “DAO.sol”. There is the ability to customize what are the requirements to make up an on-chain proposal but there are some up front off-chain requirements in the UI such as the title, summary, description, resources, etc. The on-chain requirements are the aforementioned “Failure Map” assigned to the proposal and whether or not it is an emergency proposal which determines what track it would go through for the Protocol Council. Other permissions stored are who can create a proposal, the minimum number of votes to pass a particular proposal, and minimum delay to pass a proposal. 

Example of the proposal process: Once a Protocol council member creates a proposal, all the data that is required for that proposal is stored in that state and members can approve it. The member calls the approve function and the proposal will only pass if the threshold of the minimum number of approvals is reached. The proposal requires a minimum threshold of votes from other members of the Protocol Council. Once it hits those minimum requirements of approvals, there's two things that can happen. If the proposal was an emergency, it requires ten out of thirteen votes and then it can execute right away. But if the proposal is a general one then it requires seven out of thirteen votes and then it's placed in a time lock delay for two weeks.  That's the time that off-chain users have to express their opinions and vote accordingly. After that delay has happened, there is a confirmation period, which is where members come back to the proposal and decide to confirm that they want to execute the proposal. This is also a seven out of thirteen consensus and after that they can execute. 

The first audit for the governance system was conducted by an external third party, Halborne. The followup audit is being done by the internal Polygon team. Much of the code has already been used for the governance of large protocols such as Curve and Lido but the plugin was built bespoke for Polygon and is going under additional security review by the Polygon team. The audits will be published publicly soon. If all things are approved by the Protocol Governance Council then this PIP will be approved and implemented.

Conclusion 

Earlier on September 26th the Ahmedabad hard fork landed on mainnet successfully. The Polygon PoS network parameters were stable and 100% of validators signed checkpoints right after the hard fork reached mainnet. All the changes and new PIPs that needed to be implemented have been re-verified after the hardfork was implemented on mainnet. 

There was a minor issue found in Amoy testnet after the Ahmedabad hard fork where the wMATIC to wPOL migration was not effective which was identified immediately when the hard fork went live on Amoy testnet. It was fixed in the release of the hardfork to Polygon mainnet before it was ever implemented into mainnet. The fix was in the form of Gandhinagar hard fork on the Amoy testnet.

PIP-47 is a proposal being worked on by the Polygon and Aragon teams to expand the capabilities of the Polygon Protocol Council. PIP-47 is a recently proposed upgrade that is closely related to PIP-29 which was proposed and implemented late last year. The security audits for this will be released publicly and if all is approved by the Protocol Council this upgrade will be executed. 

After the success of the Ahmedabad hard fork and the Protocol Council’s vote to implement the POL token smart contract, PIP-47 demonstrates Polygon’s focus on expanding the role of decentralized governance into core protocol upgrades. The next Polygon Protocol Governance Call is scheduled for October 17th.