- 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.
- 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 - 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:
- 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.
- 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
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.
Will be voting yes based on the desirability of shorter finalization times combined with the strength of the Security BORG’s incident response time (enforced through service-level agreements) being likely sufficient to respond to a security incident within three hours.
background:
1 Like
Hey @bitblondy - As mentioned in the notes from the last Delegate call, this specific question was discussed starting around minute 43:06 in call recording!
The Security Council has posted an update related to a Response Time Test-Run that was completed on Monday 2 December. This Test-Run is relevant to ZIP-002 to the extent that the proposal relies on the Security Council responding to any emergency incidents which may arise.