In the dispute game, when moves are made, bonds are sent into the contract. The reward system functions such that if a user's claim is challenged, the user's bond is forwarded to the challenger. This introduces a financial aspect to the game, adding an additional layer of complexity.
When preparing a move, whether it's attacking or defending, this task involves significant knowledge, resources, and time for an honest participant. The core issue lies in the fact that the attack and defend functions can be front-run.
An honest user prepares their proofs and makes a move.
An attacker observing the mempool front-runs their transaction.
The attacker makes the move instead of the honest user.
Although one might argue that the attacker assumes some risk due to the bonding requirement, this risk is minimal. The honest user still loses out, as the attacker can front-run all the moves until the resolution of the dispute, effectively making the attack risk-free for the attacker.
Implications
This front-running vulnerability undermines the integrity of the dispute game. Honest participants are at a disadvantage as their carefully prepared moves can be preempted by attackers. This not only discourages participation but also threatens the fairness and reliability of the system.
Proof of Concept
Tools Used
Manual
Recommended Mitigation Steps
Implement a commit reveal scheme to protect honest workers
Lines of code
https://github.com/code-423n4/2024-07-optimism/blob/70556044e5e080930f686c4e5acde420104bb2c4/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol#L419
Vulnerability details
Impact
Background
In the dispute game, when moves are made, bonds are sent into the contract. The reward system functions such that if a user's claim is challenged, the user's bond is forwarded to the challenger. This introduces a financial aspect to the game, adding an additional layer of complexity.
When preparing a move, whether it's attacking or defending, this task involves significant knowledge, resources, and time for an honest participant. The core issue lies in the fact that the attack and defend functions can be front-run.
Exploit Scenario
An honest user prepares their proofs and makes a move. An attacker observing the mempool front-runs their transaction. The attacker makes the move instead of the honest user. Although one might argue that the attacker assumes some risk due to the bonding requirement, this risk is minimal. The honest user still loses out, as the attacker can front-run all the moves until the resolution of the dispute, effectively making the attack risk-free for the attacker.
Implications
This front-running vulnerability undermines the integrity of the dispute game. Honest participants are at a disadvantage as their carefully prepared moves can be preempted by attackers. This not only discourages participation but also threatens the fairness and reliability of the system.
Proof of Concept
Tools Used
Manual
Recommended Mitigation Steps
Implement a commit reveal scheme to protect honest workers
Assessed type
Context