What is the "pre-commit" scheme to defeat frontrunning attack?

Question

I am writing to inquire feasible strategies to defeat Transaction Ordering Dependence (TOD) bugs.

I learned from the best practice guideline such that we can use a so-called "pre-committed" scheme to defeat TOD attacks: https://consensys.github.io/smart-contract-best-practices/known_attacks/#front-running-aka-transaction-ordering-dependence

However, it is still unclear to me how does the "pre-committed" scheme is implemented. Could anyone shed some lights or some code fragment of such implementations? Also, besides such "pre-committed" scheme, what else can be done to defeat TOD attacks?

======== update ====================

contract TransactionOrdering { 
 uint256 price; address owner; 

 function buy(uint256 amount) {
   cost = price * amount       
   return cost;                
 }                             

  function setPrice(uint256 _price) {
    // owner can set the price.      
    if (msg.sender == owner)         
      price = _price;                
  }                                  
}                                    

Let's suppose when the contract owner see a transaction of buy from the user, then the owner front runs a setPrice transaction to raise the price. Can the pre-committed pattern be used to defeat such attacks? Thanks a lot.

Answer 1

Let's suppose you have a raffle and can reserve a number

contract Raffle {
    mapping(uint256 => address) reserved;

    event Reserved(uint256 value, address owner);

    function reserve(uint256 value) public {
        require(reserved[value] == address(0), "Already reserved");
        reserved[value] = msg.sender;
        emit Reserved(value, msg.sender);
    }
}

This contract is affected by front running. If you reserve number 42 anybody can see your transaction before it is mined. A malicious actor can submit a transaction reserving the same number with a higher gas price and make your reserve fail.

A common solution is to first commit a hash instead of your data. In a second step you reveal the data that produces the committed hash.

1. Calculate your hash by calling the digest function with a random nonce, value and address. The nonce is to prevent the attacker to use brute force to try to derive your value from the hash.
2. Send the hash calculated to the contract. Since commitments are stored by user the attacker can send the same hash but it will not prevent a legitimate user from registering a hash.
3. Call reveal to show your data and make the reservation. Here all the data is available to the attacker but it cannot make a reservation at this stage, and brute forcing a previously reserved hash should not feasible.

.

contract Raffle {

    mapping(address => bytes32) commitments;
    mapping(uint256 => address) reserved;

    event Reserved(uint256 value, address owner);

    function commit(bytes32 hash) public {
        require(commitments[msg.sender] == bytes32(0), "Already committed");
        commitments[msg.sender] = hash;
    }

    function reveal(uint256 nonce, uint256 value) public {
        bytes32 d = digest(nonce, value, msg.sender);
        require(commitments[msg.sender] == d, "Invalid data");
        require(reserved[value] == address(0), "Already reserved");
        reserved[value] = msg.sender;
        emit Reserved(value, msg.sender);
    }

    function digest(uint256 nonce, uint256 value, address sender) public pure returns (bytes32) {
        return keccak256(abi.encodePacked(nonce, value, sender));
    }
}