VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

How to Learn Blockchain Technology | Build a Learning Portfolio from the Article Library

Three learners review open books together at a classroom table, with stacks of textbooks, stationery and a whiteboard in the bright room.

Build a blockchain learning portfolio from work you can explain, check and improve. The published article library supplies technical routes and complete teaching cases; your portfolio supplies evidence of what you did with them. It should help you find a missing connection and choose the next task, rather than hide uncertainty behind a long reading list.

This guide connects all ten modules of the Master Blockchain library with the learning series. You will organise five types of output, mark an original sample learner portfolio with a transparent rubric, repair its weak entries and plan a fresh assessment. Each English guide has a full Simplified Chinese sibling so you can keep technical meaning stable while explaining it in either language.

The portfolio and rubric are original educational tools. They do not award a qualification, certify production engineering competence or establish legal or financial expertise. Use synthetic examples and the published paper exercises. No live keys, transactions, personal records or deployments are needed for this guide.

The featured photograph illustrates study, not a verified blockchain class.

Find your next learning step

How to Learn Blockchain Technology · Guide 14

Choose the question · Define the objects · Work the case · Check and vary · Test transfer

Chapter index · Complete learning route

Contents

Chapters 1–5

1. Decide what your portfolio should demonstrate

2. Use the article library as a map rather than a memory test

3. Keep five output types distinct

4. Make a ten-module route card

5. Connect the learning guides to your outputs

Chapters 6–10

6. Write a first-principles explanation entry

7. Write a rule-trace entry with complete premises

8. Write an evidence-map entry

9. Write a changed-fact decision entry

10. Keep a repair log that names the error

Chapters 11–15

11. Mark the original sample portfolio with four criteria

12. Read the four complete sample entries

13. Check the score and interpret its limits

14. Repair the sample without changing its first score

15. Organise bilingual work without losing meaning

Chapters 16–20

16. Review security and data boundaries in your portfolio

17. Use the published capstone as a separate assessment

18. Schedule retrieval and transfer by output

19. Decide when to extend and when to repair

20. Present a portfolio claim that matches the evidence

CHAPTER 1 OF 20 · Learn and check

1. Decide what your portfolio should demonstrate

Back to contents

Start with a capability question: can you explain a specified mechanism, apply given rules, preserve the evidence boundary and adapt when one relevant fact changes? That is more useful than asking whether you have read one hundred articles. Reading is an input to learning; a checked explanation is one possible output.

Write your purpose on the first page. A beginner may want a reliable conceptual foundation. A programmer may want to identify the paper reasoning still missing before a supervised implementation task. A teacher may want to see which connection a learner cannot yet explain. These purposes share useful outputs, but they do not justify the same claim of readiness.

For this guide, the purpose is conceptual learning across the published curriculum. The portfolio will contain scope-limited explanations, given-rule traces, evidence maps, changed-fact responses and repair records. Actual software implementation would need its own evidence, environment and checks. Do not treat a correct worksheet as a substitute for that work.

End the purpose statement with an assessment question you can answer from the included entries. For example: “Can I reconstruct this trace and explain the failed condition without looking at the model?” Avoid an unbounded question such as “Have I mastered all blockchain?” A useful portfolio supports smaller conclusions that can be revisited as your work develops.

Contents · Next

CHAPTER 2 OF 20 · Learn and check

2. Use the article library as a map rather than a memory test

Back to contents

The core library has one hundred numbered topics arranged into ten modules, with English and Chinese versions. The learning series adds methods for reading, practice and checking. Treat the technical articles as sources you can return to, not as text that must be reproduced word for word from memory.

Begin at the technical directory in your preferred language and record the route for the task you are doing. Preserve the article number, title and language. An answer about BC033 should not point vaguely to blockchain basics when the relevant gap concerns its particular nonce and ordering explanation. Accurate source routing makes correction easier.

Do not create one hundred empty folders and call that a completed portfolio. Start with one entry that includes a question, your answer, its checks and the remaining limitation. Then link it to the relevant module. A small set of inspectable entries is more useful for diagnosis than an elaborate catalogue with no actual work.

The library remains available when you forget a detail. Your stronger learning target is to know which question to ask, which article repairs it and how to check the explanation you produce. The prerequisite-map and study-notebook guides help you identify these connections. Reading every page in order is an option, but it should not replace responding to the specific error your current task reveals.

Contents · Previous · Next

CHAPTER 3 OF 20 · Learn and check

3. Keep five output types distinct

Back to contents

Use five output types: explanation, rule trace, evidence map, changed-fact decision and repair log. An explanation defines a relationship and its conditions. A rule trace applies supplied operations step by step. An evidence map connects claims to supporting observations. A changed-fact decision shows what must be reconsidered. A repair log records a concrete error and a later fresh check.

An entry may contain more than one type, but label the parts. A correct definition does not establish that you can replay a sequence. A correct sequence does not automatically establish that you can identify a missing physical input. A copied model answer does not show that you can respond to a new variation without help.

For every entry, store the question, source route, premises, first answer, check result, corrected answer and next test. If there was no correction, state that the checked answer matched the supplied model under the stated premises. If the test was open-book, preserve that label. These details let another reader interpret what the entry demonstrates.

Choose plain files or notebook pages that you can actually maintain. This article does not require a particular app or upload service. The important structure is the relationship among the task, answer, evidence and correction. Adding graphics or elaborate software should not consume the time needed to work through the mechanism and explain the reason your result is supported.

Contents · Previous · Next

CHAPTER 4 OF 20 · Learn and check

4. Make a ten-module route card

Back to contents

Module 1, BC001–BC010, establishes foundations, the wider stack and usefulness questions. Module 2, BC011–BC020, develops cryptographic reasoning. Module 3, BC021–BC030, studies consensus and its conditions. Module 4, BC031–BC040, follows execution, state and external inputs. These modules give you the basic language for later evidence paths.

Module 5, BC041–BC050, covers architecture and scaling relationships. Module 6, BC051–BC060, follows infrastructure and observations. Module 7, BC061–BC070, studies security and response. Module 8, BC071–BC080, separates token mechanisms from wider economic and programme claims. Module 9, BC081–BC090, examines governance, institutional context and jurisdiction-sensitive questions. Module 10, BC091–BC100, applies the methods to evidence and bounded decisions.

For each module, write one current capability, one next output and one unresolved question. The card is a route, not an assertion that one entry covers ten articles completely. Some modules will need several entries because their topics involve distinct mechanisms or different assumptions.

Update the card when an error directs you backward. If an application answer confuses valid signatures with permission, revisit the relevant cryptography and execution routes. Moving back to a prerequisite is a reasoned repair, not a loss of progress. Your portfolio should show these dependencies so the order of your learning is understandable rather than merely chronological.

Complete reading map

The existing numbered curriculum is shown in full below. Each row leads to the published lesson and its language sibling. The study outputs are suggested tasks for this learning guide, not certificates or claims that reading alone establishes competence.

01. Foundations · BC001–BC010

Suggested output: A problem and responsibility map

LessonRead the original articleSibling
BC001What Is Blockchain? A Clear Guide to Shared Records, Trust and Limits简体中文
BC002Blockchain vs Traditional Databases: Choosing the Right Record System简体中文
BC003Distributed Systems vs Blockchain: What the Extra Rules Change简体中文
BC004Why Shared Records Need Trust Models简体中文
BC005Blockchain History: From Digital Cash to Programmable Systems简体中文
BC006Where Blockchain Fits in the Wider Technology Stack简体中文
BC007Nodes, Clients and Peer-to-Peer Networks简体中文
BC008Blocks, Transactions and the Meaning of State简体中文
BC009Public, Private and Consortium Blockchains简体中文
BC010When a Blockchain Is Useful and When It Is Not简体中文
BC001–BC010
02. Cryptography · BC011–BC020

Suggested output: Three evidence cards with limitations

LessonRead the original articleSibling
BC011Cryptographic Guarantees and Threat Models in Blockchain简体中文
BC012Cryptographic Hashes: Fingerprints Without Secrecy简体中文
BC013Public Keys, Private Keys and Digital Signatures简体中文
BC014How to Verify a Blockchain Inclusion Proof: Roots, Headers and Finality简体中文
BC015Addresses, Key Derivation and Identity简体中文
BC016Reviewing Blockchain Key Generation: Entropy, Cloning and Failure Handling简体中文
BC017Choosing Encryption, Hashing and Signing for a Blockchain Document Workflow简体中文
BC018Zero-Knowledge Proofs: What a Proof Actually Proves简体中文
BC019Multisignatures, Threshold Signatures and Shared Control简体中文
BC020Post-Quantum Cryptography and Blockchain Migration简体中文
BC011–BC020
03. Distributed systems and consensus · BC021–BC030

Suggested output: A consensus assumption sheet

LessonRead the original articleSibling
BC021Reading Blockchain Consensus Claims: Validity, Fork Choice and Finality简体中文
BC022Two Blockchain Nodes During a Network Partition: Views, Heads and Reconnection简体中文
BC023Diagnosing Blockchain Progress: Stalled Finality, Missing Transactions and Conflicting Checkpoints简体中文
BC024Sybil Attacks and Permissionless Participation: Why Identities Are Not Votes简体中文
BC025Proof of Work and Cumulative Work: Targets, Trials and Valid Branches简体中文
BC026Proof of Stake, Validators and Slashing: Reading the Evidence Behind Participation简体中文
BC027Reading Byzantine Vote Certificates: Signers, Weight and Round Locks简体中文
BC028Finality, Confirmations and Reorganisations: A Recipient’s Transaction Timeline简体中文
BC029Fork Choice and Checkpoint Recovery: Establishing a Node’s Starting Point简体中文
BC030Measuring Blockchain Decentralisation Without a Single Score简体中文
BC021–BC030
04. Transactions and execution · BC031–BC040

Suggested output: A state trace including failures

LessonRead the original articleSibling
BC031From User Intent to Transaction Evidence: Construct, Authorize and Execute简体中文
BC032UTXO Transactions and Change Outputs: Follow the Records, Not Just the Balance简体中文
BC033Account State and Transaction Nonces: Ordering One Sender’s Instructions简体中文
BC034Mempools and Transaction Inclusion: Compare Two Nodes Before Drawing Conclusions简体中文
BC035Gas Limits, Gas Used and Fees: Reconcile a Transaction’s Resource Budget简体中文
BC036Blockchain Virtual Machines: Replaying the Same Inputs on Two Validators简体中文
BC037Smart Contracts as State Machines: Check the Caller, Conditions and Limits简体中文
BC038Contract Storage, Events and Indexes: Reconcile Three Views of One Record简体中文
BC039Diagnosing Failed Blockchain Transactions: Rejection, Revert and Call Boundaries简体中文
BC040Blockchain Oracles: Check the Report Before Trusting the External Fact简体中文
BC031–BC040
05. Architecture and scaling · BC041–BC050

Suggested output: A responsibility and dependency map

