A block in a blockchain is a structured proposal for how to order a set of transactions and move the system from one state to a new candidate state. It is not inherently final history, but one step in an ongoing process of converging on a shared ledger. This guide focuses on blocks as proposed orderings and state transitions, not on mining vs staking, reward formulas, or user interface details. It explains why blocks are produced before there is network-wide agreement, why fresh blocks are untrusted and replaceable, how forks create temporary competing histories, and where block inclusion fits in the full lifecycle of a transaction. The goal is to replace the “blocks as permanent containers” picture with a mechanism-level mental model that works across blockchain designs.
1. The Naive View: Blocks as Containers
The first explanation many people hear is that a blockchain is a chain of blocks, and each block is like a box or a page in a ledger that stores transactions. In this picture, once a transaction is written into a block, it feels as if it has been written in ink and becomes permanent history.
This analogy is attractive because physical pages and boxes do not change once filled, so it is natural to assume the same for blocks. The problem is that this skips an important system detail: recent blocks are still candidates, and the protocol allows them to be replaced when a better-supported ordering appears. Treating blocks as immutable storage objects hides the fact that their main role is to propose an ordering, not to archive data.
- Assuming that once a transaction appears in any block, it is permanently part of the ledger and cannot disappear.
- Treating a block primarily as a storage container for transaction data instead of as an ordered sequence that defines how state should change.
- Believing that all nodes instantly and globally agree on the latest block as soon as it is produced.
- Equating the tip of the longest chain a node sees with unquestionable, finalized truth.
2. Blocks as Proposed Orderings
At the system level, a block is a data structure that proposes a specific ordering of transactions on top of a particular parent block. It says, in effect, “if you accept this parent as the current history, here is the next ordered batch of transactions to apply.”
Each block contains a reference to its parent, an ordered list of transactions, and metadata that lets nodes verify and interpret it. When a node receives a block, it does not treat it as truth; it treats it as a candidate extension of the history defined by the parent. Multiple different blocks can extend the same parent, meaning multiple different proposed orderings can coexist until the consensus process selects one branch as the canonical continuation.
- An explicitly ordered list of transactions, where position in the list determines which transaction is applied first, second, and so on.
- An implied candidate next state: if these transactions are valid and applied in this order to the parent’s state, they yield a deterministic new state.
- Metadata such as timestamps, cryptographic commitments, and producer identifiers that nodes use to validate and compare proposals.
3. Why Ordering Matters More Than Storage
Blockchains care about ordering because many transactions conflict: they touch the same balances, the same contract storage, or the same shared resources. If two transactions both try to spend the same coins or modify the same variable, the result depends on which one is applied first.
Raw storage of transaction data is relatively easy; many databases or archival systems can store bytes. The hard part is getting all honest nodes to apply the same transactions in the same order so they all compute the same resulting state. Blocks exist primarily to coordinate this ordering across the network, not because the system lacks other ways to keep a record of the data.
- If storage is available but ordering is ambiguous, different nodes may apply the same transactions in different orders and end up with incompatible balances and states.
- If ordering is consistent but long-term storage is outsourced or pruned, nodes can still agree on the current state as long as they can reconstruct or verify the ordered history they rely on.
- When two double-spend transactions are both stored but not consistently ordered, some nodes may consider one valid while others consider the other valid, breaking the shared ledger property.
- By enforcing a single agreed order inside each accepted block, the protocol ensures that all honest nodes resolve conflicts in the same deterministic way.
4. Blocks and State Transitions
The state of a blockchain system is the current snapshot of all relevant data: account balances, contract storage, nonces, and other protocol-defined fields. Every node maintains a local copy of this state derived from the history of accepted blocks it has processed.
When a node considers a new block, it starts from the parent block’s state and applies each transaction in the block’s order according to the protocol rules. If all transactions are valid, this deterministic computation yields a unique candidate next state associated with that block. The block therefore represents a proposed state transition from state Sₙ to state Sₙ₊₁, conditional on the network later agreeing that this block’s ordering is the one to keep.
- Locate the parent block referenced by the new block and load the corresponding current state Sₙ from local storage.
- Iterate through the block’s ordered transactions one by one, checking signatures, balances, nonces, and any protocol-specific validity conditions.
- For each valid transaction, update the state deterministically: adjust balances, modify storage, and record any protocol-defined side effects.
- If any transaction is invalid under Sₙ or the partially updated state, reject the entire block as invalid according to the rules.
- If all transactions are valid, record the resulting computed state as the candidate state Sₙ₊₁ associated with this block.
5. Block Production vs Agreement
Block production is a local act: a designated producer (miner, validator, or other role) selects transactions, orders them, builds a block extending some parent, and broadcasts it. At the moment of creation, this block is just that producer’s proposal for the next step in the chain.
Other nodes receive the block at different times and compare it with any competing proposals they see. They may tentatively adopt it as their current best tip based on the consensus rules, but this is not the same as final agreement. Agreement emerges only after further blocks are built on top of some branch and the consensus mechanism makes alternative branches increasingly unlikely to overtake it. The key separation is that production is instantaneous and local, while agreement is gradual and network-wide.
- The producer broadcasts the block to peers, who independently verify its structure, signatures, and state transition validity.
- Other producers may create competing blocks on the same parent, causing nodes to temporarily diverge in which block they treat as the tip.
- As more blocks are produced, one branch becomes better supported under the consensus rules, and nodes converge on a common chain where earlier blocks become increasingly stable.
Pro Tip:A junior engineer wired an off-chain shipment system to trigger as soon as a payment transaction appeared in the first block they saw. A short reorg replaced that block with a competing one that did not include the payment, leaving the shipment sent but no on-chain record. The incident forced the team to distinguish block production (a proposal) from later agreement (sufficient depth and stability) in their design.
6. Why Blocks Are Not Final
Blocks are intentionally not final when first produced because the network is distributed and messages arrive at different times. Two producers can legitimately create different valid blocks on the same parent before hearing about each other’s work, and different nodes may see these proposals in different orders.
If the protocol treated the first block a node saw as instantly irreversible, small timing differences would permanently fragment the ledger. Instead, consensus rules allow short periods where multiple candidate histories exist, and nodes are prepared to switch to a better-supported branch. This design sacrifices instant finality near the tip in order to gain safety and eventual agreement across a large, unreliable network.
- “A block is not final history the moment it is produced”; it is a candidate that can still be replaced by a competing branch.
- “Block inclusion is not a guarantee that a transaction will remain in the ledger”; transactions from discarded blocks may need to be re-included in later blocks.
- “The latest block is not a globally locked-in truth”; different nodes can legitimately see and temporarily favor different tips.
- “Reorganizations are not necessarily protocol failures”; they are a built-in mechanism for resolving temporary disagreement about which block sequence to keep.
7. Competing Blocks and Temporary Histories
When two valid blocks extend the same parent, they define two different candidate next states and two different proposed continuations of history. Each block may contain a different transaction set or a different ordering of overlapping transactions, so the resulting states can diverge.
Because messages propagate with delay, some nodes will see one child block first and tentatively build on it, while others will see the other child first. For a while, both branches are locally consistent histories from the perspective of the nodes following them. These are temporary histories: each is valid under the rules, but only one will survive as the canonical chain once further blocks are added and consensus rules cause convergence.
Pro Tip:Consider two nodes in different data centers that both track the same blockchain. A new block A arrives first at node 1, while a competing block B on the same parent arrives first at node 2. Each node extends the block it saw first and briefly believes a different sequence of blocks is “the chain.” Only after more blocks are produced and propagated do both nodes switch to the same branch, revealing that their earlier views of history were temporary and local.
8. Why Blocks Can Be Discarded
When a branch with more support under the consensus rules overtakes another, nodes perform a reorganization: they detach blocks from the losing branch and attach blocks from the winning one. The detached blocks are discarded from the canonical chain, even though they may have been considered part of history a short time earlier.
Discarding blocks is not an accident; it is how the protocol corrects earlier tentative choices once better information is available. Transactions from discarded blocks are not automatically lost: if they are still valid against the new canonical state and still of interest, they can be reintroduced into the transaction pool and included in later blocks. The key point is that block inclusion is conditional on the surrounding branch remaining preferred.
- Detect that an alternative branch has become preferable under the consensus rules, for example by having more accumulated weight or length.
- Identify the common ancestor block between the current branch and the new preferred branch.
- Roll back local state by undoing the effects of blocks above the common ancestor on the old branch, effectively discarding those blocks from the canonical view.
- Apply the blocks from the new branch in order from the common ancestor, recomputing the state transitions to reach the new canonical state.
- Optionally return transactions from discarded blocks that are still valid and not present on the new branch back to the mempool for possible future inclusion.
9. Where Blocks Fit in the Transaction Lifecycle
A transaction’s lifecycle starts when a user signs it and sends it to at least one node, which then gossips it through the network. Before it reaches any block, it typically lives in each node’s mempool, a local set of pending transactions waiting to be ordered.
At some point, a block producer selects the transaction from its mempool, assigns it a position in a new block, and broadcasts that block. This is the first moment the transaction has a proposed global ordering relative to others. However, that ordering is still tentative: the block can be replaced by a competing one that omits or reorders the transaction. Only after the transaction appears in a block that is buried under additional blocks, and the risk of reorganization becomes negligible under the consensus model, does its position in history become stable.
- Transaction is created, signed, and broadcast, then stored in nodes’ mempools as an unordered candidate for future inclusion.
- A producer includes the transaction in a block, giving it a first proposed ordering relative to other transactions in that block and its ancestors.
- If a reorg discards that block, the transaction may return to mempools and later be included in a different block at a different position in the history.
- As more blocks are built on top of the block containing the transaction, its ordering becomes increasingly stable, and the probability of reorg removing it decreases.
- Beyond some depth, depending on the consensus and risk tolerance, the transaction’s inclusion is treated as effectively permanent, even though absolute irreversibility may remain a theoretical edge case.
What Blocks Guarantee vs What They Do Not
Blocks provide some strong guarantees and leave other properties explicitly outside their scope. At the proposal level, a valid block guarantees a specific deterministic state transition if it is applied on top of its parent’s state.
What a block does not guarantee by itself is that this transition will become part of the long-term canonical history. The level of assurance associated with a block depends on how many later blocks build on it and how the consensus protocol treats depth and alternative branches.
Key facts
Ordered execution inside a block
Guaranteed by protocol rules: if the block is valid, all honest nodes execute its transactions in the same specified order and obtain the same result.
Deterministic candidate next state
Guaranteed: given the parent state and a valid block, the resulting state transition is uniquely determined by the protocol.
Immediate, irreversible finality
Not guaranteed: a freshly produced block can be replaced by another branch; irreversibility, if provided, comes from additional consensus mechanisms and depth.
Permanent transaction inclusion at first appearance
Not guaranteed: transactions from a block near the tip may disappear in a reorg and later be re-included in a different block.
Global agreement on the latest block
Not guaranteed at all times: during propagation and competition, different nodes can temporarily accept different tips as their current best view.
Long-term stability of deep blocks
Heuristically expected: blocks buried under many successors are increasingly unlikely to be reverted, but the exact risk level depends on the consensus and threat model.
Clearing Up Block Misconceptions
Many misconceptions about blockchains come from treating blocks as immutable storage units of truth rather than as tentative proposals for how history and state should evolve. This leads to assumptions that any block ever seen is permanent and that the latest block is automatically safe to base irreversible actions on.
In reality, blocks near the chain tip are deliberately provisional, and the protocol expects nodes to handle their replacement when a better-supported ordering appears. A correct mental model distinguishes between the mechanical guarantees inside a valid block and the separate, probabilistic process by which blocks become part of stable history.
- A block is not permanent history; it is a proposal that may or may not remain in the canonical chain.
- Block inclusion is not finality; it only means a transaction has been given a tentative ordering in one candidate history.
- The chain tip is not globally agreed truth; it is each node’s current best guess based on the blocks it has seen so far.
- A block is not just a container of data; it encodes an ordered state transition from one snapshot of the ledger to another.
- Consensus is not the act of producing a single block; it is the ongoing process by which the network converges on one branch among many possible proposals.
10. The Block Mental Model
A useful way to think about a block is as a signed, verifiable suggestion for the next step the ledger could take, not as the ledger itself. It ties a specific parent history to an ordered list of transactions and a resulting candidate state.
Whether that suggestion becomes part of long-term history depends on how the consensus mechanism compares it to competing suggestions over time. Blocks are therefore temporary by design near the tip, even though deeply buried blocks can be treated as effectively permanent in practice.
- A block is a proposal: it links to a parent and specifies an ordered batch of transactions plus a candidate next state.
- Inside a valid block, execution is deterministic: all honest nodes that accept the parent will compute the same resulting state.
- Recent blocks are intentionally replaceable so the protocol can resolve timing races and competing histories safely.
- Deep blocks are stable because replacing them would require violating the assumptions of the consensus model, not because blocks themselves are intrinsically immutable.