Chapter 16 — Security architecture
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Components and trust boundaries"]
N2["16.2 Defence in depth"]
N3["16.3 Documenting decisions"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Components and trust boundaries"]
N2["16.2 Defence in depth"]
N3["16.3 Documenting decisions"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Components and trust boundaries]
|
v
[16.2 Defence in depth]
|
v
[16.3 Documenting decisions]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) describe a system as components and trust boundaries; (2) apply defence in depth; (3) document architecture decisions.
16.1 Components and trust boundaries
Sofia draws the voucher system's architecture: member wallets, the shop terminal, the shift database, a small issuing service that turns approved shifts into mint requests, the treasury multisig, the voucher contract and three validators. She marks trust boundaries wherever data crosses from one owner or level of trust to another, such as from the database to the issuing service and from the service to the ledger. Each boundary needs a check: the service verifies approvals before requesting a mint, and the multisig keyholders verify the request before signing. Drawing boundaries shows where checks are missing.
16.2 Defence in depth
Defence in depth means layering controls so a single failure does not cause harm. For minting, Sofia's layers are: approvals in the database require a coordinator, the issuing service checks the shift is not already rewarded, the multisig requires two keyholders to sign, the contract enforces a weekly cap, and a daily reconciliation compares vouchers with shifts. An error at any one layer is caught by another. She notes that layers should be independent: if the same person controls both the approval and one multisig key, two layers collapse into one, so she separates those duties.
16.3 Documenting decisions
Sofia writes short architecture decision records. Each states the decision, the alternatives considered, the reasons, and the consequences. One record explains choosing a permissioned ledger over a public chain because members wanted low costs and controlled participation, accepting that the cooperative must operate validators. Another explains the weekly cap. Decision records help future volunteers understand why the system is the way it is, so they do not undo important choices by accident. Dr Asante notes that external reviewers also read them, since knowing the intent behind a design makes reviews faster and more accurate.
Worked example
Sofia layers coordinator approval, duplicate checks, a 2-of-3 multisig, a contract weekly cap and daily reconciliation, separating approval from signing duties.
Synthetic case. The architecture is synthetic.
Errors and limits
Letting one person control two layers collapses defence in depth into a single point.
Exercises
- EX046 — Boundary check. What check sits at the database-to-service boundary? Rubric: 3 = the service verifies approvals before requesting a mint;; 2 = verify approvals;; 1 = vague;; 0 = none.
- EX047 — Layer independence. Why separate approval and signing duties? Rubric: 3 = so two layers do not collapse into one person;; 2 = independence;; 1 = speed;; 0 = none.
- EX048 — Ledger choice reason. Why a permissioned ledger? Rubric: 3 = low costs and controlled participation;; 2 = control;; 1 = popularity;; 0 = none.
Synthesis
Clear boundaries, independent layers and recorded decisions make architecture defensible.
Continue studying — chapter 16 of 40
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →