Chapter 28 — Web3, blockchain and cryptoasset security: implementation I

Chapter 28 — Web3, blockchain and cryptoasset security: implementation I

Lesson map

Lesson 28 published. Map, example, EX082.

flowchart TD
  N0["Learning outcomes"]
  N1["28.1 Minimal contract"]
  N2["28.2 Secure patterns"]
  N3["28.3 Documentation"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX082"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["28.1 Minimal contract"]
  N2["28.2 Secure patterns"]
  N3["28.3 Documentation"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX082"]

[Learning outcomes]
    |
    v
[28.1 Minimal contract]
    |
    v
[28.2 Secure patterns]
    |
    v
[28.3 Documentation]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX082]

Learning outcomes

You will (1) implement the minting contract defensively; (2) apply secure patterns; (3) document special code use.

28.1 Minimal contract

Jonas implements the minting contract in a test environment with only three functions: mint against a signed batch, read the hourly minted amount, and read configuration. It contains no upgrade mechanism, no external calls except to the credit token, and no low-level assembly. Keeping it minimal follows the design choice and makes review straightforward. Every line is justified in comments, and the contract is compiled with a pinned compiler version recorded in the build file. Jonas asks a classmate to read it for clarity before review.

28.2 Secure patterns

Where the contract calls the token to mint, Jonas applies the checks-effects-interactions pattern described in EthTrust and ConsenSys guidance: validate inputs, update the hourly counter, then make the external call. He checks the return value of every call. He avoids using the transaction originator for authorisation and uses the immediate caller instead, as EthTrust requires. Each pattern is linked to the weakness it prevents in the code comments, so reviewers can check that defences are present and understood. Tests confirm each pattern.

28.3 Documentation

EthTrust asks that special code use, such as external calls and use of block timestamps, be documented with how misuse is prevented. Jonas writes a short document listing each external call and timestamp use, its purpose and protections. The hourly cap uses block timestamps; he explains that small timestamp variations do not matter at hourly granularity. Documentation supports review and future maintenance, and forms part of the evidence for the verification laboratory. The document is stored with the code and versioned alongside it, so reviewers always see documentation matching the deployed version.

Worked example

The minimal minting contract has three functions, applies checks-effects-interactions, checks call returns, avoids transaction-originator authorisation and documents timestamp use.

Synthetic case. Code and documents are synthetic; EEA EthTrust and ConsenSys best practices are real sources.

Errors and limits

Adding unnecessary features to a high-value contract enlarges what reviewers must verify.

Exercises

• EX082 — Excluded features. Name one feature the minting contract omits. Rubric: 3 = upgrade mechanism;; 2 = assembly;; 1 = minting;; 0 = none.
• EX083 — CEI order. What is the checks-effects-interactions order? Rubric: 3 = validate, update state, then call externally;; 2 = CEI;; 1 = call first;; 0 = none.
• EX084 — Authorisation source. What is used for authorisation instead of the transaction originator? Rubric: 3 = the immediate caller;; 2 = msg.sender;; 1 = tx origin;; 0 = none.

Synthesis

Minimal, pattern-based and documented implementations make high-value contracts reviewable.

Continue studying — chapter 28 of 50

← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →