The voting period for ZIP-5 is live. Delegates can vote on Tally.
1 Like
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!
1 Like
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.
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.
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:
- 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.
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.
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.
Yes, they were merged here.
Will this proposal remove those roles from the current timelock and assign them to the new timelock instead?
Yes, it will.
Does this mean we need to re-accept the agreement under the new governor and timelock?
No, we do not need to reaccept it.
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.
Unfortunately, the way our timelocks were deployed, the TIMELOCK_ADMIN_ROLE was revoked and our governors do not have any control over it, so the new EXECUTOR_ROLE can not be granted. So the only way to change a governor was to change the timelock as well.
Thank you for the replies and clarifications! Two things I want to clarify:
Yes, they were merged here.
I may be missing something, but this pr seems to only have the protocol handler changes, and redeployment scripts, not the new governor and timelock redeployment scripts or implementation changes. I did find this WIP pr which has the new timelock deployment for the protocol governor, but didn’t find a script for GovOps or the Token Governor
Unfortunately, the way our timelocks were deployed, the
TIMELOCK_ADMIN_ROLEwas revoked and our governors do not have any control over it, so the newEXECUTOR_ROLEcan not be granted. So the only way to change a governor was to change the timelock as well.
I don’t think this is true. Both the GovOps timelock and the Token governor timelock have the TIMELOCK_ADMIN_ROLE. Since the timelocks have the role, a governance proposal for each governor could grant the EXECUTOR_ROLE. PROPOSER_ROLE, and CANCELLER_ROLE to a new governor via a governance proposal on the old governors.
I am sorry for the delayed reply.
didn’t find a script for GovOps or the Token Governor
True, the Governance contracts have not changed their code, so we reused the existing scripts (while only temporarily changing the hardcoded constants).
I don’t think this is true.
Agree. Now I see that not changing timelock for GovOps / TokenGovernor would’ve been a cleaner approach. In any case, the GovOps timelock did not have any permissions, while all the TokenGovernor’s ones were moved to the new timelock. So the ZIP5 is safe. I do agree with your points and we will try to avoid doing it in the future.
1 Like
Thank you for clarifying!
After ZIP5 is executed on L1, an emergency upgrade will have to be performed by the new ProtocolUpgradeHandler to do acceptOwnership() of the new contracts.
The upgrade will contain 5 calls to the following contracts:
- 0x303a465B659cBB0ab36eE643eA362c509EEb5213 (Bridgehub)
- 0xc2eE6b6af7d616f6e27ce7F4A451Aedc2b0F5f5C (State Transition Manager)
- 0xD7f9f54194C633F36CCD5F3da84ad4a1c38cB2cB (L1SharedBridge)
- 0x5D8ba173Dc6C3c90C8f7C04C9288BeF5FDbAd06E (ValidatorTimelock)
- 0xf553E6D903AA43420ED7e3bc2313bE9286A8F987 (A bridge that allows ZK chains to bridge tokens that may migrate to minting of canonical USDC in the future)
Each call just encodes the call to acceptOwnership() function.
1 Like