Chapter 2 — Computing systems

Lesson map

Lesson 02 published. Map, example, EX004.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Processors, memory and storage"]
  N2["2.2 How a ledger node runs"]
  N3["Synthesis"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Worked example"]
  EX --> Q["Exercise EX004"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Processors, memory and storage"]
  N2["2.2 How a ledger node runs"]
  N3["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> Q["EX004"]

[Learning outcomes]
    |
    v
[2.1 Processors, memory and storage]
    |
    v
[2.2 How a ledger node runs]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX004]

Learning outcomes

You will (1) describe processors, memory and storage; (2) explain how a node runs; (3) relate system limits to ledger behaviour.

2.1 Processors, memory and storage

A computer executes instructions on a processor, keeps working data in fast memory that is lost on power failure, and keeps durable data on storage such as solid-state drives. Sofia learns these parts because a blockchain node is simply a program on such a computer. The node keeps recent state in memory for speed and writes blocks to storage so they survive restarts. If storage fills up, the node stops accepting new blocks. If memory is too small, it slows down. Understanding the hardware helps her explain later why a node falls behind or refuses to start at the cooperative.

2.2 How a ledger node runs

A ledger node receives transactions and blocks over the network, checks them against the rules, executes contract code in a virtual machine, and stores the result. The Ethereum Virtual Machine, described in Wood's yellow paper, gives every node the same deterministic result for the same inputs, which is why nodes can agree. Sofia sketches the node as a pipeline: receive, validate, execute, store, share. Each stage consumes processor time, memory or disk. She notes that the cooperative's test ledger runs three validator nodes on small rented servers, so resource limits matter more than they would in a large data centre.

2.3 Limits and behaviour

Sofia lists what happens when each resource runs short. A busy processor delays validation, so blocks arrive late. Exhausted memory causes swapping and crashes. A full disk stops the node entirely. Clock drift between servers can confuse logs and timestamps. She proposes simple monitoring for disk use, memory and clock offset on each validator, with alerts well before limits are reached. Dr Asante points out that availability is a security property: if vouchers cannot be spent because nodes are down, members lose trust in the system just as surely as they would after a theft.

Worked example

Sofia maps a validator node as receive, validate, execute, store, share and sets alerts for disk, memory and clock offset on all three servers.

Synthetic case. The cooperative's servers and ledger are synthetic; Wood's yellow paper is a real source.

Errors and limits

Ignoring disk and clock limits leaves outages that look like software bugs.

Exercises

• EX004 — Validator count. How many validator nodes does the test ledger run?
  Show marking criteria

  Rubric: 3 = three;; 2 = 3;; 1 = one;; 0 = none.
• EX005 — Determinism source. Why can nodes agree on contract results?
  Show marking criteria

  Rubric: 3 = the EVM gives the same deterministic result for the same inputs;; 2 = determinism;; 1 = luck;; 0 = none.
• EX006 — Availability link. Why is availability treated as security here?
  Show marking criteria

  Rubric: 3 = members lose trust if vouchers cannot be spent;; 2 = outages harm;; 1 = unrelated;; 0 = none.

Synthesis

Knowing the computer under a node explains many ledger failures before they happen.

Continue studying — chapter 02 of 40

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →