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:
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.
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.
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.