AnchorStateRegistry does not have the mechanism to invalidate game result
Summary
The AnchorStateRegistry is used by FaultDisputeGame to get the starting point of the game. Also games for earlier block number than the starting point given by anchorStateRegistry cannot be initialized. As soon as the resolution of a game is reached via FaultDisputeGame:resolve, the AnchorStateRegistry:tryUpdateAnchorState will be called to update the most recent rootClaim.
According to the protocol, the FaultDisputeGame may result in an incorrect resolution, and that is why the OptimismPortal2 should wait for the delay to give the time for guardians to blacklist incorrect games. However, the AnchorStateRegistry lacks this mechanism.
Vulnerability Detail
After a game is resolved via FaultDisputeGame::resolve, the function calls AnchorStateRegistry:tryUpdateAnchorState to update the rootClaim for the l2BlockNumber.
The problem is that if the game resolved for the newer block is actually resolved incorrectly, there is no way to update the anchor state. All the subsequent games will be based on this incorrect root claim.
Impact
The AnchorStateRegistry might end up with incorrect rootClaim, therefore all the subsequent games will have incorrect starting point.
lemonmon
medium
AnchorStateRegistrydoes not have the mechanism to invalidate game resultSummary
The
AnchorStateRegistryis used byFaultDisputeGameto get the starting point of the game. Also games for earlier block number than the starting point given byanchorStateRegistrycannot be initialized. As soon as the resolution of a game is reached viaFaultDisputeGame:resolve, theAnchorStateRegistry:tryUpdateAnchorStatewill be called to update the most recent rootClaim.According to the protocol, the
FaultDisputeGamemay result in an incorrect resolution, and that is why the OptimismPortal2 should wait for the delay to give the time for guardians to blacklist incorrect games. However, theAnchorStateRegistrylacks this mechanism.Vulnerability Detail
After a game is resolved via
FaultDisputeGame::resolve, the function callsAnchorStateRegistry:tryUpdateAnchorStateto update the rootClaim for the l2BlockNumber.https://github.com/sherlock-audit/2024-02-optimism-2024/blob/main/optimism/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol#L401
The AnchorStateRegistry will update the output root and l2BlockNumber, if the defender won and it is newer l2 block number.
https://github.com/sherlock-audit/2024-02-optimism-2024/blob/main/optimism/packages/contracts-bedrock/src/dispute/AnchorStateRegistry.sol#L86
These updated information is used to set the starting point of newly deployed games. Also it is not allowed to create a game with older block number.
https://github.com/sherlock-audit/2024-02-optimism-2024/blob/main/optimism/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol#L529-L539
The problem is that if the game resolved for the newer block is actually resolved incorrectly, there is no way to update the anchor state. All the subsequent games will be based on this incorrect root claim.
Impact
The AnchorStateRegistry might end up with incorrect rootClaim, therefore all the subsequent games will have incorrect starting point.
Code Snippet
https://github.com/sherlock-audit/2024-02-optimism-2024/blob/main/optimism/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol#L401
https://github.com/sherlock-audit/2024-02-optimism-2024/blob/main/optimism/packages/contracts-bedrock/src/dispute/AnchorStateRegistry.sol#L86
https://github.com/sherlock-audit/2024-02-optimism-2024/blob/main/optimism/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol#L529-L539
Tool used
Manual Review
Recommendation
Add functionality for guardians to update the rootClaim and l2BlockNumber information.
Duplicate of #81