LessonRead the original articleSibling
BC041Monolithic and Modular Blockchains: Map the Responsibilities and Trust Boundaries简体中文
BC042Who Does What in Bitcoin? Wallets, Nodes, Block Producers and the UTXO Set简体中文
BC043Ethereum Node Architecture: Diagnosing Execution, Consensus and Validator Boundaries简体中文
BC044Solana Parallel Execution: Read the Account Conflicts Before the Speed Claim简体中文
BC045Hyperledger Fabric Transaction Flow: Endorsement, Ordering and the Update That Does Not Apply简体中文
BC046Layer 1, Layer 2 and Appchains: Identify Which Security Property Comes From Where简体中文
BC047Optimistic Rollup Challenges: What an Honest Observer Must Know and Do in Time简体中文
BC048Validity Rollup Evidence: Verify the State Claim, Then Reconstruct the State简体中文
BC049Blockchain Data Availability: Publication, Sampling and the Archive You Still Need简体中文
BC050Payment Channels and Lightning: Read the State Before Judging the Close简体中文
BC041–BC050
06. Interoperability and infrastructure · BC051–BC060

Suggested output: A field-by-field provenance review

LessonRead the original articleSibling
BC051Blockchain Infrastructure Dependencies: Find the Failure Behind the Interface简体中文
BC052Cross-Chain Messages: Decide What the Destination Is Allowed to Accept简体中文
BC053Comparing Blockchain RPC Answers: Match the Network, Block and Question简体中文
BC054Reading a Block Explorer: Separate Chain Evidence, Decoding and Labels简体中文
BC055Full Nodes, Light Clients and RPC: Who Actually Checks the Claim?简体中文
BC056Blockchain Historical Indexes: Prove the Dataset Covers the Question简体中文
BC057Sequencers, Batchers and Proposers: Trace Who Controls the Order简体中文
BC058MEV and Ordering Fairness: Who Benefits When the Queue Changes?简体中文
BC059Blockchain Benchmarks: Follow the Cohort from Submission to Finality简体中文
BC060Monitoring Blockchain Services: Separate Stale RPC, Finality Delay and Index Lag简体中文
BC051–BC060
07. Wallets, security and privacy · BC061–BC070

Suggested output: An authority and recovery map

LessonRead the original articleSibling
BC061Threat-Model a Blockchain Release: Attack Paths and Control Owners简体中文
BC062Wallets and Custody: Map Who Can Act, Block and Recover简体中文
BC063Blockchain Recovery: Match the Lost Capability to the Recovery Evidence简体中文
BC064Account Abstraction: Trace a Programmable Account Operation简体中文
BC065Token Approvals: Track Remaining Permission in an Allowance Ledger简体中文
BC066Blockchain Confirmation Screens: Compare Displayed Intent with Signed Authority简体中文
BC067Smart-Contract Defensive Testing: Build a Matrix That Can Catch the Wrong Result简体中文
BC068Reading a Blockchain Audit Packet: Code Versions, Proof Scope and Upgrade Authority简体中文
BC069Blockchain Privacy: What a Pseudonymous Record Can Still Reveal简体中文
BC070Blockchain Incident Tabletop: Who Can Pause What, and What Recovery Must Prove简体中文
BC061–BC070
08. Tokens and digital value · BC071–BC080

Suggested output: A claim and obligation explanation

LessonRead the original articleSibling
BC071Digital Asset Design: Separate Interchangeability, Division, Transfer and Identity简体中文
BC072Native Assets and Token Standards: Read the Interface Before the Balance简体中文
BC073NFTs and Metadata: Trace the Record, the File and the Permission Separately简体中文
BC074Tokenised Asset Claims: Reconcile the Token, the Custodian and the Entitlement简体中文
BC075Stablecoin Reserves and Redemption: Reconcile the Claims, the Cash and the Queue简体中文
BC076Digital Money Payments: Follow the Liability Through Deposits, Private Claims and CBDCs简体中文
BC077Automated Market Maker Arithmetic: Read the Pool Before Calling It a Price简体中文
BC078Lending Protocol State Checks: Collateral Limits, Liquidation Thresholds and Unfinished Debt简体中文
BC079Composability and Nested Claims: Trace the Exposure Before Adding the Totals简体中文
BC080Blockchain Operating Budgets: Separate Fees, New Tokens and Treasury Support简体中文
BC071–BC080
09. Governance and China context · BC081–BC090

Suggested output: A dated document and decision card

LessonRead the original articleSibling
BC081Mapping Blockchain Governance: Follow a Rule Change from Proposal to Effect简体中文
BC082Blockchain Upgrades: Test Rule Compatibility Before Claiming Adoption简体中文
BC083DAO Voting: Check the Snapshot, Denominator and Execution Before Calling a Proposal Successful简体中文
BC084Blockchain Ownership Disputes: Separate Technical Control, Permission and Accountability简体中文
BC085Mainland China and Blockchain: Classify the Activity Before Reading the Label简体中文
BC086Reading Mainland Blockchain Policy: Build a Document and Claim Evidence Ledger简体中文
BC087Consortium Blockchain Collaboration: Plan for Member Exit, Disputed Records and Shared Costs简体中文
BC088Digital Renminbi and Blockchain: Read the Layer Evidence Before Guessing the Network简体中文
BC089Blockchain Data Protection: Trace Every Copy Before Promising Deletion简体中文
BC090Mainland China, Hong Kong and Singapore: Build Separate Digital-Asset Evidence Cards简体中文
BC081–BC090
10. Applications and practical judgment · BC091–BC100

Suggested output: A bounded recommendation from a fixed dossier

