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

Simple Summary

This proposal is a resubmission of ZIP-2. For more information related to the recommendation to resubmit the proposal please see this forum post by the ZKsync Security Council.

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

This proposal is a resubmission of ZIP-2. For more information related to the recommendation to resubmit the proposal please see this forum post by the ZKsync Security Council.

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.