Chapter 26 — Web3, blockchain and cryptoasset security: architecture alternatives
Lesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 Criteria"]
N2["26.2 Upgradeability options"]
N3["26.3 Selection"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 Criteria"]
N2["26.2 Upgradeability options"]
N3["26.3 Selection"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 Criteria]
|
v
[26.2 Upgradeability options]
|
v
[26.3 Selection]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) compare architectures with criteria; (2) analyse upgradeability options; (3) select and justify an architecture.
26.1 Criteria
Jonas compares the two alternatives using weighted criteria agreed with the board: security of minting, reviewability, upgrade safety, operational simplicity and cost. Each criterion has a definition and a scoring guide from one to three. He scores both designs with a partner engineer, who scores independently first. Differences are discussed and reasons recorded. Weighted criteria make the comparison transparent, so that the board can see why a recommendation was made and challenge specific scores. The criteria and weights are agreed before any design is scored, so they cannot be tuned to favour one option.
26.2 Upgradeability options
Both designs must handle future changes. Options include deploying immutable contracts and migrating to new ones when needed, or using a proxy pattern where the code behind an address can be replaced. The EthTrust specification explains that proxies mean the system cannot be treated as immutable, and that each new implementation needs review. Jonas recommends a proxy only for the transfer contract, with upgrades requiring three of five keyholders and a 48-hour timelock, and an immutable minting contract that is simple enough to replace by migration.
26.3 Selection
The split design scores 2.6 against 2.2 for the single contract, mainly because the minimal minting contract is easier to review and does not need upgradeability. Jonas presents the result with its sensitivity: if operational simplicity were weighted twice as heavily, the single contract would win narrowly. The board selects the split design, accepting extra interface testing. Reporting sensitivity shows decision-makers how robust a recommendation is, rather than presenting a single number as certain. The decision record includes the scores, weights and sensitivity result.
Worked example
The split design scores 2.6 against 2.2; sensitivity shows the result would reverse if simplicity were weighted double; the board selects the split design.
Synthetic case. Scores and designs are synthetic; EEA EthTrust is a real source.
Errors and limits
Presenting a weighted score without its sensitivity hides how fragile the choice may be.
Exercises
- EX076 — Independent scoring. Why does the partner score independently first? Rubric: 3 = to expose differences in judgement;; 2 = independence;; 1 = speed;; 0 = none.
- EX077 — Proxy use. Where is a proxy used? Rubric: 3 = only for the transfer contract;; 2 = transfer;; 1 = everywhere;; 0 = none.
- EX078 — Final scores. What were the final scores? Rubric: 3 = split 2.6, single 2.2;; 2 = 2.6 vs 2.2;; 1 = equal;; 0 = none.
Synthesis
Transparent criteria, careful upgrade choices and sensitivity analysis justify architecture selection.
Continue studying — chapter 26 of 50
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →