Ledgers, Transactions & State Transitions

A blockchain is not “a database made immutable by hashes.” It is a replicated state machine whose inputs are transactions, whose history is grouped into hash-linked blocks, and whose ordering is chosen by a consensus protocol. Hashes make changes detectable; validation and consensus determine which history nodes accept.

Three objects that are often conflated #

1. Transaction history — the ordered commands.
2. Current state — what those commands produce: the UTXO set, account balances, contract storage, validator registry, and so on.
3. Commitments — fixed-size roots in headers that authenticate a transaction set or state without placing it all in the header.

A full node does not trust a header's state root. It validates the parent, checks every transaction, executes the transition function, recomputes the root, and accepts the block only if the values match.

flowchart TB
  P["parent state S"] --> V["validate transactions and execute δ"]
  T["block transactions"] --> V
  V --> N["new state S′ and recomputed root"]
  N --> C{"matches header root?"}
  C -- no --> X["reject block"]
  C -- yes --> A["candidate for consensus"]

UTXO and account models #

In Bitcoin, “balance” is a wallet-derived sum of spendable UTXOs, not a field in the consensus state. A valid ordinary transaction consumes existing UTXOs, creates new outputs, and cannot create value; the input-output difference is the fee. In Ethereum, the transition modifies a world state keyed by account address and can execute contract code, so gas bounds computation and makes resource use part of validity.

What hash linking actually guarantees #

Each block header commits to its predecessor. Editing an old transaction changes its transaction identifier or Merkle root, then the block header, then every descendant link. That makes tampering evident and—when consensus attaches cost or quorum evidence to descendants—expensive or impossible to make canonical.

Merkle proofs are inclusion proofs #

A Merkle tree hashes leaves pairwise until one root remains. To prove one transaction is included among $N$, supply the sibling hash at each level: $O(\log N)$ hashes rather than all transactions. The verifier reconstructs the root committed by the header.

This proves inclusion relative to a trusted header. It does not prove that the transaction was valid, that no relevant transaction was omitted, or that the header is canonical. Light-client security therefore combines compact commitments with a way to authenticate consensus.

Determinism and forks #

Consensus rules include serialization, signature checking, numeric bounds, state-transition semantics, and activation conditions for protocol upgrades. If two implementations interpret one byte string differently, they can both be internally consistent yet follow different chains. Canonical encodings, test vectors, differential testing, and explicit fork versions are therefore consensus-critical—not mere wire-format details.