Chapter 10 — Web3, blockchain and cryptoasset security: orientation
Lesson map
Lesson 10 published. Map, example, EX028.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Scope of the field"]
N2["10.2 Blocks, consensus and contracts"]
N3["10.3 Locating the makerspace's risks"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX028"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Scope of the field"]
N2["10.2 Blocks, consensus and contracts"]
N3["10.3 Locating the makerspace's risks"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX028"]
[Learning outcomes]
|
v
[10.1 Scope of the field]
|
v
[10.2 Blocks, consensus and contracts]
|
v
[10.3 Locating the makerspace's risks]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX028]
Learning outcomes
You will (1) outline the field's scope; (2) explain blocks, consensus and contracts; (3) locate the makerspace's risks.
10.1 Scope of the field
Web3, blockchain and cryptoasset security covers ledgers, smart contracts, keys and wallets, the services connecting them to the outside world and the people operating them. Lucas reads NIST IR 8202 for an overview of components and permission models and the OWASP Smart Contract Top 10 for common contract weaknesses. He notes that technologists work mostly on nodes, services, keys and monitoring rather than writing contracts, but must understand contracts well enough to operate them safely, read their events and recognise when something looks wrong in the data.
10.2 Blocks, consensus and contracts
A blockchain is a sequence of blocks, each containing transactions and the hash of the previous block, as described in Nakamoto's paper. Consensus lets nodes agree on the sequence; the makerspace's ledger uses voting among its three known nodes. Smart contracts, described in Buterin's whitepaper and Wood's yellow paper, are programs stored on the ledger and executed by every node. The credit contract keeps balances, enforces the cap and emits events. Lucas learns to read those events, because they are his main window into what the contract is doing.
10.3 Locating the makerspace's risks
Lucas places the makerspace's risks on his diagram. Consensus risk is low because the three nodes are known and controlled. Contract risk exists but the contract is small and was reviewed. Key risk is significant, since the issuer multisig controls credit creation. Service risk is significant, because the issuing service decides what is granted. Operational risk, from missed updates or poor monitoring, is where his work matters most. Ms Adebayo agrees and suggests his coursework focus on keys, services and operations, which matches where real losses most often arise in practice.
Worked example
Lucas rates consensus risk low, contract risk moderate and key, service and operational risks significant, focusing his work on the last three.
Synthetic case. The makerspace's risk picture is synthetic; NIST IR 8202, OWASP SC Top 10, Nakamoto, Buterin and Wood are real sources.
Errors and limits
Focusing on consensus in a small permissioned ledger neglects the keys and services where risk concentrates.
Exercises
- EX028 — Technologist focus. What do technologists mostly work on? Rubric: 3 = nodes, services, keys and monitoring;; 2 = operations;; 1 = writing contracts;; 0 = none.
- EX029 — Block link. What links each block to the previous one? Rubric: 3 = the previous block's hash;; 2 = hash;; 1 = a timestamp;; 0 = none.
- EX030 — Lowest risk. Which risk does Lucas rate lowest? Rubric: 3 = consensus;; 2 = consensus risk;; 1 = keys;; 0 = none.
Synthesis
Understanding the field's parts shows a technologist where risk actually lies.
Continue studying — chapter 10 of 30
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →