OpenCyber Academy
Bachelor's · Chapter 20 · English
Course code: OCA-101Chapter 20: OCA-101-C020

Chapter 20 — Web3, blockchain and cryptoasset security: foundational cases

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 20 published. Map, example, EX058.

flowchart TD
  N0["Learning outcomes"]
  N1["20.1 Learning from published research"]
  N2["20.2 General lessons"]
  N3["20.3 Applying lessons safely"]
  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 Learning from published research"]
  N2["20.2 General lessons"]
  N3["20.3 Applying lessons safely"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]
[Learning outcomes]
    |
    v
[20.1 Learning from published research]
    |
    v
[20.2 General lessons]
    |
    v
[20.3 Applying lessons safely]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX058]

Learning outcomes

You will (1) study weakness classes through published research; (2) extract general lessons; (3) apply lessons safely.

20.1 Learning from published research

Sofia studies foundational research rather than attack recipes. Atzei, Bartoletti and Cimoli's 2017 survey classifies weaknesses in Ethereum contracts, such as unexpected interactions between contracts and mistakes in handling calls. Luu and colleagues' 2016 paper describes how contract behaviour can depend on transaction ordering and other conditions developers do not control. Both papers help her understand categories of weakness at a conceptual level. She reads them for lessons about design, not for procedures. Dr Asante asks each student to summarise one weakness class in a paragraph a board member could understand.

20.2 General lessons

From the research Sofia extracts three lessons. First, contracts interact with other contracts and with unpredictable ordering, so they must be written to remain correct whatever happens between steps. Second, assumptions about the environment, such as timing or who calls a function, must be checked in code. Third, many weaknesses fall into known classes, catalogued in the SWC registry, so reviewers can check systematically. She summarises each lesson in plain words. The lessons apply to the voucher contract even though it is simple, because simplicity reduces but does not remove the risk of such assumptions.

20.3 Applying lessons safely

Sofia reviews the voucher contract design against the three lessons. She confirms that balances are updated before any external interaction, that role checks are made in every privileged function, and that no function depends on block timestamps for important decisions. She records each check and its result. She does not attempt to break the contract or write any attack code; review is done by reading and by testing expected behaviour on the test ledger with synthetic data. Applying lessons this way improves security without creating anything that could harm others if shared beyond the course.

Worked example

Sofia checks the voucher contract for state updates before external interaction, role checks on privileged functions and no timestamp-dependent decisions.

Synthetic case. The contract review is synthetic; Atzei et al. (2017), Luu et al. (2016) and the SWC registry are real sources.

Errors and limits

Reading research for procedures rather than lessons risks producing harmful material.

Exercises

Synthesis

Published research teaches weakness classes that guide careful, defensive review.

Continue studying — chapter 20 of 40

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

Worked answers

EX058. The 2017 survey by Atzei, Bartoletti and Cimoli.

EX059. Assumptions about timing or callers must be checked in code.

EX060. By reading the design and testing expected behaviour on the test ledger with synthetic data.