QSP-5 Race Conditions / Front-Running

[kbak]

Issue Type

[X] bug report
[ ] feature request

Current Behavior

Files(s) affected: PaymentStandardExitRouter.sol, PaymentInFlightExitRouter.sol

Related Issue(s): SWC-114

Severity: Low

Description: A block is an ordered collection of transactions from all around the network. It's possible for the ordering of these transactions to manipulate the end result of a block. A miner attacker can take advantage of this by generating and moving transactions in a way that benefits themselves.

Specifically, as anyone can see the challenge transactions in the transaction pool, they may try to front-run them. This may disincentivize legitimate users from attempting challenges. The following functions are vulnerable to front-running:

• PaymentStandardExitRouter.challengeStandardExit(),
• PaymentInFlightExitRouter.challengeInFlightExitOutputSpent(),
• PaymentInFlightExitRouter.challengeInFlightExitInputSpent(), and
• PaymentInFlightExitRouter.challengeInFlightExitNotCanonical()

Suggested Fix

Currently we have no recommendation. One could design a protocol that is resistant to TOD, but it would make the implementation of challenges more complex. At this point, the benefit of doing that is unclear.

[boolafish]

ref: https://github.com/omisego/plasma-contracts/pull/574 TL;DR a mitigation of front-running is implemented as we've monitored some really simple front-running happened on main net via replaying the tx with higher gas to get priority.