[Draft] Protocol Governor Upgrade

Protocol Development Draft 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 2 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 2 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 2 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.

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.

4 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.

3 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.

1 Like
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