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!
1 Like
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.
2 Likes
I participated in the Security Council Test-run as OpenZeppelin’s Council representative and was very reassured by the response time of Council members. I’m also grateful to the Matter Labs and ZKNation teams that helped organize the Test-run to help demonstrate and validate the Council’s readiness ahead of such an impactful proposal. 3 hours should be a more than sufficient time delay for the Security Council to initiate a soft freeze given that the Test-run was able to collect enough signatures in under 30 minutes.
Given the results of the Security Council Test-run and the clear UX benefits of a shorter execution delay, I am comfortable voting FOR the proposal as an independent delegate.
1 Like
We support the proposal to reduce the execution delay on ZKSync chains from 21 hours to 3 hours, as it will greatly enhance user experience and transaction speed while ensuring robust security under the Security Council’s oversight.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’re voting FOR the proposal.
Our primary concern with reducing the execution delay is ensuring enough time for the Security Council to intervene if needed. As pointed out by @Sampka, however, there are at least four entities with 15-minute SLAs to guarantee the response time. On top of that, there are four other entities with 1-hour SLAs. With that in mind, there are 8 Security Council members out of the three who need to initiate a 12-hour freeze, with SLAs to respond in under 3 hours.
The recent test run for the Security Council response time demonstrated the feasibility of adequate response for the majority of the teams involved in the Security Council.
Therefore, we feel comfortable reducing the execution delay to enhance user experience and operational efficiency while still maintaining a reasonable level of security.