From Blocks to State: A Mental Model for Blockchain Systems

Blockchain systems are usually described in terms of how blocks are produced, propagated, and finalized. This works when reasoning about a single protocol.

Across chains, the word block persists while its meaning shifts. Timing, ordering, guarantees, and finality no longer align, and different systems often disagree on what a block even represents.

As a result, cross-chain discussions often feel imprecise. The vocabulary is already tied to a specific implementation and quietly carries assumptions not shared everywhere.

If not blocks, what are we actually reasoning about?

Blockchains as State-Transition Systems

At a fundamental level, a blockchain maintains and advances state. It behaves like a state machine: an initial state exists, inputs arrive (such as transactions or smart contract calls), transition rules are applied deterministically and a new state emerges. Convergence relies on applying valid transitions in a consistent order.

Blocks sit on top of this mechanism. Their role is to encode a proposed execution: a reference to a prior state, an ordered set of inputs embedded in the block's contents, and the resulting state obtained by applying them. The ordering exists only through this encoding. Any participant can independently replay the execution and verify that the outcome matches the block's claim.

Different systems construct and propagate these encoded executions in different ways. Some aggregate many inputs before publishing an ordered execution, while others publish smaller ones more frequently. In some designs, ordering is explicitly tied to time windows. In others, execution proceeds optimistically and conflicts are resolved later. These choices affect performance and convergence, but not the underlying structure.

Despite these differences, the underlying process remains the same: blocks establish an ordered prefix of state transitions that the network can validate and extend.

Introducing State Candidates

A blockchain system may have more than one plausible version of its state.

This situation arises because state transitions are proposed and propagated through an asynchronous network. Participants do not observe the same inputs at the same time, and they do not advance state in lockstep. As proposed transitions spread, each participant independently executes and validates them, advancing state based on the information currently available.

Until the system converges, several possible outcomes can coexist.

A state candidate refers to one such plausible state of the system. It represents the result of applying a particular sequence of valid transitions starting from a shared history. Different candidates usually share a long, already-agreed history and diverge only at the frontier where new transitions are still propagating. Deeper divergence can occur during periods of instability, when reconciliation is delayed.

The presence of multiple state candidates is a normal operating condition. Network latency, timing boundaries, proposer rotation, and temporary forks all create situations where participants advance state along slightly different paths. These paths are valid under the same rules, but they are not immediately reconciled, and no single candidate can yet be treated as authoritative.

As a result, the notion of a single "latest" state is inaccurate. What appears current from one vantage point may lag or differ from another. During propagation, multiple state candidates remain valid at the same time.

Competing Futures and Candidate Sets

Rather than a single future, a blockchain system carries a set of candidates representing the states it may converge to next. This candidate set captures the system's current ambiguity. It reflects the fact that different participants have observed, validated, and extended different sequences of transitions.

This ambiguity is expected, as distributed systems operate under partial visibility and asynchronous communication. New transitions are proposed before previous ones have fully propagated, and participants must continue advancing state without waiting for global agreement. The result is a temporary exploration of multiple futures.

Over time, this ambiguity contracts. Some candidates gain support and are extended further. Others stop receiving extensions and are eventually discarded. Resolution rules guide this process, collapsing the candidate set as information propagates and agreement strengthens.

Most of the time, the candidate set remains narrow and short-lived. Under normal conditions, divergence is limited to the most recent part of state progression and resolves quickly. During instability, the set may widen or persist longer, but the underlying process remains the same.

The system is not failing when multiple competing futures coexist: it is operating as designed, gradually narrowing the space of plausible outcomes until convergence is reached.

Commitment Is a Gradient

State in a blockchain system does not move cleanly from unfinalized to final. Commitment measures how expensive it would be for the system to undo a state.

As a state candidate is observed and extended, more work accumulates on top of it. Commitment grows as a side effect of this accumulation. More participants rely on it and reverting it would require discarding an increasing amount of shared history.

Different systems expose this through different mechanisms:

• Confirmations measure how much history has been built on top of a state
• Checkpoints mark points that are treated as increasingly stable
• Proofs encode conditions under which reverting a state becomes invalid

These mechanisms differ in form, but they all serve the same function: they raise the cost of reversion.

Canonical State Is a Decision

In practice, systems often need to act before finalization. They must answer questions like: what is the current balance, which orders are valid, which messages should be processed. Waiting for full finality is impractical. Progress requires choosing a state earlier.

That choice produces a canonical state: the state treated as authoritative for the purpose of making decisions. This does not mean the state is final. It means it has been selected. Canonicalization is therefore a decision made under uncertainty. It reflects a judgment that one state candidate is sufficiently likely to survive resolution and finalization to be acted upon.

Different systems make this decision at different points. Some wait for stronger commitment and accept additional latency. Others decide earlier and tolerate higher risk.

Downstream systems inherit this risk implicitly. When they consume a canonical state, they assume that reversions are unlikely enough to tolerate. If that assumption fails, they must absorb the consequences.

This is why canonical state should not be confused with truth. It is an operational decision that the system may later confirm through finalization, or invalidate it through reversion. Until then, canonical state is simply the best answer available at the time.

Finalization Is a Protocol Event

At a specific point in time, the protocol declares that a particular state can no longer be replaced by alternatives without violating its rules or incurring prohibitive penalties. Before that point, reversion may be expensive or unlikely. After finalization, reversion is no longer a valid outcome within the protocol.

Unlike commitment, finalization is binary. A state is either finalized or it is not, relative to a trusted checkpoint defined by the protocol.

Some systems delay finalization by design. They allow state to progress and accumulate commitment while postponing the moment where reversion becomes impossible. This can improve throughput, reduce coordination overhead, or preserve flexibility under normal conditions, at the cost of leaving recent state reversible for longer.

Finalization marks the boundary beyond which alternatives are no longer considered.

Time, Convergence, and State Progression

State candidates evolve over time: as new inputs arrive and are propagated, candidates are extended, discarded, or superseded by others. Some grow longer and accumulate commitment. Others stop being extended and lose relevance as participants focus on different candidates. The system is constantly advancing multiple possible futures, even if only one will eventually remain.

Convergence is the process by which this set of candidates collapses. Over time, participants align on a common history and extend the same state. This alignment does not happen instantly, nor uniformly across the network. Temporary disagreement is expected. What matters is that disagreement shrinks.

Speed alone does not guarantee convergence. A system can produce state quickly while allowing ambiguity to persist. Another may progress more slowly but reduce uncertainty earlier. These choices reflect different priorities: responsiveness vs certainty, throughput vs coordination.

This is why chains feel different in practice. Different systems handle ambiguity differently. Some surface it to downstream consumers and require them to reason about it while others resolve ambiguity internally and present a single view as early as possible.

Among systems that surface ambiguity, some prioritize fast progress and accept longer periods of uncertainty. Others wait longer to reduce uncertainty before acting, trading latency for stronger guarantees.

Resolution Rules: How One State Wins

Resolution rules define how participants choose which candidates to extend and which to ignore. They do not immediately eliminate alternatives. Over time, this causes some candidates to continue accumulating extensions while others stop progressing.

These rules are applied continuously and are evaluated whenever a participant decides how to advance state. Some systems use deterministic resolution rules: given the same set of candidates, participants will select the same one to extend. This reduces disagreement quickly and limits how long multiple futures remain viable. Other systems use probabilistic resolution rules: participants favor candidates that appear more likely to be finalized, even though alternatives may remain possible for longer.

These choices encode different risk preferences. Deterministic resolution prioritizes fast alignment and predictability. Probabilistic resolution tolerates longer periods of ambiguity in exchange for responsiveness and flexibility under uncertainty.

What ultimately drives convergence is commitment. Candidates that accumulate more extensions, more dependent history, and more reliance become increasingly attractive to build on. Candidates that fail to attract activity lose relevance and are eventually discarded. No explicit removal is required. They simply stop being extended.

Seen this way, convergence is a filtering process. Resolution rules do not declare a winner outright. They apply steady pressure until one candidate dominates and the rest fade away. In extreme failures, such as catastrophic bugs or widely contested outcomes, resolution may no longer be purely protocol-driven. In these cases, convergence shifts to off-chain coordination and social consensus, temporarily overriding the automated resolution process.

Why This Matters

Blockchains can be hard to reason about because the language used to describe them hides uncertainty. Terms like "latest", "confirmed", or "final" collapse multiple system states into a single label. When disagreement or reversion occurs, that simplification breaks down.

Making ambiguity explicit changes how systems are described. Separating state candidates, commitment, resolution and finalization allows behavior to be described precisely without being bound to any single protocol. The same vocabulary can be applied across designs, even when the underlying mechanics differ.

When uncertainty is treated as a normal operating condition rather than an edge case, cross-chain reasoning improves. Downstream systems can model ambiguity directly instead of pretending it does not exist and being surprised when it leaks.