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
  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?


  • @1sn0s Outcome would be deterministic in the long-run, but in the very short-run (milliseconds) the outcome is not deterministic. Am I right about that? Since you're never sure if the full node you're using / querying is building off the right chain, you always have a risk of getting your calculated state invalidated.
    – reedvoid
    Commented Feb 9, 2019 at 3:50
  • (Deleting my first comment, since I understood the scenario differently.) Your branching conditions are perfectly valid. EVM executions are deterministic. The outcomes will be deterministic. Building on top of right chain is a consensus issue, not an application level one. In the long run, yes the consensus on your state will be increasing (for PoW)
    – shonjs
    Commented Feb 9, 2019 at 4:05

1 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.

  • Thanks this is what I thought happened. I am building a DAG topology which is a lot more problematic when it comes to reordering.
    – reedvoid
    Commented Feb 16, 2019 at 6:17
  • It will be. There's always lots of fun wth logic at the interface between a contract and the external universe. Commented Feb 16, 2019 at 20:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.