Chapter 19 — Web3, blockchain and cryptoasset security: scope and theory
Lesson map
Lesson 19 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes"]
N1["19.1 Scope of the field"]
N2["19.2 Consensus and contracts"]
N3["19.3 Theory applied to the cooperative"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX055"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["19.1 Scope of the field"]
N2["19.2 Consensus and contracts"]
N3["19.3 Theory applied to the cooperative"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX055"]
[Learning outcomes]
|
v
[19.1 Scope of the field]
|
v
[19.2 Consensus and contracts]
|
v
[19.3 Theory applied to the cooperative]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes
You will (1) define the field's scope; (2) explain consensus and smart contracts; (3) relate theory to the cooperative.
19.1 Scope of the field
Web3, blockchain and cryptoasset security covers the ledgers themselves, the smart contracts running on them, the keys and wallets that control assets, the off-chain services that feed and read them, and the people and processes around them. Sofia draws this scope as concentric rings around the voucher contract. NIST IR 8202 describes blockchain components and permission models, and the OWASP Smart Contract Top 10 lists common contract weaknesses. She notes that many real losses arise outside contract code, in key handling and operations, so the field's scope must include those areas even when they seem ordinary or familiar.
19.2 Consensus and contracts
Consensus lets independent nodes agree on one history. Nakamoto's design uses proof of work; Ethereum later moved to proof of stake; permissioned ledgers often use voting among known validators. Smart contracts are programs stored on the ledger and executed by every node, as described in Buterin's whitepaper and Wood's yellow paper. Their code is public on most ledgers and hard to change once deployed. Sofia notes the security consequence: mistakes in contract code are visible to everyone and difficult to fix, so careful design and review before deployment matter more than in ordinary software, where patches are routine.
19.3 Theory applied to the cooperative
Sofia applies the theory. The cooperative's ledger uses voting among three known validators, so agreement depends on at least two being honest and online. The voucher contract enforces the weekly cap and role checks. Keys control minting, pausing and administration. The shift database and issuing service sit outside the ledger but determine what is minted. She concludes that the cooperative's main risks lie in keys, the issuing service and the contract's role logic, rather than in consensus. This conclusion directs her studies: she will spend most effort where the risk actually lies.
Worked example
Sofia concludes that keys, the issuing service and role logic, not consensus among three validators, carry the cooperative's main risks.
Synthetic case. The cooperative's system is synthetic; NIST IR 8202, OWASP SC Top 10, Nakamoto, Buterin and Wood are real sources.
Errors and limits
Focusing only on contract code misses losses arising from keys and operations.
Exercises
- EX055 — Field scope. Name one area inside the field's scope beyond contracts. Rubric: 3 = keys and wallets;; 2 = off-chain services;; 1 = office furniture;; 0 = none.
- EX056 — Validator agreement. How many validators must be honest and online? Rubric: 3 = at least two of three;; 2 = two;; 1 = all three;; 0 = none.
- EX057 — Main risks. Where does Sofia place the cooperative's main risks? Rubric: 3 = keys, the issuing service and role logic;; 2 = keys;; 1 = consensus;; 0 = none.
Synthesis
The field spans ledgers, contracts, keys, services and people, and risk guides where to focus.
Continue studying — chapter 19 of 40
← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →