Can smart contract reference its own state variables to make branching decisions?

Question

I have to apologize for not being very familiar with solidity or the EVM ahead of time.

Say that in the contract there are several state variables, a, b, c.

It would seem like that if I wrote a function within the contract with logic that's something like,

if a > 5 then
  b = 3
else
  c = 2

then I run into a pretty big risk that depend on when this call is run, the function will branch into different sections because the contract call has no understanding for whether or not the value a that it is accessing has received enough confirmations for me to be confident that it won't produce unpredictable results. At one time when you run it, it could branch into b=3, at another later time it could branch into c=3 all depending on the ordering and which previous block won out.

Is this a valid concern? Is this allowed in smart contracts? Is there a way for me to elevate this type of branching logic into some sort of higher, application-level code to make sure that I do not produce temporarily different outcomes depending on which split second I queried it from a full node?

Thanks!

Answer 1

Can smart contract reference its own state variables to make branching decisions?

Yes, they can. Contracts wouldn't be very useful if this was problematic.

the value a that it is accessing has received enough confirmations.

This is a misunderstanding. It's the not the states that receive confirmations. It's the inputs. State is the result of those inputs. The "inputs" are transactions that are either accepted and processed entirely or fail completely. They are "atomic". It may help also to think of them as instantaneous as there can be no "in progress" state once they are included in a block.

Your example doesn't show where a's value came from. Let's say it's a counter.

function incrementA() public {
  a = a + 1;
}

Great. Now we can imagine a scenario wherein there are all sorts of approximately simultaneous transactions that invoke this function. How does the contract know the state of b and c?

Simply put, the contract executes in the state from previously mined transactions. There is no ambiguity here.

Transactions themselves may be re-ordered or disappear in some cases because of chain reorganization and that is why you would wait for confirmations of the inputs. In no case would a's value depart from a transaction history in the canonical chain that supports it.

Suppose three such transactions were mined, then a is 3. Conditional logic will reflect the state. In the unlikely event that it turns out that one of those transactions was unacceptable and other nodes figure it out and drop said transaction from the history, then a would be 2 and all related conditional logic and state information would reflect that.

The history and the state will always be internally consistent. a, b, and c have the values they have at each block height because of the transaction mined up to that point and the logic in the contract.

Hope it helps.