Hi all,
I shared an objective overview of the facts of this upgrade above on behalf of the Developer Advisory Board, but wanted to follow up with a personal message explaining why I plan to vote no on this proposal.
Here are a few facts for context:
- If this proposal passes, deployment will occur on June 10th.
- The Fault Dispute Game itself has not been audited.
- There is an audit contest for the Fault Dispute Game that is scheduled for July.
- The safeguards themselves have received a thorough audit and no High Severity issues were found.
- This audit was focused only on the on chain components and assumed that off chain monitoring and execution worked perfectly.
- In the event that there is a bug in the Fault Dispute Game and the safeguards need to be used, the Optimism Bridge will go down temporarily and all pending withdrawals will need to be reproven.
These facts lead to me the conclusion that there is quite a serious downside risk of things going wrong after this upgrade, with very limited upside.
In terms of risks, I would suggest two major categories:
1) Reputation
I think it is highly likely (80%+) that there are critical bugs still in the Fault Dispute Game. This is no fault of the OP Labs dev team. It’s incredible complex code and hasn’t been audited. It would honestly be astonishing if there were no serious bugs.
In the event that a single critical bug is found and requires shutting down the bridge, it would cause major reputational damage for Optimism. Even though there are safeguards, mainnet bridge code having a critical bug would be very bad for public perception.
If this happens more than once (which doesn’t seem out of the question), the reputational damage would be quite a bit worse.
2) Security Risk
I participated in the contest focused on the safeguards, and feel very confident in the on chain components functioning safely.
However, the whole system relies on two facts:
- Off chain monitoring will catch any fraudulent games
- The guardian role will be able to move quickly enough to override a fraudulent game before the withdrawal is executed
In general, I feel uncomfortable about the idea that proactive action is needed to secure a multibillion dollar protocol. Although it is unlikely, it feels like there is just too much that could go wrong with this much at stake.
For example, after Protocol Upgrade #8, the guardian role is performed by the 10/13 security multisig. For a normal protocol, this might be sufficient, but with billions of dollars on the line, it doesn’t seem out of the question that an attacker could take 4 signers temporarily offline for a few days until their withdrawal is processed.
(Note that I believe the Foundation has an override here, so this example may not be exactly right, but my point is that anything that requires proactive action does not feel like adequate security to me.)
I want to make clear that I have the utmost respect for the OP Labs team and think the Fault Dispute Game is incredible well built. I am excited for it to be deployed.
But I think it is rushed to try to perform this deployment before the Fault Dispute Game audit is complete. No code this complex is perfect, and the downside of there being issues feels too large to justify taking the risk.
For these reasons, I plan to vote no on this proposal, and look forward to voting yes later in the summer when the risks have been addressed.