Are simultanous transactions possible (basic but potentially very dangerous security concern...most likely impossible...)?

Question

Long story short I am curious how a contract stores variables in memory, so is it possible to spam say 100 transactions at once and the values to be changed afterwards...I am sure I am giving bad description so here is the code to better illustrate my point:

contract thiscontract
{

uint256 balancer = 3000;

function something() public payable
{
if(balancer > 0)
{
balancer -= 1000;
msg.sender.transfer(1000);
//event Transfer(msg.sender, balancer);
}

}
}

Basically: The function should send no more than 3000 wei, each time sending 1000 wei - if 4th msg.sender calls it after the first 3 calls it will not send anything since the value is 0 and the "if" statement prevents it.

But what will happen if 100 or more transactions call the "if" simultaneously? Does the contract 'freeze' and processes every single check one after another? Or does the contract allow some sort of parallelism like a web server and many people can call it and do this exact operation in parallel?

Because if the case is as described in "parallel" what happens is:

// it takes 0.05 seconds or so to check "if" statement... // however 10000000 calls are made to cause denial of service/parallel check:

if (balancer > 0)

// let's say 5000 pass the check and continue to sending... If someone calls it an hour later it will surely fail but still way many succeed.

I am sure this isn't possible, the only thing I know is "if" check or "Require" takes some computational time and you can read a contract without any blockchain interaction, however this is so basic that it can't be possible. Maybe someone should send 200 transactions via loop statement in web3 js/python on ropsten and see if they all obey the if rule above or more succeed or better yet pass them to aws instances who execute transactions in parallel.

Final note for now: From purely programming point of view this may be impossible since the transaction will be sent to bytecode assembly LIFO which will obey the "last in, first out" rule causing indeed freeze/slowdown and impossibility of parallel execution (so no: solidity seems far simpler than java/c# or webservers with asynchronous calls and so on). I am not 100% sure and maybe the many nodes can make it possible but I admit I have limited understanding of how exactly the transaction flow occurs between Ethereum nodes.

Answer 1

tl;dr: Your transactions will be executed in a sequential order.

You cannot determine the order beforehand, because the miners decide which transactions will be added to the block. When you create let's say 4 transactions calling your something() function at the same time, you create those while the Smart Contract has the state "balancer = 3000". If you simulate their execution on the current state, all of them will pass. You send them to the ethereum network, the nodes within the network verify them regarding the common consensus rules and store and relay them to other nodes if they are okay. Miners who continiously create blocks will eventually include them in blocks (assuming your supplied gas is attractive enough for them). You cannot determine in which blocks those transactions will be included (but you can reduce the average time by supplying an attractive amount of gas). Each transaction is put in a sequential order within a block and each block is put in a sequential order within the blockchain. When a block is "executed" (verified, stored and relayed), the transactions within are executed one after another, depending on the order the miner has specified. After the execution of a transaction, the state is updated accordingly and every following transaction will be executed upon that new state.

One sidenote: Use require(...) within your something(...) function if the conditions are not met. This way you ensure that the smart contract reverts in case the conditions are not met and that the sender therefore receives the funds (the remaining gas and the ethereum supplied to the "payable" function) back.