Chapter 41 — Web3, blockchain and cryptoasset security: system optimization
Lesson map
Lesson 41 published. Map, example, EX121.
flowchart TD
N0["Learning outcomes"]
N1["41.1 What to optimise"]
N2["41.2 Gas and storage"]
N3["41.3 Measuring effects"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX121"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["41.1 What to optimise"]
N2["41.2 Gas and storage"]
N3["41.3 Measuring effects"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX121"]
[Learning outcomes]
|
v
[41.1 What to optimise]
|
v
[41.2 Gas and storage]
|
v
[41.3 Measuring effects]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX121]
Learning outcomes
You will (1) optimise cost and performance without weakening controls; (2) evaluate gas and storage choices; (3) measure the effect of changes.
41.1 What to optimise
After production readiness, Jonas looks for improvements. Candidates include reducing transaction costs on the ledger, shortening statement generation, and reducing the time from a queued privileged action to monitor confirmation. He ranks candidates by member benefit and risk of introducing defects. He sets a rule that no optimisation may remove or weaken a control listed in the architecture document, and that every optimisation must be measured before and after, so that improvements are real rather than assumed. The board agrees the rule and the ranking.
41.2 Gas and storage
Wood's yellow paper assigns gas costs to each operation, with storage writes among the most expensive. Jonas finds that the transfer contract writes a redundant timestamp for each transfer, used only by the app. Removing it saves gas but requires the app to read event logs instead. He evaluates the change with the full test suite and an external reviewer's quick check, because even small contract changes go through the upgrade path. The saving per transfer is modest, but over years it reduces member fees noticeably.
41.3 Measuring effects
Jonas measures each optimisation: gas per transfer falls by about eleven percent after removing the redundant write; incremental reconciliation cuts the weekly check from 25 minutes to four; and adding a second on-call contact reduces median monitor confirmation from nine hours to five. He records results in the metrics report. Measurement prevents optimisations being judged by how clever they feel, and shows the board which changes delivered value. Each result is compared with the previous three months to confirm that the improvement is stable rather than a one-off.
Worked example
Removing a redundant storage write saves about 11% gas per transfer; incremental reconciliation cuts weekly checks from 25 to 4 minutes; median confirmation falls from 9 to 5 hours.
Synthetic case. Measurements and changes are synthetic; Wood's yellow paper is a real source.
Errors and limits
Optimising contract code by removing checks to save gas trades security for small savings.
Exercises
- EX121 — Optimisation rule. What rule constrains optimisation? Rubric: 3 = no control may be removed or weakened;; 2 = keep controls;; 1 = vague;; 0 = none.
- EX122 — Gas saving. How much gas per transfer was saved? Rubric: 3 = about eleven percent;; 2 = 11%;; 1 = half;; 0 = none.
- EX123 — Confirmation change. How did median confirmation change? Rubric: 3 = nine hours to five;; 2 = faster;; 1 = slower;; 0 = none.
Synthesis
Measured optimisations that preserve every control improve cost and responsiveness safely.
Continue studying — chapter 41 of 50
← Chapter 40 (draft) · Course chapter index · Chapter 42 (draft) →