Chapter 22 — Web3, blockchain and cryptoasset security: system and data models

Chapter 22 — Web3, blockchain and cryptoasset security: system and data models

Lesson map

Lesson 22 published. Map, example, EX064.

flowchart TD
  N0["Learning outcomes"]
  N1["22.1 State model"]
  N2["22.2 Roles and flows"]
  N3["22.3 Checking models"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX064"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["22.1 State model"]
  N2["22.2 Roles and flows"]
  N3["22.3 Checking models"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX064"]

[Learning outcomes]
    |
    v
[22.1 State model]
    |
    v
[22.2 Roles and flows]
    |
    v
[22.3 Checking models]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX064]

Learning outcomes

You will (1) model contract state and transitions; (2) model roles and data flows; (3) check models against requirements.

22.1 State model

Jonas models the credit contract as a state machine. State includes balances, total supply, the hourly minted amount, the paused flag and role assignments. Transitions are mint, transfer, burn, pause, unpause and role changes, each with preconditions and effects. Writing the model before code clarifies questions: does pausing stop burning for redemption? He decides it should not, so members can still redeem during an investigation, and records this as a requirement. A state model is the specification against which code and tests are later checked.

22.2 Roles and flows

A role model lists each role, who holds it and what transitions it may perform: holders transfer and burn their own credits; the minting role, held by the gateway's multi-signature wallet, mints; the governance role, held by the board multi-signature with timelock, changes parameters; the pauser role, held by a two-of-five board wallet, pauses. Data-flow diagrams show readings moving from meters to the gateway, batches to the contract and redemption events to the utility. Together, these models show who can change what, and where data goes.

22.3 Checking models

Jonas checks the models against requirements using the traceability matrix. He finds one gap: the model lets the governance role change the minting cap without limit, so a mistaken change could allow far more minting than generation supports. He adds a requirement that the cap cannot exceed the capacity bound defined in configuration, itself changeable only through governance with a timelock. Checking models before implementation finds design errors when they are cheapest to fix, long before code exists. The fix is traced in the matrix.

Worked example

The state model clarifies that burning continues while paused; a model check finds an unbounded cap change and adds a capacity limit.

Synthetic case. Models and roles are synthetic.

Errors and limits

Writing code before modelling state and roles leaves design gaps to be discovered in production.

Exercises

• EX064 — Pause decision. Does pausing stop burning for redemption? Rubric: 3 = no, members can still redeem;; 2 = no;; 1 = yes;; 0 = none.
• EX065 — Minting role holder. Who holds the minting role? Rubric: 3 = the gateway's multisig wallet;; 2 = gateway multisig;; 1 = a member;; 0 = none.
• EX066 — Model gap. What gap did the model check find? Rubric: 3 = unbounded cap change by governance;; 2 = cap;; 1 = vague;; 0 = none.

Synthesis

State, role and data-flow models make designs checkable against requirements before implementation.

Continue studying — chapter 22 of 50

← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →