Chapter 8 — Computer architecture

Lesson map

Lesson 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Machines and programs"]
  N2["8.2 The Ethereum virtual machine"]
  N3["Synthesis"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Machines and programs"]
  N2["8.2 The Ethereum virtual machine"]
  N3["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 Machines and programs]
    |
    v
[8.2 The Ethereum virtual machine]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) describe how processors, memory and storage run programs; (2) explain the EVM as a virtual machine; (3) relate architecture to cost and limits.

8.1 Machines and programs

A processor fetches instructions from memory, executes them and stores results, guided by a program counter. Jonas studies registers, memory hierarchy and storage, learning why reading from disk is far slower than from memory. These ideas carry over to virtual machines, which are programs that imitate a processor. Understanding the layers helps him reason about where things can go wrong: a correct program can still fail if the machine beneath it behaves differently from what the programmer assumed. He relates each layer to ledger nodes.

8.2 The Ethereum virtual machine

Wood's yellow paper specifies the Ethereum virtual machine, a stack-based machine with its own instructions, memory and persistent storage for each contract. Every instruction has a gas cost, which limits how much computation a transaction can perform. Brightwater's ledger runs a compatible machine. Jonas learns that storage writes are among the most expensive operations, which influences design: storing every meter reading on-chain would be costly, so the system may store totals on-chain and detailed readings off-chain with hashes linking them.

8.3 Limits and failure

Gas limits mean a function that loops over an ever-growing list may eventually cost more than a block allows and become impossible to call. The SWC registry lists denial-of-service weaknesses of this kind. Jonas notes the defensive lesson: design functions whose cost is bounded regardless of how many members join, for example by letting each member claim their own credits rather than distributing to everyone in one transaction. Architecture knowledge thus shapes contract design choices that affect availability years after deployment.

Worked example

Jonas plans on-chain totals with off-chain readings linked by hashes, and per-member claims instead of loops over all members.

Synthetic case. Designs and the cooperative are synthetic; Wood's yellow paper and the SWC registry are real sources.

Errors and limits

Writing contract functions that loop over unbounded lists risks making them impossible to call as data grows.

Exercises

• EX022 — EVM type. What kind of machine is the EVM?
  Show marking criteria

  Rubric: 3 = stack-based virtual machine;; 2 = stack;; 1 = register;; 0 = none.
• EX023 — Expensive operation. Which operations are among the most expensive?
  Show marking criteria

  Rubric: 3 = storage writes;; 2 = storage;; 1 = additions;; 0 = none.
• EX024 — Bounded design. How does Jonas avoid unbounded loops?
  Show marking criteria

  Rubric: 3 = members claim their own credits;; 2 = per-member claims;; 1 = bigger blocks;; 0 = none.

Synthesis

Understanding processors and the EVM's gas model leads to designs with bounded cost.

Continue studying — chapter 08 of 50

← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →