Assertion Rely on Balance Amounts

Question

Is it possible in Ethereum blockchain to have two or more events simultaneously occurred?

Regarding the following solidity code:

    function _transfer(address _from, address _to, uint _value) internal {
    // Prevent transfer to 0x0 address. Use burn() instead
    require(_to != 0x0);
    // Check if the sender has enough
    require(balanceOf[_from] >= _value);
    // Check for overflows
    require(balanceOf[_to] + _value > balanceOf[_to]);
    // Save this for an assertion in the future
    uint previousBalances = balanceOf[_from] + balanceOf[_to];
    // Subtract from the sender
    balanceOf[_from] -= _value;
    // Add the same to the recipient
    balanceOf[_to] += _value;
    Transfer(_from, _to, _value);
    // Asserts are used to use static analysis to find bugs in your code. They should never fail
    assert(balanceOf[_from] + balanceOf[_to] == previousBalances);
}

What if some burning or minting operations have occurred and changed the balance of _to or _from after balances update but before assertion.

For example: Balance of (_from) = 10 , Balance of (_to) = 0 uint previousBalances = 10

function _transfered triggered and _value = 5 so after updating balances we will have Balance of (_from) = 5 , Balance of (_to) = 5 uint previousBalances = 10

What if after balances update but before assertion 3 tokens were minted to the address of (_to) Balance of (_from) = 5 , Balance of (_to) = 5+3 therefor assertion would be failed uint previousBalances = 5 + 5 + 3 = 13

IS THIS ASSERTION A RIGHT WAY TO CONTROL UPDATING BALANCES??

Answer 1

Concurrency is not possible.

Transactions are not accepted until mined. Mined blocks are well-ordered transaction lists. Each transaction executes in the context of the state following the transactions that came before it.

Your use of assert looks appropriate.

Hope it helps.

Answer 2

Keep in mind uint previousBalances = balanceOf[_from] + balanceOf[_to]; could already have been overflowed when checking the assertion later. So the transfer will fail even if its correct. But thats unlikely bcs it requires that both sender and recepient have more than uint256 tokens/eth together. Only then it fails.