◇ OpenCyber Academy
Engineering · Chapter 13 · English

Chapter 13 — Data systems

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 13 — Data systems

Lesson map

Lesson 13 published. Map, example, EX037.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 What goes where"]
  N2["13.2 Linking with hashes"]
  N3["13.3 Database protection"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX037"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 What goes where"]
  N2["13.2 Linking with hashes"]
  N3["13.3 Database protection"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]

[Learning outcomes]
    |
    v
[13.1 What goes where]
    |
    v
[13.2 Linking with hashes]
    |
    v
[13.3 Database protection]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX037]

Learning outcomes

You will (1) design on-chain and off-chain data; (2) link them with hashes; (3) protect member privacy.

13.1 What goes where

Not all data belongs on a ledger. Jonas sorts Brightwater's data into three groups: data that must be shared and tamper-evident, such as credit balances and transfers; data that is private, such as household names and detailed meter readings; and operational data, such as logs. Balances go on-chain; private data stays in the cooperative's database; operational data goes to a logging system. NIST IR 8202 notes that data on a ledger is hard to remove, which is a strong reason to keep personal data off it.

13.2 Linking with hashes

To connect off-chain readings with on-chain credits without publishing readings, Jonas designs a monthly commitment: the cooperative computes a hash summarising all readings and publishes only that hash on-chain. Later, anyone given a household's readings can check they match the commitment. This lets disputes be resolved with evidence while keeping data private. He notes that hashes of small, guessable data, such as a single reading, could be reversed by trying all values, so commitments include random padding. The padding is stored securely with the readings.

13.3 Database protection

The off-chain database now holds the most sensitive data. Jonas applies standard protections: access restricted to named staff, encryption at rest, backups tested by restoration, and audit logging of queries. He also plans data retention: readings older than seven years are deleted unless needed for a dispute. Moving data off-chain does not remove the need to secure it; it moves the responsibility to systems the cooperative controls, where conventional security practices apply. Jonas tests restoration quarterly and records the time taken, so the board knows how long recovery would take.

Worked example

Balances go on-chain, readings stay off-chain with monthly padded hash commitments, and the database is encrypted, access-logged and backed up.

Synthetic case. Data and designs are synthetic; NIST IR 8202 is a real source.

Errors and limits

Putting personal data on a ledger makes it practically impossible to remove later.

Exercises

Synthesis

Careful placement of data, hash commitments and database protection balance transparency and privacy.

Continue studying — chapter 13 of 50

← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →