Chapter 8 — Web3, blockchain and cryptoasset security: failure modes
Lesson map
Lesson 08 published. Map, example, EX029.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Listing failure modes"]
N2["8.2 Linking failures to symptoms"]
N3["8.3 Prioritising by impact"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX029"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Listing failure modes"]
N2["8.2 Linking failures to symptoms"]
N3["8.3 Prioritising by impact"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX029"]
[Learning outcomes]
|
v
[8.1 Listing failure modes]
|
v
[8.2 Linking failures to symptoms]
|
v
[8.3 Prioritising by impact]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX029]
Learning outcomes
You will (1) list ways the deposit system can fail; (2) link failures to symptoms; (3) prioritise by impact.
8.1 Listing failure modes
Aiko lists failure modes for the deposit system: a node falls behind; two nodes fail and the ledger stops; the deposit service crashes mid-release; a staff signer loses their device; the database and ledger disagree about a loan; a role is changed unexpectedly; and a backup cannot be restored. For each she writes a short description without technical misuse detail. Listing failure modes before they happen lets the library prepare responses calmly, rather than inventing them under pressure when a borrower is waiting.
8.2 Linking failures to symptoms
Each failure shows itself through symptoms. A lagging node shows a growing height difference. A stopped ledger shows no new blocks. A crashed deposit service shows returns recorded in the database without matching releases on the ledger. A database-ledger disagreement appears in reconciliation. An unexpected role change appears as a privileged event without an approved change. Aiko builds a table from symptom to likely failures, so that whoever sees a symptom knows where to look first. This table becomes the front page of her troubleshooting guide.
8.3 Prioritising by impact
With Mr Kowal and the manager, Aiko ranks failures by impact and likelihood. An unexpected role change is rare but high impact, because it could change who controls deposits. A crashed deposit service is more likely and affects borrowers directly. A lagging node is common but low impact while the other two are healthy. The ranking guides which monitoring and runbooks she builds first. She records the reasoning, and plans to revisit it after six months of telemetry gives better evidence of what actually happens.
Worked example
Aiko lists seven failure modes, maps symptoms to them and ranks an unexpected role change as rare but high impact.
Synthetic case. The failure modes and ranking are synthetic.
Errors and limits
Building monitoring in the order failures come to mind neglects rare high-impact events.
Exercises
- EX029 — Crash symptom. What symptom shows a crashed deposit service? Rubric: 3 = returns without matching releases;; 2 = missing releases;; 1 = slow website;; 0 = none.
- EX030 — Symptom table purpose. What is the symptom table for? Rubric: 3 = knowing where to look first;; 2 = triage;; 1 = decoration;; 0 = none.
- EX031 — Rare high-impact failure. Which failure is rare but high impact? Rubric: 3 = an unexpected role change;; 2 = role change;; 1 = lagging node;; 0 = none.
- EX032 — Ranking review. When will the ranking be revisited? Rubric: 3 = after six months of telemetry;; 2 = six months;; 1 = never;; 0 = none.
Synthesis
Failure modes linked to symptoms and ranked by impact guide preparation.
Continue studying — chapter 08 of 18
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →