[ZIP-5] Upgrade Governance Contracts

Protocol Development Active ZIPs
1
Title Protocol Governor Upgrade
Proposal Type ZIP
One Sentence Summary: This proposal suggests parameter changes to the Protocol Governor and redeploys contracts related to the protocol upgrade mechanism for ZKsync, namely the ProtocolUpgradeHandler.
Proposal Author Matter Labs, point of contact is @Stanislav Bezkorovainyi
Proposal Sponsor: TBC
Date Created: TBC
Version v1
Summary of Action Parameter changes to the Protocol Governor, specifically reducing _initialVotingDelay from 7 days to 3 days and reducing _lateQuorumVoteExtension from 7 days to 2 days, along with deploying an upgradable version of the ProtocolUpgradeHandler and a new version of the ZkProtocolGovernorTimelock.
Link to contracts More flexible governance upgrade by StanislavBreadless ¡ Pull Request #21 ¡ zksync-association/zk-governance ¡ GitHub

Summary

This proposal suggests parameter changes to the Protocol Governor and redeploys contracts related to the protocol upgrade mechanism for ZKsync, namely the ProtocolUpgradeHandler.

The Protocol Governor parameter changes in this proposal are designed to enhance the governance process by reducing the ZIP voting delay from 7 days to 3 days and reducing the quorum extension from 7 days to 3 days.

The ProtocolUpgradeHandler contract is responsible for executing protocol upgrades on Ethereum that have been approved by the Token Assembly. The current ProtocolUpgradeHandler contract is not upgradeable. This proposal includes the redeployment of the ProtocolUpgradeHandler contract to an upgradable version. This change ensures the Protocol Governor can execute upcoming ZKsync developments.

As part of the streamlined upgrade process, the existing ProtocolUpgradeHandler will continue to own the L2 chain-specific addresses (such as L2SharedBridge, etc.). The rationale behind this decision is detailed in the “Specification” section.

Abstract

The ZKsync Protocol Governor is responsible for executing ZKsync Improvement Proposals (“ZIPs”) that upgrade the ZKsync protocol and/or components of the ZKsync governance system. This proposal introduces three major amendments aimed at refining the efficiency and security of these processes:

  • Reduction of _votingDelay: Decreasing the vote delay from 7 days to 3 days to enable faster onset of the voting period.
  • Reduction of _lateQuorumVoteExtension: Shortening from 7 days to 3 days to expedite the closure of voting procedures.
  • Redeploy of the ProtocolUpgradeHandler to a be an upgradable version: This version will allow for the modification of the implementation. This is needed in case of breaking changes to the interfaces of the functions of ecosystem contracts (e.g. Bridgehub, StateTransitionManager, etc), as well as to include new contracts that fall under the scope of ZKsync contracts which can be frozen by an Emergency Upgrade. The above will happen during the v26 upgrade.

Motivation

The dual objective of this proposal is to streamline governance activities and improve the contracts governing protocol upgrades. Specifically:

  1. Governance Streamlining: By reducing the _votingDelay and _lateQuorumVoteExtension, the ZIP governance process can react more swiftly to evolving needs of the ZKsync protocol, improving operational efficiency of protocol upgrades.
  2. Improve Protocol Upgrades: Updating the ProtocolUpgradeHandler ensures that the Protocol Governor can effectively manage and secure new contracts introduced in future ZKsync upgrades by adding scope to the list of contracts the ProtocolUpgradeHandler controls. This change is vital for maintaining system integrity and alignment with the evolving architectural framework of ZKsync.

Specification

Governance Parameter Adjustments:

  • Reduce _votingDelay: The parameter adjustment modifies the _votingDelay from a duration of 7 days to 3 days. This reduction is implemented to accelerate the initiation of the voting period following proposal submission, reducing the total time taken from a ZIP to progress through the governance process by 4 days.
  • Reduce _lateQuorumVoteExtension: The _lateQuorumVoteExtension is modified from its current setting of 7 days down to 3 days. This change aims to streamline the voting process by shortening the extension period granted for achieving quorum, thereby expediting the conclusion and execution governance decisions on ZKsync Era.

Protocol Upgrade Enhancement:

  • Update to ProtocolUpgradeHandler: It is necessary to improve the ProtocolUpgradeHandler to better facilitate governance operations on L1 that reflect changes on L2. Currently, the ProtocolUpgradeHandler is a non-upgradeable contract acting as the owner of all contracts, and representing L2 governance on L1. To streamline future governance adjustments and ensure flexibility, this proposal includes:
    • Deployment of a New Contract: A new upgradeable version of the ProtocolUpgradeHandler will be deployed to replace the existing non-upgradeable version.
      • Upgradeability Feature: By making the ProtocolUpgradeHandler upgradeable, future modifications to this contract can be made more efficiently and with reduced complexity, enhancing governance flexibility and security.
      • Proxy Ownership: The proxy admin of the new ProtocolUpgradeHandler will be an OpenZeppelin’s ProxyAdmin contract with the owner being equal to the ProtocolUpgradeHandler itself.
    • Transfer of Ownership: All L1 contracts’ ownerships will be transferred to the new, upgradeable ProtocolUpgradeHandler. Also, the DEFAULT_ADMIN_ROLE of the ZK token will be also granted to the new ProtocolUpgradeHandler.
    • Update the ZkProtocolGovernorTimelock on L2: To ensure that old upgrades can not be re-executed with the new ProtocolUpgradeHandler, a new ZkProtocolGovernorTimelock contract will be used by the ZkProtocolGovernor. The parameters of the new ZkProtocolGovernorTimelock are the same as those of the previous contract. The reason for a new contract address is to prevent re-execution.
  • Additional Context
    • :warning: This proposal does not include the transfer of ownerships of L2SharedBridge, UpgradeableBeacon, L2WrappedBaseToken and similar L2 contracts that the ProtocolUpgradeHandler is the admin of. The reasoning for that is the following:
      • These contracts are deployed once per chain (and not once per ecosystem). Updating these contracts one-by-one in each chain would involve sending L1→L2 transactions to each of these. This requires obtaining the native token of the recipient chain. Additionally, there is the potential to make the upgrade process vulnerable to malicious chains that may censor such upgrade transactions. ZKsync governance can still circumvent such issues via an Emergency Upgrade, but this approach is not sustainable in the long run.
      • With the future v26 upgrade, we plan to remove any mandatory upgrades that require O(number_of_chains) L1→L2 transactions and so the ownership of the contracts does not matter as long as it is only ZKsync governance that can upgrade them.
      • The old ProtocolUpgradeHandler will remain the owner of those and will still accept transactions that come from the old timelock (and so approved by the ZKsync governance) only. In case governance needs to conduct an upgrade via the old timelock, it can still do so.
      • Leaving an old ProtocolUpgradeHandler is bad practice in the long run. In one of the future upgrades, all ZK chains will have the ownership of the L2SharedBridge, UpgradeableBeacon as well as the L2WETH’s ownership reset to a non existing address, e.g. BOOTLOADER_ADDR to ensure that their upgrade is possible only via the same upgrade process as used for the protocol upgrades, i.e. either via publishing a new protocol version or using the executeUpgrade function in extreme situations.
      • The decision above significantly simplifies the upgrade process.

These changes to the ProtocolUpgradeHandler are critical to adapting the governance structure to better manage the new dynamics introduced with the v26 Gateway Preparation upgrade (to be published soon). This will allow for more seamless and effective governance operations, maintaining the integrity and security of the system as the ZKsync protocol continues to evolve.

The addresses of the new governors

The new ZkGovOpsGovernor is 0xEEEa739a8b6fB1b8f703E23C9Be03CeeA643b160.
Its timelock is 0xC9E442574958f96C026DeF9a50C3236cab17428a.

The new ZkTokenGovernor is 0xb83FF6501214ddF40C91C9565d095400f3F45746.
Its timelock is 0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d.

Rationale

The governance parameter adjustments allow for quicker adaptation to community decisions and needs, while the upgrade to the ProtocolUpgradeHandler ensures the system’s resilience and readiness to manage new contracts securely. These amendments are strategically designed to optimize the responsiveness and efficiency of the governance process, while aligning the Protocol Governor’s capabilities with the latest technological advancements within the ZKsync ecosystem.

Backwards Compatibility

The proposed adjustments will not adversely affect existing operations but will streamline existing governance processes and enhance security protocols. They are designed to be backwards compatible, integrating seamlessly with the current operational protocols of ZKsync Era.

Security Considerations

Any perceived security risks that result from changing Protocol Governor governance parameters to increase the speed of the ZIP governance process is balanced by Guardians being able to exercise their power to veto a ZIP during the Veto Period. Further, all ZIPs continue to require Security Council approval in order to progress to execution.

Since the ProtocolUpgradeHandler is now a proxy, some changes were required to its implementation:

These do not change the behavior of the contract, but they are needed to facilitate the transition to a proxy implementation.

7 Likes
2

Hey, I am Stas, Senior Protocol Engineer at Matter Labs and I am happy to post my first ever ZIP!

We expect the upgrade to go live on the testnet today, and the proposal to be pushed on mainnet somewhere next week. On testnet, we will strive to conduct the upgrade in the same fashion as on mainnet. Thus, the parameters will be reduced by 1 minute there to simulate the parameter change.

6 Likes
3

One note is that the Token Assembly should avoid other proposals to the old Protocol Governor during the upgrade. If the upgrade proposal passes, in-flight Protocol Governor proposals will be pointed to the old, now defunct governor.

2 Likes
4

We will not redeploy the ZkProtocolGovernor contract, we’ll only redeploy its timelock, which will mean that the voting can still proceed as usual with ZkProtocolGovernor.

However, indeed some caution is warranted in case an upgrade relies on the old ProtocolUpgradeHandler’s address

1 Like
5

This proposal is now onchain. Voting starts in 7 days.
Link — Tally | ZKsync | Upgrade Governance Contracts

6

Hi, it wasn’t clear to me who or what ‘owns’ ProtocolUpgradeHandler?

Is all upgradability under control of the Token Assembly?

7

Only two entities can start a transaction out of the name of the ProtocolUpgradeHandler:

The processes above do not change with the course of the upgrade.

2 Likes
8

The voting period for ZIP-5 is live. Delegates can vote on Tally.

1 Like
9

On behalf of Dedaub, the upgrade proposal seems fine

10

after reviewed the proposal, we have no concern about this upgrade

11

thank you for the reply!

1 Like
12

As a small note, we updated the forum to include the fact that the late quorum vote extension will be reduced to 3 days and not 2 days.

The tally calldata already adheres to that.

13

I will vote for this proposal because it makes the governance process faster and more efficient by reducing voting delays.

14

After review of ZIP-5, the Treasure Delegate Council will be voting FOR this proposal.

Balancing efficiency and speed with security seems top of mind for Matter Labs, and we agree with this approach.

-Flook

15

The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas. It’s based on their combined research, fact-checking, and ideation.

We’re voting FOR the proposal.

Given the technical nature of the proposal, we requested that our research team at L2BEAT review the proposed upgrades and the associated executable so we could make an informed decision.

After our research team reviewed the contents of the proposal, they notified us that they found nothing concerning that should compel us to vote against it. According to their research, the proposed delay changes only affect voting times on L2, and the new ProtocolUpgradeHandler can only be upgraded by itself, which fits into zkSync’s governance model.

16

As a follow up: since most of our L1 contracts are Ownable2Step, the actions that are done in ZIP5 will only do the first step of transferring the ownership. The new ProtocolUpgradeHandler is expected to accept the ownership via an emergency upgrade. This is used as an opportunity to test the governance process of the emergency upgrades. The Security Council is aware of this requirement and has agreed to initiate the emergency upgrade when required.

17

ZKsync Security Council — Proposal Verification

The ZKsync Security Council has completed an initial review of ZIP-5 and shared the outcomes of the review in this forum post.

The ZKsync Security Council is comfortable that the proposal call data has been verified and any issues discovered have been acknowledged and addressed where appropriate.

18

The proposal on Tally mentions that “GovOps and Token Governors have been redeployed to update the veto guardian address to point to the new Guardians contracts.” However, the addresses of these new governors are not provided.

Furthermore, even if these governors have been deployed, they do not have permission to create, execute or cancel proposals on the existing timelocks. Is this intentional? And does that mean the old veto guardian can still veto proposals on these timelocks?

19

I’m not entirely familiar with the upgrade process, so please correct me if I’m wrong. However, it seems there may be better ways to prevent previous upgrades from being replayed on the new ProtocolUpgradeHandler than simply updating the timelock. One idea would be to ensure that _l2TxNumberInBatch in startUpgrade is always greater than any previously executed upgrades.

Changing the timelock can introduce issues: it may break existing tools that depend on the current contract, and because the timelock is the governor’s account, there could be non-obvious dependencies. In this case, it is acceptable, but generally speaking, modifying the timelock should be a last resort.

20

Hey @keating,

However, the addresses of these new governors are not provided.

Makes sense, I will append those to the post.

The new ZkGovOpsGovernor is 0xEEEa739a8b6fB1b8f703E23C9Be03CeeA643b160.
Its timelock is 0xC9E442574958f96C026DeF9a50C3236cab17428a.

The new ZkTokenGovernor is 0xb83FF6501214ddF40C91C9565d095400f3F45746
and its timelock is 0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d

Furthermore, even if these governors have been deployed, they do not have permission to create, execute or cancel proposals on the existing timelocks. Is this intentional? And does that mean the old veto guardian can still veto proposals on these timelocks?

All permissions of the old timelocks are migrated to the new ones. So yes, the old governors can interact with old timelocks, but those won’t have any power after ZIP5 as it will be transferred to the new timelocks corresponding to the new governors.

However, it seems there may be better ways to prevent previous upgrades from being replayed on the new ProtocolUpgradeHandler than simply updating the timelock. One idea would be to ensure that _l2TxNumberInBatch in startUpgrade is always greater than any previously executed upgrades.

This option was considered. The reasons why we decided not go with it:

  • The process would be less straightforward from the upgrade perspective (i.e. when the upgrade is executed (i.e. ProtocolUpgradeHandler.execute) it does not know tx number in batch or the batch number when it was submitted on L2, there are ways to make it know but they would be more convoluted and indirect). We wanted to keep the upgrade simple.
  • Having a new timelock also prevents reusing the same upgrades inside the old protocol upgrade handler. We have not yet transferred the ownership for some of the L2 bridges as explained in the description and so having these two governors as two separate entities is easier to reason about.

Changing the timelock can introduce issues: it may break existing tools that depend on the current contract, and because the timelock is the governor’s account, there could be non-obvious dependencies. In this case, it is acceptable, but generally speaking, modifying the timelock should be a last resort.

Makes sense. Hopefully, we will never need it again after this upgrade.