Polygon System Smart Contracts Governance
A need for security, as well as for the ability to seamlessly move to an improved version under specific circumstances, dictates the requirement for upgradeability as it relates to core pieces of blockchain architecture implemented in the form of smart contracts. These types of contracts usually have the ability to influence user funds directly or indirectly via manipulation of the infrastructure and its desired functioning.
The need for upgradeability of system smart contracts has been apparent for some time in the L2 space. From Optimism, through Arbitrum, to Zksync, the need for an efficient way of patching bugs and otherwise upgrading crucial pieces of the architecture persists.
While the underlying motivation for upgradeability is clear, the expression of that motivation varies between different types of contracts. A mechanism for upgrading the sequencer in a zk-based rollup will operate under a different set of risk assumptions than a bridge contract securing user funds. While both of them may be considered system smart contracts, the way that upgradeability is approached can differ greatly.
In this post, we want to present some of our initial thinking into the governance of upgradeable contracts as it relates to Polygon protocols.
The Tradeoffs
As was mentioned in the introductory post, one needs to balance multiple potentially-competing interests, including decentralization, immutability, and security, when designing governance frameworks.
On one end of the spectrum, we can see multi-signature wallets (or councils) composed of trusted community members as the only group capable of performing system smart contract upgrades. These types of setups are widely considered the most efficient in executing time-sensitive upgrades targeting dangerous bugs. However, they’re largely criticized for the concentration of power in the hands of the few, with potential dangers connected to keys being compromised or mishandled, resulting in catastrophes, e.g., Ronin bridge hack. One potential countermeasure against these types of scenarios is wide-spread timelocks, which require every council-initiated transaction to be held in a timelock before execution, allowing the community to look into the upgrade and exit the system with its funds (or coordinate countermeasures otherwise), were a malicious transaction to be initiated. At the same time, timelocks can’t fix everything - since the transaction is public once initiated, any potential hacker may inspect it and extrapolate the knowledge of how to exploit funds before the upgrade goes through, thus rendering timelocks dangerous for critical bug fixes.
On the other end of the spectrum, one can see a fully community-owned upgrade process, with tokens serving as a proxy for voting power. These types of systems, with seemingly less concentration of power, tend to solidify influence around several wealthy and active governance participants, if not enough thought was put into the specific voting model. While growth and adoption of decentralized governance primitives happens slowly, we can hopefully look towards complex voting structures that include delegation and weighted token-voting gaining traction. Importantly, one of the most crucial security guarantees for a community-owned upgrade process comes from the community. Social consensus and coordination are capable of providing the last line of defense for any decentralized governance. A highly-informed community provides a strong backbone for the decision-making process, ideally consisting of experienced communicators who ensure governance participants can’t be easily tricked or manipulated.
The Proposed Ecosystem Council Model
Overview
In this post, we seek to propose a potential future decentralized, community-controlled Ecosystem Council security model, capable of addressing the need for contract upgradeability in existing and upcoming Polygon protocols by use of decentralized and permissionless governance. The goal would be to introduce community checks for contract upgradeability, all the while retaining necessary security guarantees for Polygon protocols to flourish. We want to improve on the status quo by drawing the best from both worlds of decentralized community control and efficient council governance. The following proposal reflects the initial thinking around the subject by the Polygon Labs’ team.
Generalized Mechanism
In short, we envision an Ecosystem Council consisting of highly-reputable, technically-efficient, and value-aligned individuals, electable and removable by the community, and capable of performing timelock-limited upgrades to upgradeable system smart contracts across Polygon networks, e.g., Polygon PoS and zkEVM. While still being explored, the Ecosystem Council elections could be triggered by the community either when particular conditions are met (e.g., upgrade initiation) or at all times.
We’re concurrently proposing direct checks on the Ecosystem Council-proposed upgrades coming from the community. These might, for example, include the ability to veto any upgrade added to the bridge upgrade timelock as it relates to Polygon PoS.
Community participation, in the form of voting, might happen via use of the $MATIC token in order to provide a solid economic incentive for one of the most important pieces of Polygon architecture.
It’s important to note that community checks on the Ecosystem Council’s actions, with the likely exception of global governance parameters, will need to be adjusted for each Polygon protocol separately. For example, Polygon zkEVM’s architecture may dictate considerably different flows of system smart contract upgrades than the Polygon PoS chain.
In our considerations, we tend towards an optimistic governance model, which passes agency in active management to the contracts to the Ecosystem Council, while retaining ultimate checks on Emergency Council’s powers with the wider community, as expressed by vetoes and elections. This type of governance can minimize requirements for active governance, voter fatigue and apathy, as well as potential attack vectors connected to, for example, regularly held elections.
The Ecosystem Council for Polygon PoS chain
Current System Smart Contracts Governance
In order to visualize the proposed setup further, we use Polygon PoS as an example of a mature solution where the Ecosystem Council governance may be a suitable candidate for introduction.
The upgrades to Polygon PoS components implemented as smart contracts currently happen via the use of contract Polygon Improvement Proposals (PIPs). In contrast to core PIPs, contract PIPs can not be implemented via on-chain consensus, i.e. client software updates. Instead, they have to be upgraded by a party designated as the “admin” in these contracts. The PIP framework provides a social coordination layer for signaling for the admin to execute on.
On the technical level, various important parameters for the general infrastructure of Polygon PoS, such as the staking contracts on Ethereum, and the bridges between Polygon PoS and Ethereum are restricted such that they can only be called by a timelock contract.
In order to affect such a change, a proposal must be made to the multisig wallet, on which the admin, a community-owned multisig, then votes. Assuming a quorum of signers approves the proposal, the proposal is then queued in the timelock. The current wait time is 48 hours, and lowering this number is itself a timelock-restricted parameter, meaning that a proposal to lower the timelock’s minimum threshold would also need to wait for 48 hours prior to execution.
Once the required time has passed, the multisig creates a proposal to execute the change in the timelock. Assuming quorum is reached, the timelock is called, and the queued calls are executed.
General Community Competencies on Polygon PoS
In order to introduce community checks on the Ecosystem Council’s ability to propose and execute upgrades using the previously mentioned admin multi-sig, the community would be empowered by three main competencies via a vote, proposed and executed on-chain:
- Election and removal of Ecosystem Council members;
- Exiting Emergency State; and
- Vetoing any upgrade proposed and scheduled in the timelock by the Ecosystem Council.
Specification
As mentioned before, the current Polygon PoS setup has a multisig at the base of all upgrades to the network, securing upgrade transactions with a timelock.
As of the time of writing, the timelock applies uniformly to all transactions that the multisig wishes to execute on Polygon PoS’s contracts. Similarly, the timelock is the only restriction placed on a proposal by the multisig.
We propose altering both of these characteristics. To do this, the Ecosystem Council’s actions would conceptually be split into two categories: vulnerability and routine (non-vulnerability) proposals. The difference between the two is if the proposal seeks to protect funds potentially at risk.
In the case of routine proposals, the Ecosystem Council will make a proposal and proceed with the timelock as before. There is the possibility of increasing the timelock minimum to 10 days over 48 hours (the current minimum), as these proposals should be non-urgent by nature, and this would allow the community more time to review them, making sure they are what they claim to be. Were a malicious proposal to be initiated, the community would have the ability to:
- exit the chain with their funds via bridging;
- initiate a vote to reject the Ecosystem Council’s proposal;
- initiate a vote to replace Ecosystem Council’s members.
For sensitive proposals, i.e., user funds being at risk, resulting from potential exploits in the StakeManager or bridge predicate contracts for example, the Ecosystem Council would first enact an Emergency State, i.e., freeze on Polygon PoS’s bridge. In cases where there is a vulnerability in a bridge, this would effectively freeze funds in the bridge so that they cannot be exploited. In cases where the vulnerability is not in the bridge contracts, this still restricts the movement of funds, which would be a net positive.
Once the Emergency State is enacted and the bridge is frozen, the Ecosystem Council would have the ability to initiate time locked (shorter than routine proposals) upgrades, as well as bypass the timelock entirely if the transaction is signed by a supermajority of Ecosystem Council members, e.g., 10/12 consensus, instead of regular 7/12. The Ecosystem Council’s ability to bypass the timelock is important in rare cases when a critical bug doesn’t directly relate to bridge activity and could be exploited regardless of a bridge freeze. Similar models for varying quorum requirements have previously been used, exemplified by ZkSync’s Security Council. A gradual decrease in Ecosystem Council’s competencies as they refer to overriding the timelock should also be further explored.
In the case of timelock upgrades preceded by an Emergency State, the community would have the ability to:
- Veto the Emergency State, unfreezing the bridge and rejecting the upgrade transaction (with the exception of transactions overriding the timelock by use of supermajority);
- Veto the upgrade but keep the Emergency State (bridge freeze), e.g., in case the upgrade is the wrong fix to the issue;
- Modify particular members of the Ecosystem Council via the removal of existing signatories and proposing new ones.
The exact parameters of the governance module facilitating such votes should be discussed further and are considered one of the more important open questions.
Open Questions
It’s important to note that the potential rollout of such an Ecosystem Council model would need to be carefully planned and gradually implemented. It’s by all means a daunting task for a live blockchain to implement such a complex governance system.
As with our previous posts in the Three Pillars series, we want to invite community participation in providing feedback to the model laid out here from the beginning, as well as ask the ecosystem for assistance in answering some of the open questions, as well as identifying those we might have missed.
Community Building
For a healthy governance framework, wide community participation is crucial, especially as it concerns defining moments, e.g., Ecosystem Council elections or critical bug fixes.
- Are there viable, proven ways to incentivize participation in similar models?
- What are some of the initiatives that the ecosystem could be undertaking today to grow the community of security-aware participants?
Governance Module
As mentioned before, the particular decision-making system employed in this model is of great importance. Some of the areas we’ve been focusing on are the general design principles, voting power proxy, and architecture.
General Design Principles
- The module should tend to minimize regular active participation, but maximize community responsiveness when it really counts - how can this be achieved?
- The module requires the right quorum parameter - have there been succesful experiments with variable quorum mechanisms used for token voting?
- The module will likely require some form of delegation - have there been experiments to create healthy delegation for optimistic governance?
Architecture
- The module should live fully on-chain, requiring no off-chain dependencies in order to reduce risks
- This requirement limits our considerations around the voting power proxy. For example, any viable sybil resistant quadratic voting mechanism will need to depend on off-chain data, fed into the system by an intermediary.
Voting Power Proxy
- The voting power proxy should provide wide ecosystem inclusion and resulting legitimization of the Ecosystem Council
- The $MATIC token could be considered as proxy for voting power:
- It provides the widest set of security guarantees at the economic layer;
- The token is well-distributed among ecosystem participants;
- However, simplistic 1 token = 1 vote model risks leading to concentration of power
- Are there other mechanisms that could be considered here?
We want to thank everyone for taking the time to read and engage with this proposal, as well as all of the previous ones (The Three Pillars of Polygon Governance & First Pillar: Protocol Governance). Please feel free to leave your thoughts below or in a standalone discussion thread.
