中文版 · Blockchain learning guide · Previous: Nodes, Clients and Peer Networks
Blockchain learning · Article BC008
A transaction requests a change. A block organises protocol-defined information, including an ordered set of transactions in many blockchains. State is the current result maintained after the relevant rules have been applied.
The distinction is easiest to see in an ordinary register. “Reserve three kits” is an instruction. A recorded sequence of accepted instructions is history. “Two kits remain available” is part of the resulting state. Confusing these layers makes it easy to mistake a submitted request for a completed change or a historical record for a current entitlement.
This guide develops a small worked example you can calculate by hand. It explains the reasoning without pretending that every blockchain uses the same transaction format, data structure or confirmation rule.
Choose your reading route
In this guide
- 1. State answers “what is true inside the system now?”
- 2. Define the rules before processing instructions
- 3. Apply three requests, one at a time
- 4. The same requests can produce a different result in another order
- 5. A transaction is an instruction, not a promise of success
- 6. Blocks organise a shared sequence
- 7. History can be replayed only with the right starting point and rules
- 8. A state commitment is not the state written out in full
- 9. Account state and unspent outputs describe value differently
- 10. Current state and historical evidence support different questions
- 11. Corrections should not be confused with erasing history
- 12. A block’s presence is not a universal finality guarantee
- 13. Replay exercise: calculate before checking the answer
- Common mistakes to avoid
- Frequently asked questions
- Sources and scope
- Build the basic picture: start with the five-kit example and its update rules.
- Understand why order matters: compare the two competing reservation sequences.
- Connect the example to blockchains: read blocks, state commitments and account/UTXO models.
- Practise: complete the replay exercise before reading its answers.
Back to contents · Next section
1. State answers “what is true inside the system now?”
Suppose a teaching laboratory has five identical demonstration kits available for reservation. Its software records available kits and reservations held by each group.
At the start, the state is: five available, none reserved by Group A and none reserved by Group B. This is a deliberately small teaching model, not a live inventory system.
The state is not the entire story of how the laboratory arrived there. Two systems can display five available kits after very different histories: perhaps nobody booked anything, or perhaps several bookings were made and later released.
History answers what was recorded over time. State answers the current result under the model’s rules. Both can be useful, but they answer different questions.
Also notice the boundary: the software’s state says five kits are recorded as available. It does not prove that five intact kits are physically on the shelf. An inspection or accountable inventory process is still required for that external claim.
Back to contents · Next section
2. Define the rules before processing instructions
Our toy system has a fixed total of five kits and two actions: reserve and release. It uses whole positive quantities only.
A reserve request succeeds only when the group is authorised and enough kits remain available. A successful request reduces the available quantity and increases that group’s reserved quantity by the same amount.
A release request succeeds only when the group is authorised and has reserved at least the quantity being released. A successful release reduces its reservation and increases availability by the same amount.
For this exercise, each instruction has a unique identifier and cannot be applied twice. We ignore fees, physical loss, administrator stock adjustments and every other production concern. Those exclusions keep the arithmetic clear; they are not recommendations for a real deployment.
The model also has an invariant: available kits plus all reserved kits must equal five, and no quantity may be negative. An invariant is a condition the permitted transitions are meant to preserve.
This small rulebook is more informative than simply saying the system is “secure.” It lets a learner decide whether a proposed change is allowed.
Back to contents · Next section
3. Apply three requests, one at a time
Request A1: Group A reserves three kits. Five are available, so the request succeeds. The new state is two available, three reserved by A and zero by B.
Request B1: Group B reserves three kits. Only two are available. Under our rule, this request fails. The reservation state stays at two available, three for A and zero for B.
Request A2: Group A releases one kit. A has three reserved, so releasing one is allowed. The new state is three available, two for A and zero for B.
Now check the invariant: three plus two plus zero equals five. The state remains valid under the toy rules.
The failed B1 request is still useful information for the person who submitted it, but it did not create a reservation. A system might retain a failed-request log separately. Our example does not dictate how a particular blockchain records failures.
The important reasoning pattern is consistent: begin with the previous state, check the instruction, apply the permitted change and inspect the resulting state.
Back to contents · Next section
4. The same requests can produce a different result in another order
Return to the original state with five available kits. This time process B1 before A1.
B1 reserves three for B, leaving two available. A1 then cannot reserve three for A. The result differs from the earlier sequence, even though the requests themselves have not changed.
This is why ordering matters for shared state. Valid authorisation gives a group permission to request an action; it does not guarantee that the necessary resource will still be available when the action is evaluated.
Some operations can be reordered without changing the result. Others cannot. A system designer must understand which case applies rather than assuming every update is independent.
Ordering also raises a separate fairness question. The fact that a protocol consistently selects an order does not prove that the order matches the application’s preferred allocation policy. “Everyone agrees on the result” and “the allocation is fair” are different claims.
The example is about scarce-resource coordination, not a recommendation to tokenise laboratory equipment.
Back to contents · Next section
5. A transaction is an instruction, not a promise of success
A blockchain transaction can request a transfer, contract execution or another protocol-defined action. The exact fields and authorisation method depend on the network.
A useful conceptual description includes who is authorising the action, what operation is requested, which data it uses and what prevents inappropriate reuse. Real transaction formats add their own network-specific details.
A signature does not guarantee that the operation succeeds. The requested change may be invalid against the state at execution time, or execution may encounter a condition that causes it to fail under the platform’s rules.
Nor is every failure identical. A malformed or unauthorised request can be rejected before inclusion. In some platforms, a validly included transaction can execute and revert. That distinction matters because the protocol can still record execution status and charge for consumed resources.
Ethereum’s transaction documentation provides one concrete model. Do not assume that its failure handling or fields apply unchanged to every chain.
Back to contents · Next section
6. Blocks organise a shared sequence
In many blockchains, transactions are grouped into blocks. The block’s structure identifies or commits to the relevant contents and links to a predecessor according to the protocol.
A block is not merely a page with arbitrary text pasted onto it. It has a defined format, and validating participants check applicable rules. The order of transactions within a block can affect the resulting state, just as order affected the kit reservations.
Imagine a toy block containing the successful instruction A1 followed by A2. Starting from the initial state, applying those instructions gives three available kits and two reserved by A. A verifier can repeat the calculation from the same starting point.
This grouping does not make the instructions truthful about the physical world. It organises agreed changes to the recorded model. It also does not mean that every node immediately sees or accepts a proposed block.
Ethereum’s blocks documentation explains its own batching and data structures. The terminology is useful, but a specific block’s fields must be interpreted in its network and protocol version.
Back to contents · Next section
7. History can be replayed only with the right starting point and rules
To reproduce a state, a verifier needs more than a list of operation names. It needs an appropriate starting state, the applicable rules and the relevant ordered inputs.
If one reader starts with five kits and another starts with six, the same reservation sequence will produce different availability. If one implementation allows releasing kits that were never reserved while another rejects it, they are not following the same rulebook.
Versions also matter. Suppose a later rule permits an administrator to add stock. Replaying later updates with the old two-action model is no longer sufficient. The verifier needs to know which rules applied at each relevant point.
This is why “the data is public” does not automatically mean “any conclusion shown by a website is independently verified.” A reader needs enough context and a correct verification method.
The toy example makes that requirement visible without requiring a full protocol implementation. Agreement about bytes and agreement about their meaning are connected through rules.
Back to contents · Next section
8. A state commitment is not the state written out in full
A system can use a cryptographic commitment, such as a root hash, to represent a larger structured dataset. This can support checking that data or a proof corresponds to the committed structure.
The commitment is not a human-readable inventory report, and it is not a compressed backup from which the entire dataset can simply be recovered. The underlying data and the appropriate verification procedure still matter.
Also ask which state is being committed to. A multi-component protocol can contain different state objects and commitments. A consensus-layer state and an application’s displayed balance are not interchangeable merely because both are called state.
For the kit model, writing down a fingerprint of the complete state would not tell a reader how many kits A holds. The reader would need the state data, or an appropriate proof about a specified part, to check that claim.
A valid proof of one statement should not be expanded into a guarantee that every external assertion is true or that every historical file remains available.
Back to contents · Next section
9. Account state and unspent outputs describe value differently
An account-based model maintains information associated with accounts, such as balances and other state. A transaction can update those values according to the rules. Ethereum is a prominent example.
Bitcoin uses unspent transaction outputs, often abbreviated UTXOs. A transaction consumes eligible outputs and creates new outputs under spending conditions. A wallet’s displayed balance can be derived from the outputs it can spend.
Both models can describe valid changes, but their representations differ. It is misleading to assume every blockchain simply edits a bank-like balance column, or that every transaction consumes the same kind of object.
For this introductory lesson, the important point is that state has a model. You cannot correctly interpret a transfer merely by recognising the word “transaction.” The meaning depends on what the system stores and how its rules change it.
See Bitcoin’s transaction guide and Ethereum’s account documentation for the respective starting points. Neither model alone determines a system’s privacy or degree of decentralisation.
Back to contents · Next section
10. Current state and historical evidence support different questions
A reader asking “how many kits are available now?” usually needs current state. A reader asking “why did Group B’s request fail?” needs the relevant prior state, request order and rules.
A current total may hide an important sequence. If a reservation was created and later released, the current availability can match the starting value even though meaningful events occurred in between.
Conversely, a long transaction list can be difficult to interpret without computing its effect. A website may present a simplified result, but the underlying calculation should be distinguished from the raw history.
This distinction also explains why different node configurations support different queries. Retaining or reconstructing historical state can be a separate capability from tracking the current network state. The appropriate data source depends on the question.
Before accepting a screenshot as evidence, ask which time, state and interpretation it represents. “The latest balance” and “the balance before a disputed action” are not the same observation.
Back to contents · Next section
11. Corrections should not be confused with erasing history
Suppose Group A reserved three kits accidentally and should have reserved two. In our toy model, the authorised release of one kit can correct the current reservation while preserving the earlier request in the history.
That is different from silently editing the old request to say two. The first approach explains a sequence of actions; the second changes the historical account presented to a reader.
A real application needs to specify who can correct what, how reasons are recorded and what information should be retained. Keeping every mistake forever is not automatically desirable, particularly when personal information is involved.
The broader lesson is that an append-oriented history does not prevent all forms of correction. It changes how a correction is represented and who must authorise it.
Do not confuse this application-level correction with a chain reorganisation. A reorganisation changes which branch is locally accepted under the network’s fork-choice rules; a new corrective transaction is a different mechanism.
Back to contents · Next section
12. A block’s presence is not a universal finality guarantee
A transaction appearing in a block establishes a different fact from the transaction merely being submitted. But inclusion does not have the same finality meaning in every protocol.
A node may change its view of recent accepted history according to the protocol’s rules. Applications therefore need to interpret confirmations and finality using the actual network’s conditions, not a universal slogan such as “one block means permanent.”
This also affects state. A displayed current result is tied to the history the application is using. If that history changes, the derived result may change too.
The right response is not to conclude that records are useless. It is to state which stage has been reached and what assumptions support relying on it. Submission, inclusion, execution success and finality should remain separate labels.
A production system must decide what evidence is sufficient for its own consequences. This guide supplies concepts, not a settlement policy for financial or legal decisions.
Back to contents · Next section
13. Replay exercise: calculate before checking the answer
Start again with five available kits and no reservations. Use the same rules: positive whole quantities, authorised groups, enough available kits for reservations, enough held kits for releases, and no repeated instruction identifiers.
Process this sequence:
- A reserves two kits using instruction X1.
- B reserves two kits using instruction X2.
- A requests to release three kits using instruction X3.
- B releases one kit using instruction X4.
- The system receives X1 again, with the same identifier and contents.
For each step, record whether it succeeds and the resulting available, A-reserved and B-reserved quantities. Do not merely add and subtract every number; apply the rules first.
Worked answers
After X1 succeeds: three available, two for A, zero for B.
After X2 succeeds: one available, two for A, two for B.
X3 fails because A has only two reserved and cannot release three. The state remains one, two and two.
After X4 succeeds: two available, two for A, one for B.
The repeated X1 is not applied again under the exercise’s unique-identifier rule. The final state remains two available, two for A and one for B. The invariant holds: two plus two plus one equals five.
This is a teaching model of rule application and duplicate handling. Actual networks use their own transaction identifiers, counters, spending conditions and replay protections.
Back to contents · Next section
Common mistakes to avoid
Treating a request as a result. “Reserve three” is not evidence that three were reserved.
Ignoring the starting state. The same instruction can succeed or fail depending on the resources and permissions available when evaluated.
Ignoring order. Competing requests can produce different outcomes when reordered.
Equating a hash with a backup. A commitment supports checking; it does not automatically supply missing data.
Assuming every failed action disappears without cost. Protocols differ, and included execution can fail while still consuming resources.
Treating current state as the whole history. Two identical current totals may result from very different sequences.
Back to contents · Next section
Frequently asked questions
Is a transaction always a payment?
No. It can request many kinds of protocol-defined change, including an application action or a recorded statement. Its meaning depends on the system.
Does a block contain the entire world state?
Not necessarily. Block structures differ and can contain commitments to state rather than listing all state data directly. Interpret the actual fields in the relevant protocol.
Can two people compute different states from the same history?
They can if their starting states, rules, inputs or implementations differ. Correct verification requires the appropriate shared context, not just the same visible transaction names.
What is the next useful concept?
Study which participants are allowed to read, submit, validate and change rules. Those permissions explain how different blockchain architectures organise the state-transition process.
Back to contents · Next section
Sources and scope
The foundational research reference was dated 12 October 2026, Asia/Singapore. Primary documentation was checked during this article’s preparation. The five-kit system is an original hypothetical exercise, not a production design or a claim about a deployed service.
- Ethereum: Transactions: one transaction model and lifecycle.
- Ethereum: Blocks: ordered batches and protocol-defined block structures.
- Ethereum: Accounts: account-based state concepts.
- Bitcoin Developer Guide: Transactions: unspent outputs, spending conditions and new outputs.
- Ethereum: Gas and fees: resource consumption and fees, including failed execution.
A useful mental model is: begin with state, apply an authorised instruction under the rules, then check the new state. A blockchain adds a shared, verifiable history around that process.