Chapter 2 — Web3, blockchain and cryptoasset security: advanced seminar
Lesson map
Lesson 02 published. Map, example, EX008.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Trust assumptions"]
N2["2.2 Upgradeability"]
N3["2.3 Multi-signature and timelocks"]
N4["2.4 Ordering and monitoring"]
N5["2.5 Seminar critique"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX008"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Trust assumptions"]
N2["2.2 Upgradeability"]
N3["2.3 Multi-signature and timelocks"]
N4["2.4 Ordering and monitoring"]
N5["2.5 Seminar critique"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX008"]
[Learning outcomes]
|
v
[2.1 Trust assumptions]
|
v
[2.2 Upgradeability]
|
v
[2.3 Multi-signature and timelocks]
|
v
[2.4 Ordering and monitoring]
|
v
[2.5 Seminar critique]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX008]
Learning outcomes
You will (1) explain blockchain trust assumptions; (2) analyse privileged roles and upgradeability; (3) discuss transaction ordering and monitoring.
2.1 Trust assumptions
In the seminar, Tariq revisits foundations. Nakamoto's Bitcoin paper shows how a public ledger can be secured without a central party, provided honest participants control most computing power. Wood's yellow paper defines Ethereum's account model and virtual machine. NIST IR 8202 explains that permissioned and permissionless ledgers make different trust assumptions. Tariq's point for the seminar is that contracts inherit these assumptions but add new ones: whoever holds privileged keys becomes a trusted party, often unnoticed by users. He illustrates this with a simple diagram of trust relationships.
2.2 Upgradeability
Contracts are immutable by default, but many protocols use a proxy pattern so that the code behind a fixed address can be replaced. The EthTrust specification explains that this means the system cannot be considered immutable, because the upgrade authority could point the proxy at new code. Upgradeability lets teams fix bugs, but concentrates power. The seminar discusses how documentation, access control on upgrade functions and independent review of each new implementation reduce the risk, from the defender's side. Tariq records which forms of upgrade control he will code in his study.
2.3 Multi-signature and timelocks
A multi-signature wallet requires several keyholders to approve an action, so one lost or stolen key is not enough. A timelock delays execution of an approved action for a set period, giving users and monitors time to see it and respond, for example by withdrawing funds. Tariq notes these controls address different failures: multi-signature reduces single-key compromise and mistakes, while timelocks add visibility. Neither helps if keyholders collude, which is why governance and transparency also matter. He records the distinction in his codebook definitions.
2.4 Ordering and monitoring
Daian and colleagues (2020) showed that transaction ordering creates opportunities for value extraction, and EthTrust discusses ordering attacks and recommends timelocks for sensitive operations as one mitigation. Monitoring firms like Lumen watch queued privileged actions and alert clients. The seminar asks whether a timelock window is long enough for monitors to detect, confirm and communicate a concern, a measurable question Tariq adds to his dissertation as a secondary aim. He records how Lumen defines a confirmed alert, so that detection times are measured consistently across all queued changes in the pilot and main study.
2.5 Seminar critique
Peers challenge Tariq: protocols that adopt timelocks may also be better funded and more careful overall, so any lower incident rate might reflect care, not the control. Another asks whether public reports undercount small incidents. Tariq records both as competing explanations to address in design. Dr Larsen notes that a dissertation that names and tests its competing explanations is stronger than one that ignores them, even if it cannot rule them all out. He adds both points to his design notes for the next chapter.
Worked example
The seminar links ledger trust assumptions to privileged keys, upgradeability, multi-signature and timelocks; peers raise care and reporting bias as competing explanations.
Synthetic case. Seminar content and peers are synthetic; Nakamoto (2008), Wood, NIST IR 8202, EEA EthTrust and Daian et al. (2020) are real sources.
Errors and limits
Assuming a contract is immutable without checking for upgrade authority misjudges who users must trust.
Exercises
- EX008 — Permissioned difference. What does NIST IR 8202 say about permissioned ledgers? Rubric: 3 = different trust assumptions from permissionless;; 2 = trust;; 1 = identical;; 0 = none.
- EX009 — Proxy effect. Why does a proxy pattern break immutability? Rubric: 3 = upgrade authority can point to new code;; 2 = replaceable code;; 1 = vague;; 0 = none.
- EX010 — Multisig purpose. What does multi-signature reduce? Rubric: 3 = single-key compromise and mistakes;; 2 = single key risk;; 1 = delay;; 0 = none.
- EX011 — Timelock purpose. What does a timelock add? Rubric: 3 = time for users and monitors to see and respond;; 2 = visibility;; 1 = speed;; 0 = none.
- EX012 — Collusion limit. When do neither control help? Rubric: 3 = when keyholders collude;; 2 = collusion;; 1 = never;; 0 = none.
- EX013 — Secondary aim. What secondary aim did Tariq add? Rubric: 3 = whether timelock window allows detection and response;; 2 = window;; 1 = vague;; 0 = none.
- EX014 — Care confounder. What competing explanation did peers raise? Rubric: 3 = careful, well-funded teams adopt timelocks;; 2 = care;; 1 = luck;; 0 = none.
Synthesis
Privileged keys add trusted parties to blockchain systems, and controls like multi-signature and timelocks address distinct failures.
Continue studying — chapter 02 of 08
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →