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’ll be voting FOR this proposal as we find it important to fix the already known bugs in the production environment. However, we would like to raise our concern as to whether the current approach of releasing early and relying on fallback mechanism to prevent anything bad to happen is the right one.
As @Zachobront mentioned in a comment under the Protocol Upgrade #7 proposal, the Foundation’s approach to the fault dispute mechanism poses a reputational risk. As it was proven, Zach’s concerns were on point, and we now had to revert to the permission fallback mechanism while the bugs found in the fault dispute mechanism are patched.
While it might not seem like a big deal, given users’ funds were not at risk due to fallbacks, it actually is since there’s a very thin line between the current situation and a case where the Security Council is needed to secure the chain.
Luca Donnoh, a researcher at L2BEAT, has written an article that explains the risks associated with potential lack of trust in the fault proof mechanism:
… Even if the protocol requires a lot of funds to be pooled to protect it, one can argue that finding liquidity is not a difficult task since it eventually guarantees very high profits, assuming that the proof system works correctly. We argue that this assumption shouldn’t be taken lightly. Let’s say that an attacker actually spends billions of dollars to attack a protocol, and then signals on a social or with an onchain message that they found a bug in the challenge protocol where defenders are guaranteed to lose their funds. No one knows if the bug actually exists or if it’s just a bluff, but it can be used as an effective deterrent to prevent reaching the target amount of funds needed to save the chain. …
In simple terms, while the approach of deploying early and “testing in production” is safe in terms of there’s no (or very limited) risk to users’ funds as there are fallback mechanisms in place, we feel that if it leads to continuous instances where we actually have to use those fallbacks, it can damage confidence in the design of the system in the long run, and therefore make it much harder to get it working in a Stage 2 environment where no such fallbacks will be available.