Chapter 11 — Networks and protocols

Chapter 11 — Networks and protocols

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 How nodes talk"]
  N2["11.2 Permissioned networking"]
  N3["11.3 Protecting connections"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 How nodes talk"]
  N2["11.2 Permissioned networking"]
  N3["11.3 Protecting connections"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX031"]

[Learning outcomes]
    |
    v
[11.1 How nodes talk]
    |
    v
[11.2 Permissioned networking]
    |
    v
[11.3 Protecting connections]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) explain how ledger nodes communicate; (2) describe peer-to-peer and permissioned networking; (3) protect node connections.

11.1 How nodes talk

A blockchain is a network of nodes that share transactions and blocks. Nakamoto's paper describes broadcasting new transactions to all nodes and having nodes accept the longest valid chain. Brightwater's permissioned ledger has three validator nodes, one at the cooperative and two at partner organisations, plus read-only nodes for applications. Jonas maps the traffic: transactions arrive at an application gateway, are forwarded to validators, and blocks are shared among validators. Understanding these paths tells him where an outage or interception would affect the system.

11.2 Permissioned networking

Unlike a public network where anyone can connect, Brightwater's validators accept connections only from known peers identified by certificates. Jonas learns to read the node configuration: allowed peer lists, ports and transport encryption. He finds that one partner node also exposes its administrative interface on a public address, a configuration mistake rather than an intended feature. He reports it privately to the partner, who restricts the interface to their internal network. Checking configuration against intent is a basic but valuable network security habit.

11.3 Protecting connections

Jonas recommends that all node-to-node and application-to-node connections use encrypted, mutually authenticated channels, that administrative interfaces are reachable only from management networks, and that each node runs on a separate provider or site so one outage does not halt the ledger. He documents the network diagram and peer list as configuration records. These measures address availability and integrity of communication, which matter as much as contract correctness because a ledger that nodes cannot reach cannot process members' transactions. Each recommendation is linked to a requirement.

Worked example

Jonas maps three validators and gateways, finds one partner's admin interface publicly exposed, and recommends mutually authenticated channels and separated sites.

Synthetic case. Nodes, partners and findings are synthetic; Nakamoto (2008) is a real source.

Errors and limits

Exposing node administrative interfaces to public networks invites misuse.

Exercises

• EX031 — Validator count. How many validators does Brightwater run? Rubric: 3 = three;; 2 = 3;; 1 = one;; 0 = none.
• EX032 — Exposed interface. What configuration mistake was found? Rubric: 3 = admin interface on a public address;; 2 = exposed admin;; 1 = vague;; 0 = none.
• EX033 — Site separation. Why run nodes at separate sites? Rubric: 3 = one outage does not halt the ledger;; 2 = availability;; 1 = cost;; 0 = none.

Synthesis

Known peers, encrypted channels and protected admin interfaces secure ledger networking.

Continue studying — chapter 11 of 50

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