Chapter 12 — Web3, blockchain and cryptoasset security: data flows
Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Tracing the flow"]
N2["12.2 Where data can go wrong"]
N3["12.3 Adding checks"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Tracing the flow"]
N2["12.2 Where data can go wrong"]
N3["12.3 Adding checks"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX034"]
[Learning outcomes]
|
v
[12.1 Tracing the flow]
|
v
[12.2 Where data can go wrong]
|
v
[12.3 Adding checks]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes
You will (1) trace data from source to ledger; (2) find points where data can go wrong; (3) add checks along the flow.
12.1 Tracing the flow
Lucas traces how teaching a workshop becomes credits. The leader records the workshop in the booking system; the coordinator approves it; each week the issuing service reads approved workshops, calculates credits and builds a batch; two staff sign the batch through the multisig; the contract grants credits and emits events; the booking application shows the new balance. He writes each step, its data, who controls it and how it could fail. The trace reveals that the calculation step has no independent check, which becomes his first improvement project for the term.
12.2 Where data can go wrong
Data can go wrong at each step: a leader records the wrong date, a coordinator approves a duplicate, the service miscalculates, a signer approves without reading, or the contract rejects a valid grant. Lucas also considers timing: if the service runs while the database is mid-update, it may read partial data. He lists each failure point with an example. He does not consider how someone might deliberately misuse the system in detail; he focuses on errors and controls, which also protect against misuse in most cases without needing attack knowledge.
12.3 Adding checks
Lucas adds checks along the flow. The issuing service now compares its batch total with an independent calculation from the database and refuses to proceed if they differ. The batch summary shows each member's grant and flags any workshop already credited. After the contract grants credits, a script compares events with the batch. Each check is small and independent. Together they make it unlikely that an error passes unnoticed. He tests each check with seeded errors in synthetic data and records the results in the design notes for the developer.
Worked example
Lucas adds an independent batch total check, duplicate flags in the summary and a post-grant event comparison, each tested with seeded errors.
Synthetic case. The data flow and checks are synthetic.
Errors and limits
A calculation step with no independent check can pass errors straight to signing.
Exercises
- EX034 — Unchecked step. Which step had no independent check? Rubric: 3 = the credit calculation;; 2 = calculation;; 1 = signing;; 0 = none.
- EX035 — Timing issue. What timing problem could occur? Rubric: 3 = reading partial data mid-update;; 2 = partial reads;; 1 = vague;; 0 = none.
- EX036 — Post-grant check. What happens after credits are granted? Rubric: 3 = a script compares events with the batch;; 2 = event comparison;; 1 = vague;; 0 = none.
Synthesis
Tracing flows and adding independent checks keep data correct from source to ledger.
Continue studying — chapter 12 of 30
← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →