could you also elaborate on Cantina 3.3.5, i.e. the incorrect implementation of the srav opcode? why is it considered low severity?
The srav opcode deviating from the spec is only considered low priority because the actual MIPS instructions generated by the go compiler when compiling op-program are not affected by the difference in behavior. So it doesn’t currently have an impact on the fault proof system but may in the future due to changes in the go compiler or op-program. Additional information about this class of bugs can be found on this section of the Cannon FPVM spec
secondly, to me it’s a bit concerning that the fault proof system is outside the scope of external audits. I understand that in Stage 1, given the fallback, the blacklisting mechanism, the pause button and the Security Council, a bug is unlikely to affect the safety of the system. Citing Vitalik, the amazing property of Stage 1 rollups is being able to be safe AND live assuming <25% of honest members in the SC, also assuming small probability of bugs. If this probability is not small, and the system is often in the fallback state, the system mostly relies on a >75% honesty, defeating the purpose of Stage 1.
The audit framework gives some more detail on the reasoning behind the choice to leave the fault proof system outside of the initial scope. We feel that one of the best ways to gain confidence in the fault proof system is to operate it in the real world. This proposal is a good example of that - three audits have been completed and while they did find a number of issues, there were also issues they did not find that were identified either through the bug bounty program or from experience actually working with the fault proof system.
You are absolutely right that reducing the probability of bugs in the fault proof–as this upgrade itself seeks to accomplish–is important, and we felt that the path we took would ultimately get us to a bug-minimized system the fastest. At the end of the day, the community should be empowered to hold us accountable to how upgrades happen. While we (and even those who voted no on the original upgrade) continue to believe that the risks posed by this approach are not about the fundamental security of the system, there should continue to be space for the community to push back if they feel that other (i.e. reputational) risks are too high going forward.