LessonRead the original articleSibling
BC091Did Blockchain Cause the Improvement? Audit a Project’s Before-and-After Claim简体中文
BC092Blockchain Supply-Chain Records: Reconcile the Ledger with the Shipment简体中文
BC093Verifying an Education Credential: Issuer, Subject, Claim and the Optional Blockchain Anchor简体中文
BC094Credential Status Over Time: Verify the Snapshot, the Challenge and the Key History简体中文
BC095AI Agents and Blockchain Actions: Follow Authority, Submission and the Lasting Effect简体中文
BC096IoT Data on a Blockchain: Reconstruct the Sensor-to-Ledger Evidence Path简体中文
BC097Blockchain Energy Reports: Reconcile Equipment, Electricity and Emissions简体中文
BC098Design a Blockchain Pilot: Freeze the Gates Before Reading the Results简体中文
BC099Blockchain Procurement: Turn a Proposal into Verifiable Deliverables简体中文
BC100Blockchain Capstone: Decide a Shared Booking System from a Fixed Evidence Dossier简体中文
BC091–BC100
Plain-language companions · 35 published guides

These existing plain-language companions are English articles. Chinese readers can use the complete Chinese technical route above; a translated title is not being presented as a Chinese page.

How Blockchain Works | Simplest Explanation

How Blockchain Works | The Complete System

How Blockchain Works | The History

How Blockchain Works | What Can We Do with It

How Blockchain Works | Why We Need Blockchain

How Blockchain Works | Who Runs a Blockchain?

How Blockchain Works | An Idea into A Decentralized Ledger

How Blockchain Works | Why Time Is Key

How Blockchain Works | Closed Loop System

How Blockchain Works | A Record’s Journey

How Blockchain Works | Digital Fingerprints

How Blockchain Works | Keys and Digital Signatures

How Blockchain Works | Nodes and Shared Copies

How Blockchain Works | Consensus and Agreement

How Blockchain Works | Smart Contracts and Rules

How Blockchain Works | Oracles and the Outside World

How Blockchain Works | Public, Private and Consortium Networks

How Blockchain Works | Confirmations and Finality

How Blockchain Works | Wallets and Custody

How Blockchain Works | Tokens and What They Represent

How Blockchain Works | Supply Chains and Handovers

How Blockchain Works | Certificates and Credentials

How Blockchain Works | Databases and When Blockchain Helps

How Blockchain Works | Scaling and Layers

How Blockchain Works | Bridges Between Networks

How Blockchain Works | Fees and Computing Resources

How Blockchain Works | Governance and Upgrades

How Blockchain Works | Privacy and What Records Reveal

How Blockchain Works | Zero-Knowledge Proofs

How Blockchain Works | Block Explorers and Reading a Record

How Blockchain Works | Testing Rules and Finding Mistakes

How Blockchain Works | Merkle Trees and Small Proofs

How Blockchain Works | Data Availability and Missing Pieces

How Blockchain Works | Forks and Changing Histories

How Blockchain Works | Digital Identity and Proving Who You Are

Technical extensions · 19 topic pairs

Choose an extension only after its prerequisite task is clear. These workshops deepen the existing technical library rather than replace its foundational sequence.

WorkshopRead the original articleSibling
EXT001Practise Blockchain Safely: Local Chains, Public Testnets and What a Reset Really Changes简体中文
EXT002Blockchain Time and Deadlines: Which Clock Does the Rule Use?简体中文
EXT003Random Selection on a Blockchain: Commitments, Proofs and the Option to Withhold简体中文
EXT004Accessible Blockchain Tasks: Review Context, Follow Status and Recover Safely简体中文
EXT005Smart-Contract Upgrades: Preserve Stored State and Its Meaning简体中文
EXT006Conditional Exchange Across Two Blockchains: Claims, Deadlines and Refund Paths简体中文
EXT007Smart-Contract Reentrancy: Trace Callback-Visible State and Check Every Entry Point简体中文
EXT008Smart-Contract Source Verification: Reconstruct the Build and Explain the Bytecode Match简体中文
EXT009Content-Addressed Blockchain Files: Verify Required Blocks Before Reconstructing简体中文
EXT010Token Transfer Accounting: Reconcile Requested Amounts, Actual Receipts and Internal Credits简体中文
EXT011Ethereum Account and Storage Proofs: Verify the Account, the Slot and the Meaning简体中文
EXT012Smart-Contract Integer Accounting: Scales, Rounding and Conserved Remainders简体中文
EXT013Decode an Ethereum Event Log: Topics, Dynamic Data and Schema Ambiguity简体中文
EXT014Smart-Contract Role Administration: Trace Reachable Powers and Recovery Limits简体中文
EXT015Reconcile a Blockchain Timelock Queue: Dependencies, Cancellation and Operation Identity简体中文
EXT016Replay a Nested EVM Call: Restore Storage and Reconstruct Surviving Logs简体中文
EXT017Trace Solana CPI Privileges: Signers, Writable Accounts and Program-Derived Authority简体中文
EXT018Validate a Fabric Query Result: Range Evidence, Rich Queries and Phantom Changes简体中文
EXT019Trace EIP-7702 Authorization Processing Before Execution简体中文
19 published extension pairs at this review.
Related introductions and family guides

Use these related introductions when their specific reader question matches yours. They remain separate articles; this learning series does not replace them.

Blockchain Versus Crypto for Parents and Children

Problems a Blockchain Might Experience | What Can Go Wrong and Why

Can You Correct a Mistake on a Blockchain? | A Simple Guide for Children and Adults

How to Explain Blockchain to a Child? (Or an Adult)

What Is Blockchain? How Children Should Learn About It the Right Way

What Is Blockchain? A First-Principles Guide

什么是区块链?从第一性原理开始理解

Contents · Previous · Next

CHAPTER 5 OF 20 · Learn and check

5. Connect the learning guides to your outputs

Back to contents

The master learning route and reading-practice-checking guide explain how to use the collection. The prerequisite map helps locate a missing foundation. The cryptography notebook helps separate protected bytes, keys, signatures and wider identity claims. Use these early guides when your explanation lacks a clearly named object or assumption.

The consensus guide separates protocol conditions; the state-replay guide checks supplied operations; the architecture guide traces one claim; the scaling guide keeps workload and resource units explicit. These guides help you produce a controlled trace or comparison rather than combine examples from unrelated systems into an invented universal protocol.

The infrastructure evidence notebook and security paper lab support observation and permission reasoning. The token notebook separates record, mechanism and programme meaning. The governance notebook separates decision, release, runtime observation and adoption. The application comparison guide asks what evidence a purpose requires. Each method creates a different portfolio output.

You do not need to repeat an entire learning article in your notebook. Link to it, identify the task you attempted and retain your own explanation and checks. A portfolio entry should be smaller than its source yet contain enough of the premises for another reader to inspect your reasoning. If crucial facts are available only in an unlabeled screenshot or an unspecified earlier conversation, make the entry self-contained before claiming the result is reproducible.

GuidePublished learning method
01How to Learn Blockchain Technology | A Complete Learning Route
02How to Learn Blockchain Technology | Read, Practise, Check and Connect
03How to Learn Blockchain Technology | Build Your Prerequisite Map
04How to Learn Blockchain Technology | Build a Cryptography Study Notebook
05How to Learn Blockchain Technology | Study Consensus Without Mixing Protocols
06How to Learn Blockchain Technology | Learn Transactions by Replaying State
07How to Learn Blockchain Technology | Study Architecture by Tracing One Claim
08How to Learn Blockchain Technology | Study Scaling with Workload Worksheets
09How to Learn Blockchain Technology | Build an Infrastructure Evidence Notebook
10How to Learn Blockchain Technology | Build a Paper-Only Security Study Lab
11How to Learn Blockchain Technology | Build a Token Meaning-and-Mechanism Notebook
12How to Learn Blockchain Technology | Build a Governance Decision-and-Change Notebook
13How to Learn Blockchain Technology | Compare Applications by Problem and Evidence
14How to Learn Blockchain Technology | Build a Learning Portfolio from the Article Library
Use the linked task, preserve its premises and save your own output.

Contents · Previous · Next

CHAPTER 6 OF 20 · Learn and check

6. Write a first-principles explanation entry

Back to contents

Choose a relationship that repeatedly causes confusion. One example is the distinction between protecting specified data and establishing a wider real-world claim. Write the object, supplied check and permitted conclusion in three sentences. Then add a counterexample in which the check remains successful while the wider claim is not established.

Route this entry to Cryptographic Hashes: Fingerprints Without Secrecy and Public Keys, Private Keys and Digital Signatures when the gap concerns hashes or keys, and to the appropriate application article for the wider claim. Preserve each source's assumptions. Do not combine their details into a claim that one toy check implements every cryptographic or identity process they discuss.

A useful original example says: “The exercise supplies a successful integrity check for document D under its declared verification assumptions. That supports the specified integrity result. It does not by itself establish that issuer J is accepted by verifier V for purpose P.” The counterexample keeps the integrity result and explicitly gives J as outside V's accepted list.

Check whether your explanation identifies which relationship fails instead of saying the entire document is untrustworthy. Then close the source and explain the example aloud with different fictional identifiers. Changing labels should not change the logic. If you lose the distinction, record that specific error and return to the prerequisite rather than adding more terminology to the same unclear paragraph.

Contents · Previous · Next

CHAPTER 7 OF 20 · Learn and check

7. Write a rule-trace entry with complete premises

Back to contents

A trace needs initial state, rules, operation order and a clear scope. Without those, a final number cannot be checked. Include failed operations and state what they do to the tracked variables. If the worksheet omits fees, nonces or physical effects, preserve those omissions rather than inventing behaviour from a real platform.

Use the state-replay learning guide and Account State and Transaction Nonces: Ordering One Sender’s Instructions, Smart Contracts as State Machines: Check the Caller, Conditions and Limits, Contract Storage, Events and Indexes: Reconcile Three Views of One Record or Diagnosing Failed Blockchain Transactions: Rejection, Revert and Call Boundaries according to the missing connection. Keep their cases separate. A nonce explanation, a contract transition and an event-storage distinction are related topics, but they do not automatically describe one identical execution environment.

For this guide's short original trace, a paper account starts with 5 points. Its only operation is spend an integer x. It succeeds if x is positive and no greater than the current points; success subtracts x, and failure changes nothing. Process spend3, spend4 and spend1 in that order. There are no fees, network messages or other tracked variables.

The checked results are success to 2, failure remaining at 2, then success to 1. Two operations succeed and one fails. A portfolio answer containing only final1 is incomplete because it hides whether the learner understood the rejection. This exercise illustrates the structure of a trace; the library's fuller cases provide richer execution reasoning under their own supplied rules.

StepSpendOutcomePoints after
13Success2
24Rejected: 4 > 22
31Success1
Original point-only paper model; initial 5, no fees or network effects.

Contents · Previous · Next

CHAPTER 8 OF 20 · Learn and check

8. Write an evidence-map entry

Back to contents

An evidence map should contain a claim, its supporting facts, the trusted premises and the limitation. Arrows need specific meaning. “Observation O supports the stated result for object K at t1” is useful. “O proves everything” conceals the dependencies you need to study.

Use the architecture and infrastructure guides to practise object identity, observation time and contribution limits. Comparing Blockchain RPC Answers: Match the Network, Block and Question, Reading a Block Explorer: Separate Chain Evidence, Decoding and Labels, Full Nodes, Light Clients and RPC: Who Actually Checks the Claim? and Blockchain Historical Indexes: Prove the Dataset Covers the Question help distinguish access, displayed information, verification and coverage. Your map should retain the source's actual conditions instead of treating every query response as independent proof.

For an original paper entry, suppose O is a correctly checked observation that system L runs version R1 at t1. Separately, release note N establishes that R2 was published at t0. Neither fact establishes that L adopted R2. Draw N to publication and O to L's observed runtime. Leave the adoption relationship unfilled rather than inventing it.

This case connects to the governance notebook but is not a deployment procedure. The missing relationship is runtime adoption of R2 by L, not publication of R2 or an observation that L never changes. A good portfolio map preserves both successful facts and asks for the specific target-bound runtime evidence needed for a later question. It does not replace uncertainty with a generic red failure label.

Contents · Previous · Next

CHAPTER 9 OF 20 · Learn and check

9. Write a changed-fact decision entry

Back to contents

A changed-fact entry starts from a fully stated baseline. Change exactly one named premise, preserve the others and identify which conclusion must be reconsidered. This structure tests whether you understood the dependency or merely memorised the earlier answer.

The application comparison guide supplies a useful example: under policy P, five checks suffice and an anchor is optional. P2 adds an anchor requirement. The baseline packet without that evidence can satisfy P while not satisfying P2 on its supplied packet. Both results remain correctly labelled. A new policy does not erase the old one.

You can practise the same method with the short point trace. Independently reset to5 and change only the second operation from spend4 to spend2. The operations are now spend3, spend2, spend1. Results are success to2, success to0, failure remaining0. The final state changes from1 to0 and the failure moves from the second to the third operation.

Keep the changed sequence labelled as a new fixture, not as a correction to the original trace. If you accidentally continue from the original final1, you have changed the starting state as well and are no longer doing the specified variation. That error should enter the repair log. This is how a small portfolio exercise teaches controlled comparison before you tackle the fuller governance or application capstones.

Contents · Previous · Next

CHAPTER 10 OF 20 · Learn and check

10. Keep a repair log that names the error

Back to contents

A repair log records the original statement, why it failed, the relevant source route, the corrected relationship and a later fresh test. “Read again” is an action, but it does not identify what was repaired. “Confused submission with accepted state change” identifies a connection you can test.

For the point trace, a learner might write “spend4 reduces2 to minus2.” The error is applying subtraction without checking the supplied permission condition. The repair is to evaluate positive x and x no greater than current points before updating. The later test should use a fresh sequence so the learner cannot simply reproduce the corrected final number.

For the runtime map, a learner might write “R2 was released, therefore L runs R2.” The missing relationship is target adoption. Repair by preserving R2's publication and L's R1 observation at t1, then requesting target-bound evidence for any later runtime claim. A fresh variation can change the observed target from L to V and ask what transfers.

Do not delete the first attempt from the portfolio. It shows the reason for the next task, while the corrected answer shows what you now understand. Label copied model reasoning and assisted corrections honestly. A later independent explanation can strengthen the learning evidence, but the history should remain interpretable rather than polished into a fictional record of never making mistakes.

Contents · Previous · Next

CHAPTER 11 OF 20 · Learn and check

11. Mark the original sample portfolio with four criteria

Back to contents

We will mark four fictional entries using the same four criteria, one point each. Criterion Q: the question and scope are stated. Criterion P: the supplied premises and relevant rule are retained. Criterion R: the conclusion follows from those premises. Criterion B: the boundary or remaining uncertainty is explained. Each entry can receive 0–4 points; the total is out of16.

These are classroom criteria for this sample, not a universal competence framework. A point is binary here: award it only when the named requirement is fully present in the supplied entry. We will provide exactly enough facts to make the scoring reproducible. Do not infer missing work from a learner's confidence or the neatness of the page.

The four entries are an explanation, a trace, an evidence map and a changed-policy decision. The repair log is kept outside the scored set so you can see how correction affects the next assessment without rewriting the first score. This avoids awarding extra points merely because a learner submitted more pages.

Read the entries in the next section, assign Q, P, R and B separately, then calculate each subtotal. A single number such as mostly correct would conceal the teaching diagnosis. The criterion pattern matters because different entries need different repairs even when they happen to earn the same subtotal.

Contents · Previous · Next

CHAPTER 12 OF 20 · Learn and check

12. Read the four complete sample entries

Back to contents

Entry A asks whether supplied successful integrity checking for D establishes J's acceptance by V for purpose P. It retains the given integrity result and the fact that J is not on V's accepted list. It concludes that integrity passes while issuer acceptance fails, and explicitly limits the result to the given purpose. All required information is present.

Entry B asks for the result of the original point trace. It records initial5, the positive-and-affordable spend rule, failure leaving state unchanged, and the sequence3,4,1. It incorrectly concludes that all three succeed and the final state is minus3. It says the model contains no fees or network effects. The wrong arithmetic outcome follows from ignoring the retained rule, not from missing premises.

Entry C asks whether the supplied notes establish L's adoption of R2. It retains R2's publication at t0 and L's correctly observed R1 runtime at t1. It concludes that R2 adoption is not established, but provides no statement of the remaining boundary or evidence request. We deliberately supply no extra sentence to rescue that criterion.

Entry D asks for A and B's acceptance under changed policy P2. It retains P2's five mandatory checks plus H, A's passing five checks without H and B's passing five checks with H. It concludes only B satisfies P2 on the supplied packets and says this does not erase A's acceptance under P or establish wider recognition. Nothing else is needed for this sample decision.

Contents · Previous · Next

CHAPTER 13 OF 20 · Learn and check

13. Check the score and interpret its limits

Back to contents

Entry A earns Q1, P1, R1 and B1: 4/4. Entry B earns Q1 and P1 because its question and rules are present, R0 because its result violates those rules, and B1 because its stated model boundary is present: 3/4. A clear scope does not repair a wrong trace.

Entry C earns Q1, P1 and R1. B0 reflects the intentionally absent explanation of remaining evidence or boundary: 3/4. Entry D earns all four criteria: 4/4. The total is4+3+3+4=14/16, or87.5%. That percentage is only an arithmetic description of these four classroom entries.

The portfolio is not ready to be described as error-free. Entry B has a material reasoning failure even though the total is high. Entry C needs an explicit limitation. A weighted average cannot make a violated trace rule true. Preserve the criterion results beside the total so the next task follows the actual errors.

This score also does not demonstrate all ten curriculum modules, production security, independent implementation or long-term retention. Only the four supplied entries were assessed. To expand the claim, add suitable work and fresh assessment evidence. A useful portfolio statement is “These entries show the listed strengths and the two identified repair needs under this rubric,” rather than “87.5% means I have mastered blockchain.”

EntryQPRBTotal
A11114
B11013
C11103
D11114
First attempt: 14/16 = 87.5%; corrected with assistance: 16/16. Fresh assessment still needed.

Contents · Previous · Next

CHAPTER 14 OF 20 · Learn and check

14. Repair the sample without changing its first score

Back to contents

Repair B by applying the condition before each update: spend3 succeeds from5 to2; spend4 fails because4 exceeds2 and leaves2; spend1 succeeds from2 to1. State two successes, one failure and final1. Preserve the same model boundary. The corrected entry now satisfies all four sample criteria.

Repair C by adding: “The notes establish R2's publication and L's R1 runtime at t1. They do not establish L's later adoption or permanent non-adoption. A later claim about L running R2 would require appropriately target-bound runtime evidence.” This preserves the successful facts and names the remaining question.

The corrected four-entry set would score16/16 under this rubric. Keep the original14/16 as the first-attempt result and label16/16 as corrected with model assistance. Do not report the latter as an unaided fresh assessment. The distinction is part of making the portfolio's learning evidence honest and usable.

For the next independent check, use a new trace and a new runtime variation. Supply the rules fully and close the model before answering. If the same error recurs, return to the rule evaluation or identity-binding prerequisite. If it does not, record that bounded improvement. A single successful fresh test supports improvement on that connection, while longer-term retention and wider transfer still require their own observations.

Contents · Previous · Next

CHAPTER 15 OF 20 · Learn and check

15. Organise bilingual work without losing meaning

Back to contents

Keep English and Simplified Chinese sibling routes together for each entry. Identify which language you first used and whether you consulted the sibling during correction. Reading both can reveal a confused term, but two language versions of one source are not two independent proofs of its factual claims.

Preserve identifiers, quantities, conditions and time labels across your own bilingual explanation. For the point trace, initial5, sequence3,4,1 and final1 must remain the same. For the policy case, optional H under P must not become mandatory merely because the Chinese sentence uses a different phrase. Technical equivalence rests on these relationships, not on matching every word.

Use a small term card with the English term, Chinese expression, object and one contrast within the exercise. For example, submission can be explained as 提交 in a task where it is kept distinct from accepted state change. Do not claim that a preferred translation alone settles every platform's technical definition; check the source's actual use.

For readers in China, keep conceptual study separate from statements about current local permissions or regulatory treatment. The published jurisdiction articles give scoped reading routes, including Mainland China and Blockchain: Classify the Activity Before Reading the Label, Reading Mainland Blockchain Policy: Build a Document and Claim Evidence Ledger and Mainland China, Hong Kong and Singapore: Build Separate Digital-Asset Evidence Cards. Any real activity would require current, relevant evidence. This portfolio guide makes no new legal conclusion and does not treat a Chinese translation as permission to conduct a particular blockchain or token activity.

Contents · Previous · Next

CHAPTER 16 OF 20 · Learn and check

16. Review security and data boundaries in your portfolio

Back to contents

Use fictional names, public teaching data and the article's synthetic fixtures. A conceptual portfolio does not need real private keys, passwords, personal identity documents or production customer records. The original exercises already supply the premises required for learning; adding sensitive material would not improve the reasoning task.

For security entries, route to Threat-Model a Blockchain Release: Attack Paths and Control Owners for threat questions, Wallets and Custody: Map Who Can Act, Block and Recover and Blockchain Recovery: Match the Lost Capability to the Recovery Evidence for custody and recovery distinctions, and Token Approvals: Track Remaining Permission in an Allowance Ledger or Blockchain Confirmation Screens: Compare Displayed Intent with Signed Authority for permission and displayed-information reasoning. The security paper lab helps you practise these connections without conducting a live attack or granting a real allowance.

Label observations as paper-only, supplied, independently calculated or actually measured, whichever applies. A table copied from a fictional model should not be presented as a benchmark you ran. A correctly marked threat worksheet does not demonstrate that a production system has been audited. This protects the evidential meaning of the portfolio rather than adding a vague warning after each page.

If you later add implementation work, define a separate entry with its environment, versions, test inputs, outcomes and limitations. Keep that evidence distinct from the conceptual paper exercises. The present guide does not instruct you to deploy, sign transactions or collect real personal data. It gives you a structure for understanding what each learning output supports before you make a broader readiness claim.

Contents · Previous · Next

CHAPTER 17 OF 20 · Learn and check

17. Use the published capstone as a separate assessment

Back to contents

When your prerequisite outputs are stable, attempt Blockchain Capstone: Decide a Shared Booking System from a Fixed Evidence Dossier from its fixed evidence dossier before reading the model answer. The article already supplies its own booking case, decision rule, operation sequence and twenty-point rubric. Do not recreate its facts from vague memory or replace them with the simpler point account in this guide.

Save your decision memo as a new portfolio entry. Retain the architecture choice, supplied state trace, control map, physical and data boundaries, evidence plan and changed-fact response requested there. Mark using the capstone's rubric, not the four-criterion sample score used in this guide. Different rubrics answer different learning questions.

If you select a conventional design under the dossier's base conditions and justify it correctly, that can demonstrate good blockchain understanding. The score should follow the supplied requirements, not reward a preferred technology. When the governance fact changes, preserve all unchanged facts and reconsider the dependency the article explicitly identifies.

After checking, record which earlier portfolio entries helped and which connection still failed. A failed authority distinction may send you to governance; a mistaken final state may send you to execution; an inflated physical conclusion may send you to the application comparison. This makes the capstone a diagnostic assessment integrated with the library, rather than a ceremonial final page that prevents further learning.

Contents · Previous · Next

CHAPTER 18 OF 20 · Learn and check

18. Schedule retrieval and transfer by output

Back to contents

Plan review around an observable task. First reconstruct a relationship without the source; then check it; later apply a changed premise. The aim is to see whether the connection survives when the original wording or familiar final number is absent. Merely recognising a highlighted sentence is a weaker learning observation.

For an illustrative review plan, complete one explanation and one trace in the first session. In the next session, close the source and reconstruct them. In a later session, use one fresh variation and one evidence map. These are flexible study stages, not experimentally validated timing prescriptions for every learner.

Keep the task version and assistance level with each result. If you changed the initial state, identify that change. If a tutor supplied the failing condition, record that support. This lets you compare like with like and avoid declaring improvement simply because the second task was easier or the model was visible.

Do not review every module at equal length regardless of need. Use the route card and repair log to choose the next output. A learner consistently getting identity and time right but failing transition conditions needs a different task from one who calculates correctly yet inflates physical conclusions. Your portfolio should reveal that distinction and make the next session concrete enough to complete.

Contents · Previous · Next

CHAPTER 19 OF 20 · Learn and check

19. Decide when to extend and when to repair

Back to contents

Extend complexity when you can state the premises, produce a checked result, explain its boundary and handle a relevant fresh variation. Repair when one of those connections repeatedly fails. This is a local learning decision, not a universal score threshold that certifies mastery of the whole field.

For example, after correctly solving the point trace and its variation, move to a published execution case with additional tracked variables. Keep the new rules explicit. After correctly interpreting the runtime notes, move to a governance case involving decision, released artifact and target observation. Add one source of complexity at a time so a new error remains diagnosable.

If your portfolio has excellent definitions but no traces, add a trace rather than reread definitions indefinitely. If it contains correct traces but unsupported application claims, add an evidence-boundary task. If every answer came from a visible model, add a fresh unaided attempt with complete premises. The missing output type should shape the next step.

Keep a practical stopping point for each session: one corrected relationship and one declared next test. You can then continue without needing to reconstruct a scattered conversation or a dozen open pages. Progress is the expanding set of tasks you can explain and check under stated conditions, accompanied by an accurate account of what remains uncertain.

Contents · Previous · Next

CHAPTER 20 OF 20 · Learn and check

20. Present a portfolio claim that matches the evidence

Back to contents

Your cover note should state purpose, included modules and output types, source routes, assistance levels, assessment results and unresolved gaps. Make it possible for a reader to inspect a particular entry rather than rely on your description of confidence. The strongest claim is the one the included work can actually support.

For the fictional sample, a model cover note says: “This conceptual portfolio contains four assessed paper entries. The first attempt scored14/16 under the stated Q/P/R/B rubric, with a trace error and an omitted evidence boundary. Model-assisted corrections bring the same entries to16/16. A fresh independent trace and runtime variation remain to be completed. These results do not establish coverage of all ten modules or implementation competence.”

For your own portfolio, replace every sample quantity with your real learning observations. Do not report the fictional score as your achievement. Include the ten-module route card to show coverage and next tasks, and retain the repair history so the reader understands the route from first attempt to present explanation.

Return to the learning-series hub whenever a new question appears. The published library can support continuing study of foundations, cryptography, consensus, execution, architecture, infrastructure, security, tokens, governance and applications. This guide gives you a way to organise that study into inspectable work. A useful portfolio stays open to correction and grows through new checked tasks, while each claim remains tied to the evidence actually included.

Contents · Previous · Next

Continue learning

Technical article library

Sources and scope

The packet comparison, point trace and portfolio rubric are original paper exercises. Their supplied verification outcomes are premises, not implemented protocols, measurements, qualifications or production assurance. Linked technical articles retain their own examples and conditions. Sources and published routes checked on 14 October 2026. Reading and paper practice do not certify implementation competence.

Master Blockchain — English technical directory

Master Blockchain — Chinese technical directory