Chapter 6 — Web3, blockchain and cryptoasset security: system model
Lesson map
Lesson 06 published. Map, example, EX021.
flowchart TD
N0["Learning outcomes"]
N1["6.1 States and actions"]
N2["6.2 Rules of the system"]
N3["6.3 Who can change what"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX021"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 States and actions"]
N2["6.2 Rules of the system"]
N3["6.3 Who can change what"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX021"]
[Learning outcomes]
|
v
[6.1 States and actions]
|
v
[6.2 Rules of the system]
|
v
[6.3 Who can change what]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX021]
Learning outcomes
You will (1) describe the deposit token system as states and actions; (2) list its rules; (3) identify who can change what.
6.1 States and actions
Aiko models the deposit system. Its state includes each borrower address's token balance, the library's holding balance, the paused flag and the role list. Actions are issue deposit tokens to a borrower when they pay, lock a deposit when a tool is borrowed, release it when the tool is returned, transfer, pause and change roles. For each action she lists who may perform it and what it changes. A model like this lets a technician understand what normal activity looks like in the ledger's events and spot actions that do not fit.
6.2 Rules of the system
Aiko lists the rules the system must keep: the total of all balances equals tokens issued minus tokens redeemed; no balance is negative; a deposit is released only when the database shows the tool returned; and only the library's 2-of-3 staff multisig can issue tokens. These rules come from the developer's documentation and the library's policy. Writing them down gives Aiko clear things to check. Later chapters turn each rule into an automatic check that reads ledger events and the database and reports any difference.
6.3 Who can change what
Aiko records roles: borrowers can transfer their own tokens; the deposit service can request locks and releases; the staff multisig can issue tokens and approve releases above a threshold; an administrator role behind a 48-hour timelock can change roles; and two staff can pause. The OWASP Smart Contract Top 10 lists access control failures among the most common weaknesses. Knowing exactly who can change what tells a technician which ledger events need the closest watching, especially role changes and pauses. A written role table also gives reviewers something concrete to compare against the deployed configuration.
Worked example
Aiko models six actions and four rules, and records that only the 2-of-3 staff multisig issues tokens while role changes wait 48 hours.
Synthetic case. The system model is synthetic; the OWASP Smart Contract Top 10 is a real source.
Errors and limits
Watching all events equally misses the role changes and pauses that matter most.
Exercises
- EX021 — Deposit release rule. When may a deposit be released? Rubric: 3 = when the database shows the tool returned;; 2 = on return;; 1 = anytime;; 0 = none.
- EX022 — Supply rule. State the supply rule. Rubric: 3 = balances total issued minus redeemed;; 2 = totals match;; 1 = supply grows;; 0 = none.
- EX023 — Issuer role. Who can issue tokens? Rubric: 3 = the 2-of-3 staff multisig;; 2 = multisig;; 1 = the deposit service;; 0 = none.
- EX024 — Pause holders. Who can pause the system? Rubric: 3 = two staff;; 2 = 2 staff;; 1 = any borrower;; 0 = none.
Synthesis
A state, rule and role model shows a technician what normal looks like and what to watch.
Continue studying — chapter 06 of 18
← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →