Chapter 11 — Web3, blockchain and cryptoasset security: verification
Lesson map
Lesson 11 published. Map, example, EX041.
flowchart TD
N0["Learning outcomes"]
N1["11.1 Planned tests"]
N2["11.2 Using the test ledger safely"]
N3["11.3 Recording results"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX041"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["11.1 Planned tests"]
N2["11.2 Using the test ledger safely"]
N3["11.3 Recording results"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX041"]
[Learning outcomes]
|
v
[11.1 Planned tests]
|
v
[11.2 Using the test ledger safely]
|
v
[11.3 Recording results]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX041]
Learning outcomes
You will (1) verify controls with planned tests; (2) use the test ledger safely; (3) record verification results.
11.1 Planned tests
Aiko writes a verification plan listing each control and how to test it. A single staff signature must not issue tokens. A release for a loan not marked returned must be refused. An administrator change must wait 48 hours. An outside computer must not reach node interfaces. A login with a shared account must fail. Each test has an expected result. Planning tests in advance ensures nothing is forgotten and that results can be compared with expectations objectively rather than interpreted after the fact.
11.2 Using the test ledger safely
All ledger tests run on the library's separate test ledger with synthetic borrowers and tokens of no value. Test keys are clearly labelled and kept apart from live keys. Aiko never uses live keys for testing and never sends test transactions to the live ledger. The test ledger is reset after each round. Mr Kowal explains that confusing test and live environments is a common cause of real incidents, so separation and labelling are themselves important controls, not just good housekeeping practices.
11.3 Recording results
Aiko records each test: date, environment, steps, expected and actual result. Four of five tests pass. The release test fails: a release for a loan not yet returned succeeds on the test ledger, because the deposit service checks the database but the database's test copy marked all loans returned by default. She reports it, the test data is corrected and the test passes. The finding shows that tests depend on realistic data. She stores the results with the configuration and contract versions tested.
Synthetic case. The tests and results are synthetic.
Errors and limits
Testing with unrealistic data can make a control appear broken or working when it is not.
Exercises
- EX041 — Planned test. Name one planned test. Rubric: 3 = a single signature must not issue tokens;; 2 = release refused for unreturned loan;; 1 = deploy to live;; 0 = none.
- EX042 — Key separation. How are test keys kept apart? Rubric: 3 = clearly labelled and separate from live keys;; 2 = labelled;; 1 = shared;; 0 = none.
- EX043 — Failing test. Which test failed at first? Rubric: 3 = the release test for an unreturned loan;; 2 = release;; 1 = timelock;; 0 = none.
- EX044 — Failure cause. Why did it fail? Rubric: 3 = test data marked all loans returned by default;; 2 = bad test data;; 1 = code bug;; 0 = none.
Synthesis
Planned tests on a separate ledger, with recorded results, verify controls honestly.
Continue studying — chapter 11 of 18
← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →