Front Running

Front Running is a significant vulnerability in blockchain transactions. It occurs when an attacker observes a transaction before it is mined and manipulates the blockchain to their advantage. This vulnerability can be exploited to reorder transactions to the attacker’s advantage.

The Problem

Transactions take some time before they are mined. An attacker can watch the transaction pool and send a transaction, have it included in a block before the original transaction. This mechanism can be abused to re-order transactions to the attacker's advantage.

Let’s consider a simple Solidity contract as an example:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract FindThisHash {
    bytes32 public constant hash =
        0x564ccaf7594d66b1eaaea24fe01f0585bf52ee70852af4eac0cc4b04711cd0e2;

    constructor() payable {}

    function solve(string memory solution) public {
        require(hash == keccak256(abi.encodePacked(solution)), "Incorrect answer");

        (bool sent, ) = msg.sender.call{value: 10 ether}("");
        require(sent, "Failed to send Ether");
    }
}

In this contract, Alice creates a guessing game where you win 10 ether if you can find the correct string that hashes to the target hash.

Here’s how the front running vulnerability can be exploited:

1. Contract Deployment: Alice deploys the FindThisHash contract with 10 Ether as a reward for anyone who can find the correct string that hashes to the target hash.

2. Solution Discovery: Bob finds the correct string (“Ethereum”) that hashes to the target hash.

3. Solution Submission: Bob calls the solve function with “Ethereum” as the argument and sets the gas price to 15 gwei.

4. Transaction Pool Monitoring: Eve is watching the transaction pool for the answer to be submitted.

5. Front Running: Eve sees Bob’s answer in the transaction pool and calls the solve function with “Ethereum” as the argument but with a higher gas price than Bob (100 gwei).

6. Transaction Mining: Eve’s transaction gets mined before Bob’s because transactions with higher gas prices are typically mined first. As a result, Eve wins the reward of 10 Ether.

The vulnerability here lies in the fact that transactions take some time before they are mined and are put in the transaction pool during this time. An attacker can monitor the transaction pool, get the answer from a transaction in the pool, and send a transaction with a higher gas price so that their transaction will be included in a block before the original. This is known as front running and is a significant issue in blockchain transactions.

Preventative Techniques

Commit-Reveal Schemes

A Commit-Reveal Scheme is a cryptographic algorithm that allows someone to commit to a value while keeping it hidden from others, with the ability to reveal it later. The values in a commitment scheme are binding, meaning that no one can change them once committed. The scheme has two phases: a commit phase in which a value is chosen and specified, and a reveal phase in which the value is revealed and checked.

contract SecuredFindThisHash {
    // Struct is used to store the commit details
    struct Commit {
        bytes32 solutionHash;
        uint commitTime;
        bool revealed;
    }

    // The hash that is needed to be solved
    bytes32 public hash =
        0x564ccaf7594d66b1eaaea24fe01f0585bf52ee70852af4eac0cc4b04711cd0e2;

    // Address of the winner
    address public winner;

    // Price to be rewarded
    uint public reward;

    // Status of game
    bool public ended;

    // Mapping to store the commit details with address
    mapping(address => Commit) commits;

    // Modifier to check if the game is active
    modifier gameActive() {
        require(!ended, "Already ended");
        _;
    }

    constructor() payable {
        reward = msg.value;
    }

    /* 
       Commit function to store the hash calculated using keccak256(address in lowercase + solution + secret). 
       Users can only commit once and if the game is active.
    */
    function commitSolution(bytes32 _solutionHash) public gameActive {
        Commit storage commit = commits[msg.sender];
        require(commit.commitTime == 0, "Already committed");
        commit.solutionHash = _solutionHash;
        commit.commitTime = block.timestamp;
        commit.revealed = false;
    }

    /* 
        Function to get the commit details. It returns a tuple of (solutionHash, commitTime, revealStatus);  
        Users can get solution only if the game is active and they have committed a solutionHash
    */
    function getMySolution() public view gameActive returns (bytes32, uint, bool) {
        Commit storage commit = commits[msg.sender];
        require(commit.commitTime != 0, "Not committed yet");
        return (commit.solutionHash, commit.commitTime, commit.revealed);
    }

    /* 
        Function to reveal the commit and get the reward. 
        Users can get reveal solution only if the game is active and they have committed a solutionHash before this block and not revealed yet.
        It generates an keccak256(msg.sender + solution + secret) and checks it with the previously commited hash.  
        Front runners will not be able to pass this check since the msg.sender is different.
        Then the actual solution is checked using keccak256(solution), if the solution matches, the winner is declared, 
        the game is ended and the reward amount is sent to the winner.
    */
    function revealSolution(
        string memory _solution,
        string memory _secret
    ) public gameActive {
        Commit storage commit = commits[msg.sender];
        require(commit.commitTime != 0, "Not committed yet");
        require(commit.commitTime < block.timestamp, "Cannot reveal in the same block");
        require(!commit.revealed, "Already commited and revealed");

        bytes32 solutionHash = keccak256(
            abi.encodePacked(Strings.toHexString(msg.sender), _solution, _secret)
        );
        require(solutionHash == commit.solutionHash, "Hash doesn't match");

        require(keccak256(abi.encodePacked(_solution)) == hash, "Incorrect answer");

        winner = msg.sender;
        ended = true;

        (bool sent, ) = payable(msg.sender).call{value: reward}("");
        if (!sent) {
            winner = address(0);
            ended = false;
            revert("Failed to send ether.");
        }
    }
}

In this contract, Alice deploys SecuredFindThisHash with 10 Ether as a reward for anyone who can find the correct string that hashes to the target hash. Bob finds the correct string (“Ethereum”) and calculates the keccak256 hash of his wallet address in lowercase, the solution, and a secret (“mysecret”) that only he knows. Bob then calls commitSolution with the calculated solution hash and a gas price set to 15 gwei.

Eve, who is watching the transaction pool, sees Bob’s answer and also calls commitSolution with the same solution hash but a higher gas price than Bob (100 gwei). Eve’s transaction gets mined before Bob’s, but she hasn’t won the reward yet. She needs to call revealSolution with the exact secret and solution.

Bob then calls revealSolution with “Ethereum” and “mysecret” as arguments and a gas price set to 15 gwei. Eve, who’s still watching the transaction pool, finds Bob’s revealSolution transaction and also calls revealSolution with “Ethereum” and “mysecret” as arguments and a higher gas price than Bob (100 gwei).

Eve’s revealSolution transaction gets mined before Bob’s, but it reverts with a “Hash doesn’t match” error because the revealSolution function checks the hash using keccak256(msg.sender + solution + secret). So, this time Eve fails to win the reward. However, Bob’s revealSolution transaction passes the hash check and he gets the reward of 10 ether.

This example demonstrates how a Commit-Reveal Scheme can be used to prevent front-running in blockchain transactions.

Resource: https://medium.com/swlh/exploring-commit-reveal-schemes-on-ethereum-c4ff5a777db8

Submarine Sends (https://libsubmarine.org/)