中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC055
The difference between a full node, a light client and a provider-trusting application is not simply how many bytes they store. It is which rules they check themselves, which evidence they obtain and which assumptions remain outside their checks.
A client can correctly verify that a transaction belongs under a particular block root without independently validating every transaction in that block. A node can validate a history and later discard some raw files. An application can receive a correct answer from a provider while doing no local verification of the chain claim.
This lesson compares those responsibilities using one fictional UTXO-style chain. It contains no wallet setup, payment recommendation or live node operation. The goal is to describe a verification boundary precisely enough that another reader can understand what has, and has not, been established.
Choose your reading route
In this guide
- 1. One sentence can hide three different claims
- 2. The fictional chain and its three observers
- 3. Follow the supplied valid history
- 4. What each observer can actually say
- 5. A correct branch beneath an unaccepted header
- 6. Another transaction can invalidate the whole block
- 7. Historical inclusion does not prove current unspent status
- 8. Pruning and validation are different axes
- 9. Light-client capability is protocol-specific
- 10. Build a verification-responsibility matrix
- 11. Exercises and answers
- 12. Frequently asked questions
- Sources and next reading
Sections 1–3 define three observers and their evidence. Sections 4–7 test a membership proof, an invalid block and a later spend. Sections 8–10 separate validation from archival service and explain protocol-specific limits. The final exercises check whether you can assign the right claim to the right evidence.
The Bitcoin paper’s simplified payment verification section is an important historical reference for checking transaction membership through block headers. It also explains why that approach has different assumptions from checking the transaction history directly. We use the distinction as a starting point, not as a current software configuration guide. Bitcoin paper, section 8
Back to contents · Next section
1. One sentence can hide three different claims
Suppose an application says, “Transaction T is verified.” That could mean that T’s identifier was found on a website, that its membership proof matches a root, that a node validated the containing block, or that some later condition has been checked.
For our worksheet, split the sentence into three precise claims:
- Membership: T is included in identified block B100.
- Validity: B100 satisfies all the toy chain’s relevant transition rules from the accepted prior state.
- Current state: output t0 created by T is still unspent at identified block B102.
The claims are related but not interchangeable. Membership is about a record’s position in a committed collection. Block validity requires the applicable rules and preceding state. Current unspent status requires considering what happened after the output was created.
An answer should name the claim before naming the client. Otherwise a light client can be criticised for failing a job it never promised, or credited with a job it did not perform. The same problem appears when “full” is mistaken for “able to answer every historical query instantly”.
Back to contents · Next section
2. The fictional chain and its three observers
All observers know the intended network. The toy begins at an explicitly trusted starting state S0 with correct rule configuration. We do not ask them to establish S0’s historical validity; that trust is visible in the model.
Observer F obtains the complete relevant blocks after S0. It checks their header requirements, all applicable transaction and state-transition rules, and the selected-chain rules. For this exercise, no relevant transition check is skipped. This is an idealised full-validation responsibility, not a claim about every default optimisation in a real client.
Observer L is a specified Bitcoin-style header-and-membership client. It checks its header chain from the supplied anchor, including linkage and the specified proof-of-work and header-selection conditions. It obtains T and a membership branch to B100’s root. It does not download and validate every block transaction or maintain the complete current UTXO state.
Observer R requests an answer from a remote service and accepts the response without locally checking header or membership evidence. The provider may be honest and competent. The point is that R delegates the chain claim rather than verifying it itself.
Assume the observers’ stated algorithms are implemented correctly. Connectivity, access to relevant evidence and the chain’s security assumptions remain explicit dependencies. None of the three labels makes those dependencies disappear.
Back to contents · Next section
3. Follow the supplied valid history
In the main history, S0 contains an unspent input u0 worth eight invented units. In B100, valid transaction T spends u0, creates output t0 worth seven and leaves one unit as the input-output fee difference. All other transactions in this main-history block are valid.
In B101, valid transaction V spends t0, creates output v0 worth six and leaves a one-unit fee difference. B102 is a valid descendant of B101. No later transaction restores the exact outpoint t0 to the unspent set; a new output with the same amount would have a different identity.
F validates these transitions and maintains the resulting state. L is supplied with the appropriate accepted header context and a correct membership branch for T in B100. R receives a provider report saying that T was included in B100 and t0 is spent by B102.
Three useful observations follow. F has locally checked the relevant validity and state transitions under the model. L has checked the supplied membership relationship in its accepted header context. R has a report whose truth it is relying on the provider to establish.
The values are intentionally small so the boundary is visible. Seven plus one accounts for the first input; six plus one accounts for the second. Arithmetic is part of the supplied validity story, but it does not replace the other required rules or authorization checks.
Back to contents · Next section
4. What each observer can actually say
F can say: “Under the trusted S0 and stated rules, I validated the relevant history through B102. T is in B100, and t0 has been spent in B101.” This statement names both the validation work and its starting assumption.
L can say: “The supplied T and branch match the transaction root of B100 in the header chain I accept under my specified checks and assumptions.” It cannot add “I independently checked every transaction in B100” because it did not perform that work.
R can say: “My provider reports that T was included and t0 is now spent.” If R presents the result without that qualification, it can conceal where verification responsibility sits. A correct answer does not retroactively mean that the receiving application checked it.
The Bitcoin developer guide’s operating-modes discussion distinguishes full validation from SPV membership checking and explicitly notes that transaction membership does not by itself guarantee transaction validity. That narrow distinction supports the comparison here. Bitcoin operating modes
These are capability descriptions, not a universal product ranking. A particular task may need a small authenticated claim, extensive local validation or a historical data service. Define the task before evaluating whether the chosen mode is sufficient.
Back to contents · Next section
5. A correct branch beneath an unaccepted header
The next card is separate from the main history. A stranger supplies a header Z, transaction T and a branch that correctly recomputes Z’s transaction root. No evidence connects Z to L’s accepted header chain or trusted starting point.
L can establish the mathematical relationship between T, the branch and that root. It cannot establish that Z belongs to the intended accepted chain merely because the branch matches. The missing evidence concerns the header’s authority and context, not the branch arithmetic.
Adding a longer filename, a familiar logo or the word “verified” to the packet does not supply the missing connection. Nor does receiving the same packet from two websites necessarily provide independent header verification.
The right worksheet answer is therefore split: membership relative to supplied Z passes; membership in the intended accepted history is not established. A binary “proof valid” label would hide this difference.
This is why a verification interface should expose which root or header it checked against and how that reference was accepted. A compact proof saves work only if its starting reference has the meaning the application requires.
Back to contents · Next section
6. Another transaction can invalidate the whole block
Now consider a different candidate block K100. It contains T followed by another transaction U that attempts to spend the same input u0 again. All necessary facts are supplied: T already consumes u0, and U violates the toy’s no-double-spend rule. K100’s header passes the specified header-level checks, and T has a correct membership branch to its root.
F rejects K100 as invalid. The correct membership of T does not repair U. Greater header work would not make that invalid transition acceptable under F’s rules.
L’s limited membership check for T still matches the supplied root. Because this version of L does not validate all transactions, that check alone does not detect the invalid U. This illustrates a missing validation responsibility, not a practical instruction for constructing an attack.
An L-style security argument therefore relies on additional assumptions about the accepted header chain and the system supporting it. Those assumptions must not be relabelled as local execution of every transition. The Bitcoin paper itself discusses limitations of simplified verification under adverse conditions. Bitcoin paper, section 8
R may report whatever its provider concludes. If the provider fully validates and rejects K100, R can benefit from that work while still relying on the provider’s report. Delegation and local verification remain different descriptions of responsibility.
Back to contents · Next section
7. Historical inclusion does not prove current unspent status
Return to the valid main history. T belongs to B100, but V spends t0 in B101. At B102, the statement “t0 was created in B100” is true, while “t0 is still unspent” is false.
L’s proof for T does not contain the later state information needed to answer the second question. Rechecking the same proof more carefully cannot reveal a spend that lies outside the proof’s claim.
F can answer the current-state question because the exercise gives it the complete relevant validated transitions through B102. R can obtain a provider answer but must account for its dependence on that provider. An expanded light-client protocol might support additional authenticated state claims, but that is a different capability from the simple L defined here.
Do not infer “unspent” from failing to receive a later spend record. Missing data and verified absence are different. The operating-modes guide discusses omission as a potential issue for simplified clients, which reinforces the need to name the evidence actually obtained. Bitcoin operating modes
The lesson generalises to many record systems: proving that an event occurred is not the same as proving that no relevant event occurred afterwards. The second task needs a defined state or coverage argument.
Back to contents · Next section
8. Pruning and validation are different axes
After validating the main history, suppose F retains its required current state and metadata but no longer stores the old raw block B100. In this card, its prior validation is a supplied fact; no disk corruption or loss of required current state is introduced.
F has not become a header-only client merely because an old raw file is gone. The distinction concerns what F checked while processing the history. However, F may now be unable to serve B100’s raw bytes or produce a requested historical proof from local storage alone.
Bitcoin Core’s historical 0.11.0 release notes introduced block-file pruning while retaining full-validation operation. They distinguish processed databases from raw block and undo files. We use that historical explanation for the conceptual separation, not its old configuration restrictions or storage figures as current advice. Bitcoin Core 0.11.0 pruning notes
Now imagine an archive service that stores every block but gives R answers that R never checks. Extensive server storage does not transform R into a locally validating client. Storage quantity, validation responsibility and proof-serving capability need separate columns.
This three-column view avoids two errors: assuming less retained history necessarily means weaker past validation, and assuming more retained history automatically means stronger verification by the user receiving an answer.
Back to contents · Next section
9. Light-client capability is protocol-specific
The L in this exercise is deliberately narrow. It should not be used as a universal definition of every product called a light client. Different protocols authenticate headers differently and can support different data proofs, update procedures and bootstrap assumptions.
Ethereum’s light-client documentation distinguishes execution and consensus responsibilities and notes that the scope of a light execution client can vary. The relevant question is therefore what a particular implementation checks, not whether its name contains “light”. Ethereum light clients
For any real design, identify the trusted starting information, how new authenticated references are accepted, which proof types are checked, which state transitions are not checked and what data must remain obtainable. A claim about one chain’s client should not silently become a claim about another chain.
Similarly, an authenticated response may still be too old for the intended task. Correct proof verification at one identified state does not establish that this is the state the application should currently use. Freshness and chain selection remain part of the full claim.
The worksheet deliberately avoids current product recommendations, hardware estimates and universal confirmation counts. Those would require different evidence and would distract from the durable responsibility question.
Back to contents · Next section
10. Build a verification-responsibility matrix
For each observer, record five things in plain language: data received, checks performed, trusted starting information, unverified assumptions and data-service limitations.
For F, the data are complete relevant blocks and prior state; the checks include all specified transitions; S0 remains the supplied anchor. For L, the data are accepted headers plus selected transaction evidence; the checks do not include all block transactions or a complete current UTXO reconstruction. For R, the answer is a provider report and the chain claim is delegated.
Add a sixth line for the exact output claim. “T belongs under this root” is narrower than “T is in my accepted chain”, and both are different from “t0 is unspent at B102”. The matrix is useful only if those outputs remain distinct.
Finally, ask what happens when evidence is missing. A proof server outage may prevent a light client from obtaining a result without causing it to accept a false result. A pruned node may know its current validated state while lacking an old block file. A provider response can be unavailable even while the chain progresses.
These are different failure modes. Naming them helps the reader avoid treating every unavailable answer as a consensus failure or every returned answer as independently verified truth.
Back to contents · Next section
11. Exercises and answers
Question 1. A branch correctly links T to Z’s root, but Z has no established connection to the accepted chain. What passes and what remains unproved?
Answer. The membership relationship relative to Z passes. Inclusion in the intended accepted history remains unestablished.
Question 2. K100 contains valid T and invalid double-spend U. Can a correct T membership proof make K100 valid?
Answer. No. F rejects the invalid block. L’s limited check does not validate U or the whole block.
Question 3. T creates t0 worth seven in B100; V spends it in B101. Is t0 unspent at B102?
Answer. No. Historical creation remains true, but current unspent status is false in the supplied history.
Question 4. F deletes old raw B100 after validation while retaining required current state. Has it necessarily become an SPV client?
Answer. No. Pruning retained files is different from skipping validation. Its ability to serve old bytes may nevertheless be reduced.
Question 5. R’s provider gives a correct answer. Did R independently validate the chain claim?
Answer. No. Correctness of the report and the recipient’s verification work are different facts.
Question 6. Can an unavailable proof be treated as proof that T is absent?
Answer. No. Failure to obtain evidence does not establish the opposite claim.
Back to contents · Next section
12. Frequently asked questions
Does full validation remove every assumption?
No. Correct software, rule configuration, the starting state and relevant network evidence still matter. The worksheet makes S0 explicit rather than hiding it.
Is every small client merely trusting an RPC server?
No. Some clients locally verify authenticated evidence. Identify the checks actually performed.
Does a proof of inclusion prove real-world truth?
No. It concerns the authenticated record. Whether an off-chain statement is true requires evidence appropriate to that statement.
Is an archive node always required to validate new blocks?
Do not equate retention with validation. The required current state and validation data differ from the ability to serve every historical record on demand.
Back to contents · Next section
Sources and next reading
Primary materials checked on 12 October 2026:
- Bitcoin white paper, especially section 8 on simplified payment verification; historical 2008 design discussion.
- Bitcoin developer guide: Operating modes, used for the narrow full-validation and SPV distinction.
- Bitcoin Core 0.11.0 release notes, historical pruning rationale only.
- Ethereum light clients, page updated 25 February 2026, used only for protocol-specific scope variation.
The observer definitions, invented units and candidate-block cards are original teaching models. They do not specify a production client’s default configuration or offer operational instructions.