Summary
We recently discovered a bug in an offchain component of Optimism’s fault proof stack that can lead to permissionless dispute games resolving incorrectly under certain conditions – this is medium-severity based on Optimism’s established classification framework. User assets are not at risk given Optimism’s multi-layered approach to security. Superchain chain operators currently relying on permissionless fault proofs, and chain servicers running infrastructure for these chains, have been proactively notified of this bug.
- The bug fix has been developed and audited. The fix will be included in the next release of op-program and op-challenger and we will be requesting governance approval along with the absolute prestate for Upgrade 15.
- This bug is related to how L2 transaction data (stored in EIP-4844 blobs) is made accessible to the EVM in the final stage of the fault dispute game.
- The fix is in this pull request.
- The independent auditor’s report is here. This auditor was selected for expertise with the relevant cryptographic protocols.
- Until this fix is deployed, established incident response safeguards would prevent any attempt to exploit this bug from succeeding. For this reason, we are recommending not proactively downgrading to permissioned dispute games or responding with an emergency fix.
- For clarity, the Optimism fault proof system allows for incorrectly resolved dispute games to be blacklisted from being used in L1 bridge withdrawals by the security council. There are monitoring and notification systems in place to detect dispute games resolving incorrectly, and established runbooks to handle this situation.
Context for evaluating fault proof vulnerabilities
- Optimism’s security posture for fault proofs focuses on fundamental safety mechanisms first – it takes a defence in depth approach assuming that bugs in the fault proof system do exist.
- There are safeguards in place: monitoring, the air gap, and the ability to blacklist games, and potentially fall back to permissioned dispute games.
- It’s very expensive for an adversary to attempt to exploit a fault proof vulnerability if it requires playing a full dispute game down to the
step()
function (they will require ~300 ETH in bonds which they will forfeit if they don’t win the dispute game), so they only have incentive to do so if they know they can succeed. And their success is unlikely, given the ability for the security council to blacklist an invalid game.
Rollout of bug fix
- Correctly loading of blobs into the Preimage Oracle only requires changes to op-challenger and op-program. There are no required code changes to any smart contracts, however we do need to deploy new contract instances (see below) and update offchain challenger cloud deployments.
- The change to op-program requires an update to the absolute prestate – FaultDisputeGame and PermissionedDisputeGame contracts are initialized with this value, meaning that new contracts will need to be deployed. This can not be handled just as an offchain infrastructure update.
- The fix will be included in the next release of op-program and op-challenger and we will be requesting governance approval along with the absolute prestate for Upgrade 15.