Chapter 19 — Identity and cryptography
Lesson map
Lesson 19 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes"]
N1["19.1 Keys and signatures"]
N2["19.2 Merkle trees"]
N3["Lab — Merkle inclusion"]
N4["19.3 Reading the proof"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX055"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["19.1 Keys and signatures"]
N2["19.2 Merkle trees"]
N3["Lab — Merkle inclusion"]
N4["19.3 Reading the proof"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX055"]
[Learning outcomes]
|
v
[19.1 Keys and signatures]
|
v
[19.2 Merkle trees]
|
v
[Lab — Merkle inclusion]
|
v
[19.3 Reading the proof]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes
You will (1) explain keys, signatures and addresses; (2) verify Merkle inclusion proofs; (3) plan key custody.
19.1 Keys and signatures
Blockchain identities are key pairs. A private key signs transactions; the matching public key, or an address derived from it, lets anyone verify the signature. Wood's yellow paper specifies how Ethereum accounts and signatures work. Jonas learns that whoever holds a private key controls the account, with no password reset. This makes key custody the central identity question: losing a key loses access, and leaking it gives control to someone else. Members' keys, administrator keys and validator keys each need different custody arrangements.
19.2 Merkle trees
A Merkle tree hashes data in pairs up to a single root, so one short root commits to many items. A proof that an item is included needs only the hashes along its path, a logarithmic number. Brightwater's monthly commitment of meter readings uses a Merkle root, so a household can verify its own readings were included without seeing others'. Jonas writes a standard-library script to build a tree over eight synthetic readings and verify inclusion proofs, which only reads data and prints results.
Lab — Merkle inclusion
"""Merkle root and inclusion-proof verification for synthetic meter readings (read-only)."""
import hashlib
H = lambda b: hashlib.sha256(b).digest()
LEAVES = [f"meter-{i:02d}:{kwh}".encode() for i, kwh in enumerate([12, 9, 15, 7, 11, 14, 8, 10])]
def levels(leaves):
lv = [[H(x) for x in leaves]]
while len(lv[-1]) > 1:
cur = lv[-1]; lv.append([H(cur[i] + cur[i + 1]) for i in range(0, len(cur), 2)])
return lv
def proof(lv, idx):
out = []
for layer in lv[:-1]:
sib = idx ^ 1; out.append((layer[sib], sib < idx)); idx //= 2
return out
def check(leaf, pr, root):
h = H(leaf)
for sib, left in pr:
h = H(sib + h) if left else H(h + sib)
return h == root
def main():
lv = levels(LEAVES); root = lv[-1][0]
print("leaves", len(LEAVES), "root", root.hex()[:12], "proof length", len(proof(lv, 5)))
print("meter-05 included:", check(LEAVES[5], proof(lv, 5), root))
print("altered meter-05 included:", check(b"meter-05:41", proof(lv, 5), root))
if __name__ == "__main__":
main()
Run with python3 lab_merkle.py. Verified output:
leaves 8 root 88c2dfaf0abe proof length 3
meter-05 included: True
altered meter-05 included: False
19.3 Reading the proof
The script builds a tree over eight readings, prints the root and produces a three-hash proof for meter-05. The genuine reading verifies as included; an altered reading with the same proof does not. Jonas notes that proofs are short because the tree has three levels, and that the root must be obtained from the ledger, not from the party providing the proof, otherwise the check is meaningless. He then drafts custody plans: members may use cooperative-managed custody or their own wallets; administrators use hardware keys within multi-signature wallets.
Worked example
The lab verifies meter-05's reading with a three-hash proof and rejects an altered value; custody plans distinguish member, administrator and validator keys.
Synthetic case. Readings, keys and plans are synthetic; Wood's yellow paper is a real source.
Errors and limits
Checking a Merkle proof against a root supplied by the same party as the proof gives no assurance.
Exercises
- EX055 — Key loss. What happens if a private key is lost? Rubric: 3 = access is lost with no reset;; 2 = lost access;; 1 = reset;; 0 = none.
- EX056 — Proof size. How many hashes were in meter-05's proof? Rubric: 3 = three;; 2 = 3;; 1 = eight;; 0 = none.
- EX057 — Root source. Where must the root come from? Rubric: 3 = the ledger, not the proof provider;; 2 = ledger;; 1 = provider;; 0 = none.
Synthesis
Keys, signatures and Merkle proofs underpin identity and verifiable data, with custody as the central risk.
Continue studying — chapter 19 of 50
← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →