Chapter 20 — Web3, blockchain and cryptoasset security: engineering context
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 The system in context"]
N2["20.2 Stakeholders and constraints"]
N3["20.3 The engineering problem"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 The system in context"]
N2["20.2 Stakeholders and constraints"]
N3["20.3 The engineering problem"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 The system in context]
|
v
[20.2 Stakeholders and constraints]
|
v
[20.3 The engineering problem]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) describe the cooperative's token system in context; (2) identify stakeholders and constraints; (3) define the engineering problem.
20.1 The system in context
Entering the specialist part of the degree, Jonas restates the engineering problem. Brightwater wants members to earn credits for solar generation and spend them on energy bills or transfer them to neighbours. The system must be accurate, available, private for household data and understandable to members. It runs on the cooperative's permissioned ledger with two partner validators. Constraints include a small budget, one part-time developer, members with varying digital skills and regulatory obligations around financial records. He writes these down as the project's starting facts.
20.2 Stakeholders and constraints
Jonas revisits stakeholders with new detail. Members want reliability and simplicity; the board wants accountability and low risk; partners want clear operating agreements; the utility wants accurate redemption data; auditors want evidence. Constraints shape solutions: with one developer, the design must be simple enough to maintain; with limited budget, external audits must be targeted. He records each constraint and how it influences choices, so that later designs can be judged against reality, not an ideal. The board confirms the list before design starts.
20.3 The engineering problem
Jonas writes the problem statement: design, implement and verify a credit token system and its operations so that credits are issued only for verified generation, transferred only by their holders, redeemable reliably, and governed by accountable, transparent controls, while keeping household data private. Each phrase becomes a requirement area in the next chapter. A precise problem statement keeps a multi-year project focused and gives reviewers a standard against which to judge the final result. Dr Nwosu and the board approve the statement as written.
Worked example
Jonas writes a one-paragraph problem statement covering issuance, transfer, redemption, governance and privacy, with recorded constraints.
Synthetic case. The cooperative, stakeholders and constraints are synthetic.
Errors and limits
Starting design without stating constraints leads to solutions the cooperative cannot maintain.
Exercises
- EX058 — Credit uses. What can members do with credits? Rubric: 3 = spend on bills or transfer to neighbours;; 2 = spend;; 1 = mine;; 0 = none.
- EX059 — Developer constraint. What does having one developer imply? Rubric: 3 = design must be simple to maintain;; 2 = simplicity;; 1 = vague;; 0 = none.
- EX060 — Problem areas. Name two requirement areas from the statement. Rubric: 3 = issuance and governance;; 2 = transfer, privacy;; 1 = colour;; 0 = none.
Synthesis
A clear problem statement grounded in stakeholders and constraints frames the specialist engineering work.
Continue studying — chapter 20 of 50
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →