◇ OpenCyber Academy
Engineering · Chapter 3 · English

Chapter 3 — Physics for computing

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 3 — Physics for computing

Lesson map

Lesson 03 published. Map, example, EX007.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Energy and computation"]
  N2["3.2 Meters as physical inputs"]
  N3["3.3 Device trust"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX007"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 Energy and computation"]
  N2["3.2 Meters as physical inputs"]
  N3["3.3 Device trust"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX007"]

[Learning outcomes]
    |
    v
[3.1 Energy and computation]
    |
    v
[3.2 Meters as physical inputs]
    |
    v
[3.3 Device trust]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX007]

Learning outcomes

You will (1) relate energy and physical limits to computing; (2) explain why physical meters matter; (3) reason about device trust.

3.1 Energy and computation

Every computation consumes energy, and blockchains make this visible. Nakamoto's design secures Bitcoin through proof of work, where miners spend electricity to propose blocks. Brightwater's permissioned ledger instead uses a small set of known validator nodes, so it consumes little energy, but it trusts those operators. Jonas compares the two in terms of physical cost and trust assumptions, as NIST IR 8202 does in its discussion of consensus models. He concludes that the cooperative's choice suits a small community where members know the operators, but that it shifts security onto node governance.

3.2 Meters as physical inputs

The token system starts with physics: solar panels generate electricity measured by smart meters, which report readings that become credits. If a meter is faulty, tampered with or misconfigured, the ledger faithfully records wrong data. Jonas learns that a blockchain guarantees the integrity of what is recorded, not the truth of what was measured. He studies meter accuracy classes and calibration intervals, and notes that physical plausibility checks, such as comparing generation with sunlight data, are needed at the boundary between the physical and digital worlds.

3.3 Device trust

Meters are small computers with firmware, clocks and network connections. Jonas lists ways their readings could be wrong without anyone intending harm: clock drift misaligning hourly totals, power cuts causing missing data and firmware bugs. He proposes that each meter sign its readings with a device key, so the ledger can at least confirm which device sent which reading. Signing does not prove the reading is accurate, but it stops readings being silently attributed to the wrong household, which is a common source of disputes.

Worked example

Jonas compares proof-of-work and permissioned consensus by energy and trust, and proposes signed meter readings plus plausibility checks against sunlight data.

Synthetic case. Meters, readings and the cooperative are synthetic; Nakamoto (2008) and NIST IR 8202 are real sources.

Errors and limits

Assuming a blockchain makes meter data true ignores the physical input boundary.

Exercises

Synthesis

Physical inputs and device trust bound what any ledger can guarantee.

Continue studying — chapter 03 of 50

← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →