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.
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.
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
This proposal is now onchain. Voting starts in 7 days.
Link — Tally | ZKsync | Upgrade Governance Contracts
Hi, it wasn’t clear to me who or what ‘owns’ ProtocolUpgradeHandler?
Is all upgradability under control of the Token Assembly?
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.
On behalf of Dedaub, the upgrade proposal seems fine
after reviewed the proposal, we have no concern about this upgrade
thank you for the reply!
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.
I will vote for this proposal because it makes the governance process faster and more efficient by reducing voting delays.
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
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.
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.
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.
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?
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.
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
ProtocolUpgradeHandlerthan simply updating the timelock. One idea would be to ensure that_l2TxNumberInBatchinstartUpgradeis always greater than any previously executed upgrades.
This option was considered. The reasons why we decided not go with it:
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.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.
The new ZkGovOpsGovernor is 0xEEEa739a8b6fB1b8f703E23C9Be03CeeA643b160.
Its timelock is 0xC9E442574958f96C026DeF9a50C3236cab17428a.
The new ZkTokenGovernor is 0xb83FF6501214ddF40C91C9565d095400f3F45746
and its timelock is 0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d
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.
Oh, so we’re not just deploying new governors; we’re also deploying new timelocks that differ from the existing ones. I don’t believe that was mentioned in the proposal. If the new governor implementations aren’t already in the zk-governance repository, it would be helpful to open a pull request for them—or, if they’re already there, to link them in the proposal.
Deploying new timelocks could introduce some unexpected scenarios. One example that might be addressed by this proposal is the role of the current Token Governor timelock as a minter and burner admin on the ZK token. Will this proposal remove those roles from the current timelock and assign them to the new timelock instead?
Another consideration is that, under the GovOpsGovernor, we accepted the SEAL Safe Harbor agreement using the old timelock. Does this mean we need to re-accept the agreement under the new governor and timelock?
There may be additional scenarios like these, which is why it might have been better to simply grant and then renounce permissions to the new governor using the existing timelock.