Front running within the FuelVM

Fuel Network
1

I have a question regarding front-running within the FuelVM.

For simplicity, here’s a basic example of a pattern that could be front-run:

  1. Alice transfers an asset to the contract using a simple transfer.
  2. In a separate transaction, Alice calls deposit() with the assetId of the token she sent to the contract in the first transaction.
pub fn deposit(asset_in: AssetId) {
    let last_balance = storage.last_balance.get(asset_in);
    let new_balance = balance_of(ContractId::this(), asset_in);

    storage.last_balance.insert(asset_in, new_balance);

    let delta_balance = new_balance - last_balance;
    let current_user_balance = storage.user_balance.get(msg_sender());

    storage.user_balance.insert(msg_sender(), current_user_balance + delta_balance);
}

Bob, who is monitoring the network, sees that Alice sent an asset to the contract with the intention of calling the deposit() function. He quickly creates a call transaction to the deposit() function and specifies a tip amount, hoping to get his transaction included first in the block.

If Bob’s transaction succeeds, the smart contract will update Bob’s balance, not Alice’s.

My question is: how realistic is it to monitor the mempool on Fuel? Does Fuel have a public mempool? If the fuel mem pool is not public, could Bob listen for transactions that transfer assets to the contract that has the deposit() function? Could this type of front-running attack happen on Fuel?

If the transfer and then the call to the deposit() function were bundled into a multicall, would this prevent the front running vulnerability?

2

Front running is possible with any public blockchain

In this case, yes bob could steal alice’s balance, but that’s a consequence of a poor smart contract design rather than anything related to fuel

2 Likes
3

Excellent! Just wondering since some L2s don’t have a public mempool.

1 Like