Chapter 22 — Web3, blockchain and cryptoasset security: data and dependencies
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 Tracing data flows"]
N2["22.2 Identifying dependencies"]
N3["22.3 Planning for dependency failure"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 Tracing data flows"]
N2["22.2 Identifying dependencies"]
N3["22.3 Planning for dependency failure"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 Tracing data flows]
|
v
[22.2 Identifying dependencies]
|
v
[22.3 Planning for dependency failure]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) trace data flows across on-chain and off-chain parts; (2) identify dependencies; (3) plan for dependency failure.
22.1 Tracing data flows
Sofia traces how one volunteer shift becomes vouchers. A coordinator records the shift in the database; another approves it; each night the issuing service reads approved shifts, builds a mint batch, and sends it to the keyholders; two keyholders sign; the contract mints; the shop terminal reads balances from a validator. At each step she records the data, its format, who can change it and how it is checked. The trace shows that the issuing service is a critical point: if its output is wrong, keyholders may sign an incorrect batch without noticing anything unusual.
22.2 Identifying dependencies
The system depends on components the cooperative does not fully control: the hosting provider for validators, the wallet application members use, the libraries used by the contract and issuing service, and the compiler that builds the contract. Sofia lists each dependency, its owner, its update frequency and how failure would show. The SWC registry includes weaknesses from outdated compilers, so she records the exact compiler version. Dependencies are part of the attack surface and the failure surface, and knowing them is the first step to managing them rather than being surprised by changes made by someone else.
22.3 Planning for dependency failure
For each important dependency Sofia writes what the cooperative would do if it failed. If the hosting provider has an outage, two validators in different data centres keep the ledger running. If the wallet application is withdrawn, members can export keys to another compatible wallet. If a library has a serious flaw, the issuing service can be stopped and minting done manually with extra checks. She pins library versions and reviews updates monthly. Planning ahead turns dependency failures from crises into procedures, and the board approves the plan with a yearly review date.
Worked example
Sofia finds the issuing service is a critical point and plans responses for hosting, wallet and library failures, with pinned versions.
Synthetic case. The data flows and dependencies are synthetic; the SWC registry is a real source.
Errors and limits
Assuming dependencies are stable leaves the system unprepared when they change or fail.
Exercises
- EX064 — Critical point. Which component does the trace show is critical? Rubric: 3 = the issuing service;; 2 = issuing service, hedged with another option;; 1 = the shop;; 0 = none.
- EX065 — Compiler record. Why record the exact compiler version? Rubric: 3 = outdated compilers are a known weakness class;; 2 = compiler risk;; 1 = style;; 0 = none.
- EX066 — Library response. What happens if a library has a serious flaw? Rubric: 3 = stop the issuing service and mint manually with extra checks;; 2 = manual minting;; 1 = ignore;; 0 = none.
Synthesis
Tracing flows and planning for dependency failure make hidden risks manageable.
Continue studying — chapter 22 of 40
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →