Chapter 39 — Web3, blockchain and cryptoasset security: maintainability | Engineering Web3, blockchain and cryptoasset security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 39 — Web3, blockchain and cryptoasset security: maintainability

Lesson map

Lesson 39 published. Map, example, EX115.

flowchart TD
  N0["Learning outcomes"]
  N1["39.1 Maintenance plan"]
  N2["39.2 Managing upgrades"]
  N3["39.3 Transferable knowledge"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX115"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["39.1 Maintenance plan"]
  N2["39.2 Managing upgrades"]
  N3["39.3 Transferable knowledge"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX115"]

[Learning outcomes]
    |
    v
[39.1 Maintenance plan]
    |
    v
[39.2 Managing upgrades]
    |
    v
[39.3 Transferable knowledge]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX115]

Learning outcomes

You will (1) plan long-term maintenance; (2) manage upgrades and dependency changes; (3) keep knowledge transferable.

39.1 Maintenance plan

Contracts may run for years, but everything around them changes: compilers, libraries, network software and people. Jonas writes a maintenance plan covering scheduled reviews of dependencies, monitoring of security advisories for the compiler and libraries, annual review of role assignments and keyholders, and a budget for re-review when upgrades are needed. The EthTrust specification notes that network upgrades can change how code behaves and that certifications apply only to specified virtual machine versions, so the plan includes checking each ledger software upgrade.

39.2 Managing upgrades

Each upgrade of the transfer contract follows a defined path: change request, design note, implementation on a branch, tests including invariants and end-to-end runs, review by a second engineer or external reviewer, queuing with the timelock, member notice and post-upgrade verification. Jonas tests the path once with a trivial change on the test network to find friction, such as unclear responsibility for member notices. A rehearsed upgrade path reduces the temptation to bypass controls when an urgent fix is needed.

39.3 Transferable knowledge

With one developer, knowledge loss is a major risk. Jonas ensures that runbooks, decision records, architecture documents and scripts are complete and stored in the repository, and that a second person from a partner organisation can deploy to the test network unaided. He records a short video walkthrough of the system for future staff. Maintainability is a security property: a system nobody understands will eventually be changed unsafely or left unpatched. The partner engineer's notes on unclear steps are used to improve the runbooks.

Worked example

A maintenance plan covers dependencies, advisories, keyholders and network upgrades; a trial upgrade finds unclear notice responsibility; a partner engineer deploys to test unaided.

Synthetic case. Plans and people are synthetic; EEA EthTrust is a real source.

Errors and limits

Assuming deployed contracts need no maintenance ignores changing compilers, libraries and networks.

Exercises

EX115 — Network upgrade issue. Why check ledger software upgrades? Rubric: 3 = they can change code behaviour;; 2 = behaviour changes;; 1 = vague;; 0 = none.
EX116 — Trial friction. What did the trial upgrade reveal? Rubric: 3 = unclear responsibility for member notices;; 2 = notices;; 1 = vague;; 0 = none.
EX117 — Knowledge test. How is knowledge transfer tested? Rubric: 3 = partner engineer deploys to test unaided;; 2 = second person;; 1 = quiz;; 0 = none.

Synthesis

Planned maintenance, rehearsed upgrades and transferable knowledge keep the system secure over years.

Continue studying — chapter 39 of 50

← Chapter 38 (draft) · Course chapter index · Chapter 40 (draft) →