Chapter 36 — Web3, blockchain and cryptoasset security: performance and scale
Lesson map
Lesson 36 published. Map, example, EX106.
flowchart TD
N0["Learning outcomes"]
N1["36.1 Estimating load"]
N2["36.2 Bottlenecks"]
N3["36.3 Growth without weakening security"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX106"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["36.1 Estimating load"]
N2["36.2 Bottlenecks"]
N3["36.3 Growth without weakening security"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX106"]
[Learning outcomes]
|
v
[36.1 Estimating load]
|
v
[36.2 Bottlenecks]
|
v
[36.3 Growth without weakening security]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX106]
Learning outcomes
You will (1) estimate load and costs; (2) identify bottlenecks; (3) plan for growth without weakening security.
36.1 Estimating load
Jonas estimates load: 400 households produce hourly readings, giving about 9,600 readings per day, batched into 24 minting transactions. Transfers and redemptions add perhaps 300 transactions per day. The permissioned ledger handles this easily. He then models growth to 2,000 households if neighbouring villages join. Load is still modest, but database size and statement generation grow linearly. Estimating load with simple arithmetic prevents both over-engineering and surprises when growth arrives. He records the assumptions behind each estimate and plans to compare them with measured load each quarter, adjusting the model when real data differ.
36.2 Bottlenecks
The analysis identifies bottlenecks: statement generation takes 40 minutes nightly at current size and would take over three hours at 2,000 households; the reconciliation script reads entire snapshots; and the gateway processes batches sequentially. Jonas notes that none is a contract problem, but each affects reliability and the timeliness of security checks. Slow reconciliation, for example, means mismatches are found later. He proposes incremental reconciliation and parallel statement generation. He measures each bottleneck on the test network to confirm the estimates, and finds the statement estimate accurate within ten percent, which gives confidence in the growth plan.
36.3 Growth without weakening security
Jonas warns against scaling shortcuts that weaken controls, such as raising the minting cap without changing the capacity bound, or batching privileged actions to save effort. Growth plans must keep the same controls: new villages' meters must be signed and registered, new capacity must be reflected in configuration through governance with a timelock, and monitoring thresholds must be recalculated. He adds these to the growth plan so that performance changes are reviewed for security effects. The board approves the plan with these conditions.
Worked example
Load of about 9,600 readings and 300 transactions per day is modest; statement generation would exceed three hours at 2,000 households, prompting incremental and parallel processing.
Synthetic case. Loads, times and plans are synthetic.
Errors and limits
Raising caps or bypassing reviews to cope with growth weakens the controls that protect members.
Exercises
- EX106 — Daily readings. How many readings per day at 400 households? Rubric: 3 = about 9,600;; 2 = 9600;; 1 = 400;; 0 = none.
- EX107 — Statement bottleneck. How long would statements take at 2,000 households? Rubric: 3 = over three hours;; 2 = three hours;; 1 = 40 minutes;; 0 = none.
- EX108 — Growth control. How must new capacity be reflected? Rubric: 3 = in configuration through governance with a timelock;; 2 = governance;; 1 = directly;; 0 = none.
Synthesis
Simple load estimates and security-aware growth plans let the platform scale safely.
Continue studying — chapter 36 of 50
← Chapter 35 (draft) · Course chapter index · Chapter 37 (draft) →