Lesson map
Lesson 31 published. Map, example, EX091.
flowchart TD
N0["Learning outcomes"]
N1["31.1 Transaction ordering"]
N2["31.2 Key-management incidents"]
N3["31.3 Relating cases to small systems"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX091"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["31.1 Transaction ordering"]
N2["31.2 Key-management incidents"]
N3["31.3 Relating cases to small systems"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX091"]
[Learning outcomes]
|
v
[31.1 Transaction ordering]
|
v
[31.2 Key-management incidents]
|
v
[31.3 Relating cases to small systems]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX091]
Learning outcomes
You will (1) analyse transaction-ordering risks conceptually; (2) study key-management incidents at a high level; (3) relate advanced cases to small systems.
31.1 Transaction ordering
On public ledgers, the order of transactions within a block is chosen by the block producer, and others can see pending transactions before they are included. Daian and colleagues' 2020 study, Flash Boys 2.0, documented how this visibility lets automated agents profit by reordering or inserting transactions, harming ordinary users and potentially the stability of consensus. Sofia studies the paper conceptually. She notes the cooperative's permissioned ledger has only three known validators and no open trading, so this risk is much smaller, but any future connection to public markets would bring it into scope and require fresh analysis.
31.2 Key-management incidents
Many large losses in the cryptoasset field have involved the compromise or misuse of keys controlling privileged functions, rather than flaws in contract logic. Sofia reads public summaries at a high level only, noting patterns: too few signers, keys held on internet-connected machines, and no delay before privileged actions took effect. She compares these patterns with the cooperative's design: three keyholders on hardware devices, a 2-of-3 threshold and timelocks on administration. She concludes the design addresses the main patterns, while recognising that people can still be deceived into signing, so batch summaries remain essential.
31.3 Relating cases to small systems
Advanced cases from large systems can seem irrelevant to a 900-member cooperative, but their lessons scale down. Transaction-ordering research teaches that visible pending actions can be exploited, so the cooperative should not reveal planned batches publicly in advance. Key incidents teach that signing processes need clear information and independent checks. Sofia writes a one-page note for the board summarising three lessons and the corresponding controls. Dr Asante praises her for drawing lessons without copying details that could be misused. Learning from others' incidents is cheaper than learning from one's own.
Worked example
Sofia relates Flash Boys 2.0 and key-incident patterns to the cooperative, keeping batches unannounced and relying on hardware keys, 2-of-3 signing and summaries.
Synthetic case. The cooperative's analysis is synthetic; Daian et al. (2020) is a real source.
Errors and limits
Dismissing large-system incidents as irrelevant misses lessons that apply at small scale.
Exercises
- EX091 — Ordering study. Which 2020 study documented transaction reordering?
Show marking criteria
Rubric: 3 = Daian et al., Flash Boys 2.0;; 2 = Flash Boys 2.0;; 1 = Nakamoto;; 0 = none. - EX092 — Key incident pattern. Name one pattern in key-related losses.
Show marking criteria
Rubric: 3 = too few signers;; 2 = keys on connected machines;; 1 = strong timelocks;; 0 = none. - EX093 — Ordering lesson applied. How does the cooperative apply the ordering lesson?
Show marking criteria
Rubric: 3 = do not announce planned batches publicly;; 2 = keep batches private;; 1 = publish batches;; 0 = none.
Synthesis
Advanced cases teach scalable lessons about ordering, keys and signing processes.
Continue studying — chapter 31 of 40
← Chapter 30 (draft) · Course chapter index · Chapter 32 (draft) →