[ZIP-002] Reduce the execution delay from 21 hours to 3 hours

:ballot_box: This proposal passed with a majority of 1.11B ZK in-favor of the proposal. See final results here.

ZKSync Improvement Proposal Summary

Title Reduce the execution delay on ZK Chains from 21 hours to 3 hours
Proposal Type ZIP
One Sentence Summary This ZIP proposes reducing the execution delay on ZK Chains from 21 hours to 3 hours.
Proposal Author Matter Labs, point of contact is Samuel Kaufman [ @sampka ]
Date Created 2024-11-06
Version 1.0
Summary of Action Decrease the execution delay to enhance user experience and operational efficiency, leveraging the recently established Security Council for rapid response in emergency situations.

ZIP — Reduce the execution delay from 21 hours to 3 hours

Simple Summary

This ZIP proposes to reduce the execution delay on ZK Chains from the current 21 hours to 3 hours, enhancing transaction finality while maintaining security through the oversight of the newly established Security Council.

Abstract

The proposal aims to shorten the execution delay in the ZKsync Era and ZK Chains network to improve user experience and operational efficiency. With the establishment of the Security Council, we can confidently reduce the delay to 3 hours, providing sufficient time for emergency interventions without compromising the network’s security.

Motivation

  • Enhancing User Experience: A shorter execution delay means faster transaction confirmations, which improves the overall user experience.
  • Operational Efficiency: Reducing the delay streamlines operations for developers and businesses relying on ZKsync Era and ZK Chains
  • Security Assurance: The newly formed Security Council can promptly address any security issues within the reduced timeframe.

Historically, the 21-hour delay was a precautionary measure to allow time for manual intervention in case of critical issues. However, this long delay can hinder the network’s usability and responsiveness. Now that the Security Council is in place with the authority to freeze the chain in emergencies, we can safely reduce the delay to 3 hours.

Specification

The technical changes involve updating the network’s parameters to adjust the execution delay from 21 hours to 3 hours. Specifically:

  1. Parameter Update: Modify the delay parameter in the network’s smart contracts and configuration files to reflect the new 3-hour delay.
  2. Security Protocols: Ensure that the Security Council’s monitoring systems are fully operational to detect and respond to issues within the reduced timeframe.
  3. Testing: Perform extensive testing on testnets to validate the change and monitor for any unforeseen impacts.

These changes require coordinated updates across all nodes and stakeholders to ensure a smooth transition.

{
        "index": 8,
        "network": "mainnet",
        "from": "0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897",
        "to": "0x5D8ba173Dc6C3c90C8f7C04C9288BeF5FDbAd06E",
        "functionName": "setExecutionDelay",
        "functionSignature": "setExecutionDelay(uint32)",
        "arguments": {
            "_executionDelay": {
                "type": "uint32",
                "value": "10800"
            }
        },
        "description": "Validator Timelock - Decrease Execution Delay"
    },

Rationale

Reducing the execution delay enhances the network’s efficiency without sacrificing security because:

  • Security Council’s Role: The Security Council can act within the 3-hour window to freeze the chain if a critical issue arises.
  • Adequate Response Time: Three hours is sufficient for the Security Council to investigate issues and coordinate a response without rushing decisions.
  • Improved Competitiveness: A shorter delay aligns ZKsync Chains with industry standards, making it more attractive to users and developers.

Alternative options, such as incremental reductions or maintaining the status quo, were considered. However, a direct reduction to 3 hours offers immediate benefits and is feasible given the current security infrastructure.

Execution Impact

  • User Transactions: Users will experience faster transaction finality, improving satisfaction and engagement.
  • Developers and Businesses: Quicker execution times enable more responsive applications and services.
  • Network Performance: Overall network throughput and efficiency are expected to improve.

No negative impacts are anticipated, but continuous monitoring will be in place to address any issues promptly.

Backwards Compatibility

This change is backward-compatible as it does not alter existing smart contract interfaces or require modifications from users or developers. All existing transactions and contracts will continue to function correctly under the new execution delay.

Security Considerations

  • Emergency Response: The Security Council has protocols to quickly freeze the chain within the 3-hour window if necessary.
  • Monitoring Systems: Enhanced monitoring will be implemented to detect anomalies in real-time.
  • Risk Assessment: A thorough risk assessment has been conducted, and no significant security risks have been identified with the reduced delay.

The Security Council’s ability to act swiftly mitigates potential risks associated with the shorter delay.

7 Likes

Hello everyone,

I’m Sam Kaufman, a Staff Security Engineer at Matterlabs. We’ve always been committed to reducing execution delays in Zksync. Now that our governance is in place—specifically with the Security Council now operational—we’re excited to confidently implement these reductions.

If you have any questions or concerns, please feel free to share them here on this forum. I’d be happy to address them.

2 Likes

Hi @Sampka, this sounds really good. We did have people complain about long finalization times when bridging out or using exchanges (which don’t happen that often tbh) so it has been really interesting reading your proposal!

If you don’t mind, I have a few questions below:

  1. I assume this will also reduce the withdrawal delay for people bridging out to the L1, is that correct or is it unrelated?
  2. When you say “The Security Council has protocols to quickly freeze the chain within the 3-hour window if necessary”, is there a place where these are documented?
  3. " * Monitoring Systems: Enhanced monitoring will be implemented to detect anomalies in real-time." → I think this could be really interesting if opened to the public to let the community digest the metrics and showcase it
  1. Yes this should shorten the withdrawal delay for people bridging to l1. I cant say exactly how much as there are still other factors that effect the withdrawal delay.
  2. Here are a few links to both the members and some of the powers of the security council:
    ZKsync Security Council: Safeguarding Technical Integrity
    Schedule 3: ZKsync Security Council | ZK Nation
  3. We at Matter Labs do plan to eventually share this information with the larger community. For now, however, it is primarily being discussed among security council members so we can determine best practices and assess what is safe to disclose without highlighting potential blind spots to malicious attackers.
1 Like

Is there a specific reason to make it 3h? Can’t think of any downsides and this is highly required. Only thing that I have in mind is, assuming it should require a basic param change in sequencer, why do node operators need a change and if so, how would different providers (eg. Alchemy) will be synced to new params? Is it time sensitive?

The reason we chose a 3-hour delay is twofold:

  1. Security Considerations: This timeframe gives the security council enough time to investigate any potential issues and determine whether the chain needs to be frozen to address them. By having this window, we can avoid unnecessary and disruptive freezes, ensuring smoother operations.
  2. Current Proving Time: Our current proving time is approximately 2–3 hours. Reducing the delay below this threshold wouldn’t actually decrease the finalization time at this point, since the proving process itself is the bottleneck. We are actively working on improving the proving time, and once it decreases, we can reevaluate and potentially adjust the delay accordingly.
1 Like

That’s great news! Hopefully the time will be reduced even more soon.

I sent ZK to Binance today. When I want to withdraw again, it says I have to wait 24 hours. We need to fix this

I like the proposal. I just have a few questions:

Who is on the security council?
Is the security council made up of team members in different time zones?
At any given time, how many members of the security council will be able to respond to an emergency?

The Security Council’s expected response times vary among its members. For some entities, the shortest required response time is 15 minutes, which necessitates having a team monitor the chain 24/7 to meet this obligation. However, this level of responsiveness is not feasible for some individual council members, so they have longer SLAs.

@Sampka this is definitely a long due improvement many people have been looking for. the caveats I see here (that maybe just means better communication are)

  • Are you guys sure proof generation stays under 3h even for large batches? Cause if not, and people get used to 3h delay for withdrawals, and for any reason some batches takes 4h to be proven, a lot of noise/questions/fud might happen
  • What is the impact on other ZK chains? Nowadays all of them have the same 21h delay iirc, and with interop coming, it is expected that all of them have similar behaviour for better UX. Does this proposal (and security acoundil oversight) is also valid for them?
  • Are you guys sure proof generation stays under 3h even for large batches? Cause if not, and people get used to 3h delay for withdrawals, and for any reason some batches takes 4h to be proven, a lot of noise/questions/fud might happen*

Yes all of the proof generation is under 3 hours at this point even for large batches.

  • What is the impact on other ZK chains? Nowadays all of them have the same 21h delay iirc, and with interop coming, it is expected that all of them have similar behaviour for better UX. Does this proposal (and security acoundil oversight) is also valid for them?

This will immediately reduce all chain finalization delay to 3 hours, once interop comes it will change things more but as this is still being worked on i dont want to get into to many details. I will say once interop is live we will not see any finalization delays increase only more decreases.

1 Like

Hi Sampka, i like the idea of aways reducing the execution delay but how is 3 hours enough for the security council if for example some are sleeping? is the sc distributed enough? sorry if my question is a bit dumb.

The Security Council’s expected response times vary among its members. For some entities, the shortest required response time is 15 minutes, which necessitates having a team monitor the chain 24/7 to meet this obligation. However, this level of responsiveness is not feasible for some individual council members, so they have longer SLAs.

Currently, the Security Council can initiate a 12-hour soft freeze with the agreement of just three members. To extend the freeze beyond this period, approval from nine out of twelve members is required. The council comprises four entities with a 15-minute Service Level Agreement (SLA) to acknowledge and begin investigating an issue, another four entities with a 1-hour SLA, and the remaining four individuals have a 9-hour SLA. Given these response times, a 3-hour window provides more than enough time for at least eight members to investigate and decide whether to initiate a freeze.

1 Like

Hi @Sampka

Can we change the wording in this proposal as it does not impact ONLY zksync but also cronos zkEVM

Zksync → ZK chain

Would love to share this to our community

@Thomas Do these changes work?

1 Like

Cyfrin supports [ZIP-002], reducing the execution delay to 3 hours.

The proposal balances improved user experience with robust emergency protocols via the Security Council.

1 Like

Thanks for the reply. I will vote in favor of this proposal.

This comment has been formulated by the Treasure Delegate Council (TDC).

Given the the fact that there are ‘four entities with a 15-minute Service Level Agreement (SLA) to acknowledge and begin investigating an issue, another four entities with a 1-hour SLA, and the remaining four individuals have a 9-hour SLA’, we don’t see any downsides to reducing the execution delay to 3 hours. Yet, obvious benefits, as mentioned in the proposal itself (user experience and operational efficiency). Therefore, we are supportive of this initiative.

2 Likes

Thanks for the proposal. Is it ensured, that the security council could become active in the three hour time-frame? The seven days proposals are pending in Tally are much longer than that.