Hi @inphi,
Thanks for putting up the detailed proposal about a potential upgrade to fix the vulnerabilities found in the conducted audits after the deployment of the Fault Proofs upgrade. We appreciate the team’s effort on fixing the issues and improving the system further while activating the permissioned fallback mechanism with proper coordinations and cautions.
Let us clarify two points,
Looking at the Cantina’s audit report, Cantina 3.1.1 was considered “Critical”, the most severe bug type of which must be fixed ASAP while you indicated this bug’s severity as “High”. That’s possibly because the team considered a potential exploit is not feasible with the Go runtime memory protection, but we believe it’s misleading as it’s an important information for us to evaluate how the Fault Proofs system should be reviewed and audited going forward. You mentioned other issues that weren’t found from the audit were identified because of running the system in production, but this is not necessarily because of deploying the system without audits complete.
In the last upgrade proposal, we (alongside @zachobront) expressed the concern about the fact that the system would be deployed without proper audits on the upgrade code while we understood that you made the clarification on how OP Labs considered the upgrade and audit on it. Yet, we suggested that coordinating with the security council, the Labs could reconsider the deployment timing. Apparently, the deployment was occurred as planned and now, there was a critical bug that caused a fallback operation. Was there even a discussion about the concerns that we made? How’s Security Council responsible for the situation?