[ZIP-5] Upgrade Governance Contracts

[ZIP-5] Upgrade Governance Contracts

Summary

This proposal suggests parameter changes to the Protocol Governor, redeploys all governance contracts, including 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.

In addition to these changes, the redeployment of the Token Governor and GovOps Governor ensures that all facets of the governance framework remain consistent and secure. Specifically, these governors have been redeployed with their original parameters intact, with the only change being an update of the Veto Guardian to the new Guardians contract address.

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:

1. Reduction of _votingDelay: Decreasing the vote delay from 7 days to 3 days to enable faster onset of the voting period.
2. Reduction of _lateQuorumVoteExtension: Shortening from 7 days to 2 days to expedite the closure of voting procedures.
3. Redeploy of the ProtocolUpgradeHandler to 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:

• 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.
• 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: Modifies _votingDelay from 7 days to 3 days to accelerate the initiation of the voting period following proposal submission.
• Reduce _lateQuorumVoteExtension: Modifies _lateQuorumVoteExtension from 7 days to 2 days, streamlining the voting process by shortening the extension period for achieving quorum.

Protocol Upgrade Enhancement

• Update to ProtocolUpgradeHandler:

  • Deployment of a New Contract: A new upgradeable version of the ProtocolUpgradeHandler will be deployed to replace the existing non-upgradeable version.
  • Upgradeability Feature: Ensures future modifications to this contract can be made efficiently and securely.
  • Proxy Ownership: The proxy admin of the new ProtocolUpgradeHandler will be an OpenZeppelin ProxyAdmin contract, with the owner set to the ProtocolUpgradeHandler itself.
  • Transfer of Ownership: All L1 contracts’ ownerships will be transferred to the new upgradeable ProtocolUpgradeHandler. The DEFAULT_ADMIN_ROLE of the ZK token will also be granted to the new ProtocolUpgradeHandler.

• Update the ZkProtocolGovernorTimelock on L2:

  • A new ZkProtocolGovernorTimelock contract will be used by the ZkProtocolGovernor, ensuring old upgrades cannot be re-executed with the new ProtocolUpgradeHandler.

Additional Context

⚠️ This proposal does not include the transfer of ownerships of L2SharedBridge, UpgradeableBeacon, L2WrappedBaseToken, and similar L2 contracts that the ProtocolUpgradeHandler is the admin of. These contracts are deployed once per chain rather than ecosystem-wide. Future governance upgrades will aim to remove any mandatory upgrades requiring O(number_of_chains) L1→L2 transactions.

The old ProtocolUpgradeHandler will remain the owner of these contracts and continue accepting transactions from the old timelock, ensuring governance continuity.

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 optimize 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 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 resulting from changing governance parameters to accelerate the ZIP governance process are mitigated by Guardians being able to veto a ZIP during the Veto Period. Further, all ZIPs continue to require Security Council approval to progress to execution.

Since the ProtocolUpgradeHandler is now a proxy, some changes were required to its implementation:
🔗 GitHub PR #21

These changes do not alter the contract's behavior but facilitate the transition to a proxy implementation.