From Proposals to Ordered History
In the previous step, we focused on transactions as signed proposals to change who owns what. Many different participants can create transactions at the same time, and those proposals circulate through the network independently.
A proposal, however, is not the same as acceptance. When many transactions are announced concurrently, the system still needs a way to decide which proposals are applied next and in what order.
A block is the mechanism that performs this step. It turns many independent transaction proposals into one ordered update everyone can share.
Core Definition: An Ordered Update
At a system level, a block is how a blockchain turns many independent transaction proposals into one ordered update to history.
A block is not just a batch of data. It is a specific choice of which transactions are accepted next and the exact order in which they are applied. That ordering matters whenever transactions interact or compete for the same resources.
Once a block is accepted by the network, it becomes a reference point. Everyone can talk about the state after this block and know they mean the same ordered set of changes.
How Blocks Turn Proposals into Shared History
At any moment, a blockchain network contains many outstanding transaction proposals. Different nodes may hear about them in different orders or at different times.
A block producer selects a subset of these proposals and arranges them into a specific sequence. This ordered list is presented as a candidate block — a suggestion for what the next step of shared history should look like.
Other participants independently verify this candidate against the shared rules. If it is accepted, the ordered transactions inside the block become the next agreed update to history.
Once attached, the block extends the existing chain. From that point on, everyone can reference balances or effects after this block and be referring to the same ordered outcome.
Why Blocks Exist
Transactions alone do not automatically line up into a single sequence. They are created by many people, in many places, and reach different nodes at different times.
Without blocks, different participants could apply transactions in different orders and end up with different results. If order differs, two transactions could compete for the same funds, and nodes would disagree on which one happened first. Blocks solve this by fixing both which transactions happened and in what order for each step of history.
When a block is accepted, it defines a common chapter that all nodes can align on, even if their local views of incoming transactions originally differed.
Over time, these chapters form one global sequence that everyone can reference: block after block, step by step.
The Block Boundary: From Proposal to Commitment
A transaction by itself is only a request to change the shared record. It becomes part of the system’s current story only when it appears inside an accepted block.
The important boundary to remember is block inclusion. Before inclusion, a transaction is still a proposal. At the moment it is included in an accepted block, the system treats it as committed for that step in history.
Not every proposal crosses this boundary. Some transactions may be delayed, replaced, or never included at all. Blocks are where the system makes a choice about which proposals count next.
One Block vs the Whole Chain
A single block is one ordered update — like a chapter in a book. It records which transactions were accepted at that step and in what order.
The blockchain is the entire sequence of these updates linked together over time. Each new block builds on the one before it, so the meaning of later transactions depends on everything that happened earlier.
Because blocks depend on previous blocks, changing an earlier block would affect all later ones. This dependency is what turns many individual updates into one continuous shared history.
As more blocks are added after a given block, the ordering recorded in that earlier block becomes increasingly stable in practice.
Common Misconceptions About Blocks
- A block is just a batch of transactions — Not quite. A block also fixes the order of those transactions and connects them to prior history.
- Once in a block, a transaction is final — Not exactly. Block inclusion is an important milestone, but stability increases as more blocks are added later.
- Blocks appear instantly and globally — Not quite. A block is proposed in one place and then propagates through the network.
- Blocks are created by 'the network' — Not exactly. A specific participant proposes a block, and others independently verify it.
- The block is the blockchain — Not quite. A block is one step; the blockchain is the full sequence of many blocks over time.
What a Block Guarantees — and What It Doesn't
Key facts
Inside-block ordering
Guaranteed. Once a block is accepted, the relative order of transactions inside that block is fixed for that version of history.
Reference point
Guaranteed. An accepted block gives everyone a common after this block state to refer to.
Instant permanence
Not guaranteed. Recent blocks can sometimes be replaced by alternative blocks.
Immediate inclusion
Not guaranteed. Valid transactions may wait across multiple blocks or never be included.
Fair ordering
Not guaranteed. Ordering can be influenced by incentives and network conditions.
Pro Tip:Blocks give ordered placement in history. Confirmations and finality explain when that placement becomes practically unchangeable.
The Mental Model
- Transactions are signed proposals.
- A block chooses and orders some proposals.
- An accepted block becomes the next shared update.
- The blockchain is the chain of these updates over time.
- Later blocks make earlier ordering more stable.
In simple terms: a block is how a blockchain takes many transaction proposals, selects some of them, locks in their order, and moves shared history forward one step.
What Comes Next: Confirmations & Finality
Blocks explain how proposals become ordered updates. The next question is how stable that ordering is over time. Confirmations and finality explain when an ordered history becomes effectively permanent.