State Transitions

A useful abstraction is S' = F(S, T): take prior state S, apply transition function F using transaction T, and produce new state S'. Every full node must reach the same output from the same ordered inputs or consensus breaks.

The transition function includes rules for authorization, balances, nonces, gas or compute limits, contract logic, and protocol bookkeeping. Consensus orders inputs; deterministic execution makes the ordered result reproducible.

Suppose an account has enough funds for only one of two competing payments. If transaction A executes first, transaction B may fail for insufficient balance. Reversing the order can reverse the outcome. The transactions themselves did not change; the starting state seen by the second transaction did.

This is why block ordering, mempool policy, and parallel scheduling matter to applications.

Before execution, nodes check signatures, chain identifiers, sequence numbers, fee capability, and other protocol conditions. A transaction that fails basic validity may never enter execution. A transaction that is valid to submit can still execute contract code that reverts while consuming allowed fees or compute according to the chain's rules.

Separating admission validity from execution result makes error analysis much clearer.

If one node used its local clock, random generator, or private web API during contract execution, another node could produce a different result. Blockchain virtual machines therefore expose only deterministic inputs or consensus-controlled context for state transitions. External information enters through signed transactions or oracle mechanisms rather than arbitrary local calls.

Determinism is what lets thousands of machines reproduce one state machine.

A state transition is a deterministic function from a valid prior state plus ordered input to a new state. The word deterministic is crucial: honest nodes that begin from the same prior state and execute the same valid transaction sequence under the same rules must reach the same result. Otherwise the network cannot maintain a shared ledger.

Validation happens before and during execution. A transaction may fail authorization checks, reference unavailable funds, violate nonce rules, exceed resource constraints, or trigger invalid execution. Protocols define whether a failed execution consumes fees, reverts state changes, or invalidates the entire enclosing block.

Ordering matters whenever transactions interact with the same state. If one transaction spends an output or modifies a contract value that another transaction depends on, reversing the order can change which operations succeed. Consensus therefore establishes an ordering or an equivalent deterministic schedule.

The state-transition view is powerful because it turns “blockchain” into a replicated computation model. The ledger is not merely appending text records. Each accepted block provides inputs that every validating node applies to a state machine. Agreement requires both common history and common execution semantics.

1. Write the state-transition idea as prior state + ordered input → new state.

2. Why must execution be deterministic across validating nodes?

3. Give an example where changing transaction order changes the outcome.

4. What is the difference between rejecting an invalid transaction and reverting a contract call, depending on protocol rules?

5. Why is consensus over ordering important even when every transaction is individually well formed?

6. Correct this statement: “A blockchain only stores transactions; nodes do not need to agree on how those transactions change state.”