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
- EX058 — Survey source. Which 2017 survey classifies Ethereum contract weaknesses?
Show marking criteria
Rubric: 3 = Atzei, Bartoletti and Cimoli;; 2 = Atzei;; 1 = Nakamoto;; 0 = none. - EX059 — Environment lesson. What lesson concerns the environment?
Show marking criteria
Rubric: 3 = check assumptions about timing and callers in code;; 2 = check assumptions;; 1 = ignore it;; 0 = none. - EX060 — Review method. How does Sofia review without attacking?
Show marking criteria
Rubric: 3 = reading and testing expected behaviour with synthetic data;; 2 = reading;; 1 = attack code;; 0 = none.
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) →