Chapter 31 — Web3, blockchain and cryptoasset security: implementation II
Lesson map
Lesson 31 published. Map, example, EX091.
flowchart TD
N0["Learning outcomes"]
N1["31.1 Transfer contract"]
N2["31.2 Initialisation and upgrades"]
N3["31.3 Preparing for review"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX091"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["31.1 Transfer contract"]
N2["31.2 Initialisation and upgrades"]
N3["31.3 Preparing for review"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX091"]
[Learning outcomes]
|
v
[31.1 Transfer contract]
|
v
[31.2 Initialisation and upgrades]
|
v
[31.3 Preparing for review]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX091]
Learning outcomes
You will (1) implement the transfer contract and proxy safely; (2) protect initialisation; (3) prepare for review.
31.1 Transfer contract
Jonas implements the transfer contract behind a proxy, as selected in the architecture. The contract supports transfer, burn for redemption and read functions, and enforces non-negative balances and positive amounts. He reuses a widely reviewed open-source token implementation at a pinned version rather than writing token logic from scratch, adding only the cooperative's specific rules. Reusing reviewed code reduces the amount of new code to verify, but he still reads the library's documentation and known issues before adopting it, recording the version and reasons in a decision record.
31.2 Initialisation and upgrades
Proxied contracts are configured by an initialiser function rather than a constructor. The EthTrust specification warns that many protocols have suffered because initialisers were left unprotected or not called in the same transaction as deployment. Jonas deploys and initialises in one transaction, sets roles to the board multi-signature during initialisation, and disables re-initialisation afterwards. The upgrade function is restricted to the governance role with a 48-hour timelock. He documents the deployment script so that the process can be repeated exactly on the test network and later in production.
31.3 Preparing for review
Before external review, Jonas prepares a review pack: the requirements, state and role models, architecture decision, source code at a tagged version, compiler settings, test results, invariant replays, documentation of special code use and known limitations. The EthTrust specification lists compiler options and metadata as part of a conformance claim, so he includes them. A complete pack lets reviewers spend time on finding problems rather than reconstructing context, which improves the value of limited review budgets. Reviewers confirm the pack was complete when they begin.
Worked example
The transfer contract reuses a pinned, reviewed library; deployment and initialisation occur in one transaction with re-initialisation disabled; a full review pack is prepared.
Synthetic case. Contracts, scripts and packs are synthetic; EEA EthTrust is a real source.
Errors and limits
Leaving an initialiser callable after deployment can let someone else take control of a proxied contract.
Exercises
- EX091 — Library reuse. Why reuse a reviewed token implementation? Rubric: 3 = less new code to verify;; 2 = reviewed;; 1 = cheaper only;; 0 = none.
- EX092 — Initialiser protection. How is the initialiser protected? Rubric: 3 = called in deployment transaction, then disabled;; 2 = same transaction;; 1 = left open;; 0 = none.
- EX093 — Pack contents. Name two items in the review pack. Rubric: 3 = models and compiler settings;; 2 = tests, docs;; 1 = vague;; 0 = none.
Synthesis
Reused reviewed code, protected initialisation and complete review packs make upgradeable contracts safer.
Continue studying — chapter 31 of 50
← Chapter 30 (draft) · Course chapter index · Chapter 32 (draft) →