Chapter 27 — Web3, blockchain and cryptoasset security: verification

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Tests from invariants"]
  N2["27.2 Using test networks safely"]
  N3["27.3 Recording verification evidence"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Tests from invariants"]
  N2["27.2 Using test networks safely"]
  N3["27.3 Recording verification evidence"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Tests from invariants]
    |
    v
[27.2 Using test networks safely]
    |
    v
[27.3 Recording verification evidence]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) write tests from invariants; (2) use test networks safely; (3) record verification evidence.

27.1 Tests from invariants

Sofia turns each invariant into tests. After every test action, the test checks that total supply equals the sum of balances, no balance is negative and weekly issuance is within the cap. She writes tests for normal actions, edge cases and forbidden actions: an issuance by a non-minter must be refused, a transfer while paused must be refused, and a mint that would exceed the cap must be refused. Testing forbidden actions is as important as testing allowed ones, because security failures usually mean something forbidden became possible without anyone noticing.

27.2 Using test networks safely

All tests run on the cooperative's private test network with synthetic members and vouchers that have no value. Test keys are separate from production keys and are clearly labelled. Sofia never uses production keys in tests and never deploys test contracts to the live ledger. The test network is reset regularly. These boundaries mean mistakes during testing cannot affect real members. Dr Asante notes that confusion between test and production environments is a common cause of real incidents, so clear labelling and separation are themselves security controls, not mere tidiness or convenience.

27.3 Recording verification evidence

Sofia stores test results with the contract version, compiler version, test network block and date. A summary shows 42 tests, all passing, with the invariant checks run after each. When the developer changes the contract, the tests are rerun and the new results stored alongside the old. This record lets the board and any external reviewer see exactly what was verified and when. Verification evidence is only valuable if it clearly corresponds to the code actually deployed, so she records the deployed contract's code hash and compares it with the tested build.

Worked example

Sofia runs 42 invariant-checked tests, including forbidden actions, on a separate test network and matches the deployed code hash to the tested build.

Synthetic case. The tests and networks are synthetic.

Errors and limits

Using production keys on a test network risks real loss from test mistakes.

Exercises

• EX079 — Forbidden action test. Give one forbidden action that is tested.
  Show marking criteria

  Rubric: 3 = issuance by a non-minter;; 2 = transfer while paused;; 1 = normal transfer;; 0 = none.
• EX080 — Environment separation. Why keep test and production keys separate?
  Show marking criteria

  Rubric: 3 = test mistakes cannot affect real members;; 2 = isolation;; 1 = speed;; 0 = none.
• EX081 — Deployment match. How is tested code matched to deployed code?
  Show marking criteria

  Rubric: 3 = compare the deployed code hash with the tested build;; 2 = code hash;; 1 = by name;; 0 = none.

Synthesis

Invariant-based tests on separated networks, with matched records, give trustworthy verification.

Continue studying — chapter 27 of 40

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →