FeedProjects
Developers
Settings
🎉 A new chapter begins: Boardroom has joined Agora
Learn more
protocol logo
Explore / Projects
ZKSync

Insights

Proposals

Discussions

Members

Information

Reports

Create Proposal

ZKSync

InsightsProposalsDiscussionsMembersInformationReports
Proposal
Back to Proposals
executedEnds a year ago ·  Protocol Governor

Upgrade Governance Contracts

By 0xc118...ffaD2C

[ZIP-5] Upgrade Governance Contracts

Title[ZIP-5] Upgrade Governance Contracts
Proposal TypeZIP
One Sentence SummaryThis 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.
Proposal AuthorMatter Labs, point of contact is @Stanislav Bezkorovainyi
Proposal SponsorCyfrin
Date Created11-February-2025
Versionv1
Summary of ActionParameter 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. Additionally, GovOps and Token Governors have been redeployed to update the veto guardian address to point to the new Guardians contracts.
Link to ContractsGitHub PR #21

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

Continue Reading
Connect Wallet to Add Note
0
Never Miss a ProposalSign up for ZKSync notifications
Cast Vote
Votes 3655
VoterCast PowerVote & Rationale
0x2E21...15f21A
98.459M

FOR

0x0000...A359De
86.51M

FOR

0x1B68...88eeaD
85.235M

FOR

0x9e0D...Bf986e
61.945M

FOR

0x3FB1...2d4C8A
57.131M

FOR

SHOW MORE
VOTE POWER
0
Connect Wallet
Proposal Status
  • Tue February 11 2025, 07:14 pmPublished Onchain 0xc118...ffaD2C
  • Tue February 18 2025, 07:14 pmVoting Period Starts
  • Thu February 27 2025, 03:28 pmEnd Voting Period
  • Thu February 27 2025, 03:53 pmQueue Proposal
  • Thu February 27 2025, 04:25 pmExecute Proposal
Current Results

1-FOR

956.317M

99.89%

2-ABSTAIN

960,140.75

0.1%

3-AGAINST

76,444.445

0.01%
Quorum 957.353M/630M
DocumentationBrandingContact Us
Press space bar to start a drag. When dragging you can use the arrow keys to move the item around and escape to cancel. Some screen readers may require you to be in focus mode or to use your pass through key