Information Flow and Testing Decentralised Systems
One-Way Information Flow
In a system with security levels or trust domains, information should only travel in directions that cannot leak high-security information to low-security observers. Two distinct concerns:
Confidentiality: Low → High
For confidentiality, the rule is: low-clearance data may be read by high-clearance processes, but high-clearance data must not flow to low-clearance readers.
A low-clearance user may write data that a high-clearance process reads (e.g. a soldier in the field submits a report that a classified intelligence system ingests). But a high-clearance process must not write data that a low-clearance user can read (the classified intelligence must not leak into the field report).
Integrity: High → Low
For integrity, the rule is inverted: trusted (high-integrity) information flows from high to low. Untrusted (low-integrity) input must not silently corrupt trusted state.
A web server should accept input from untrusted users (low integrity) — but that input must be validated and sanitised before it is written into the trusted database (high integrity). The integrity boundary is the validation layer: untrusted data crosses it only after passing explicit checks.
Testing a Decentralised System
The 2025 Tripos Paper 2 Q5(a) scenario asks: “Explain some possible strategies for testing the server software for this [decentralised, rapidly growing] social network.”
The key insight is that a decentralised system has testing challenges that a centralised one does not:
Strategies, with justification specific to the decentralised scenario
| Strategy | Why it matters for a decentralised system specifically |
|---|---|
| Unit tests | Test core server logic (post validation, ranking, storage) in isolation, mocking the network and federation layers. Fast, reliable, the base of the pyramid. |
| Integration tests | Test against a real database and a second, locally-run server instance to exercise real federation calls. Catches boundary/serialisation bugs of the Mars Climate Orbiter type — two independently-tested components that disagree on a shared format. |
| Protocol conformance / interoperability testing | Since other people’s servers are independently implemented black boxes, test your server against the published federation protocol specification — not just against your own implementation of it. Your implementation may have made the same assumption as your tests; the spec is the ground truth. |
| Fuzzing | A hostile or buggy remote server can send malformed federation messages (deliberately or accidentally). Fuzz the message parser with plausible-but-invalid payloads — malformed JSON, missing required fields, circular references, enormous strings — to verify it fails safely (rejects the message) rather than catastrophically (crashes, leaks memory, executes injected code). |
| Load / stress testing | The system is described as “rapidly growing.” Test under bursty, anomalous load — 10× the expected peak — not just the steady-state happy path. Models the London Ambulance Service scenario: a system that works under normal load can collapse when load exceeds design assumptions, flooding itself with duplicate retry requests. |
| Security testing | Specific to the federated trust model: attempt to forge a post claiming to be from another server’s user; attempt to replay a valid signed message; attempt to access private data without authorisation. STRIDE-driven test cases targeting the Spoofing, Tampering, and Elevation of Privilege surfaces. |
| End-to-end / manual exploratory testing | Cover the critical user journeys (posting, following a remote user, receiving a federated timeline) end-to-end. Catches UX and integration issues no unit or integration test will detect — e.g. a post that is technically correctly federated but renders garbled due to a CSS or client-side parsing issue. |
Mark-scheme guidance for 6-mark Tripos parts
A 6-mark part rewards roughly one mark per distinct, well-justified strategy. Name the strategy, explain why it matters for this specific system, and link it to a course concept or case study (e.g. “integration testing catches the Mars Climate Orbiter unit-mismatch class of bug”). Do not simply list testing types — explain their relevance to the scenario.
Expected Learning
- Explain the one-way information-flow rules for confidentiality (low → high) and integrity (high → low).
- For a decentralised system scenario, name and justify at least four testing strategies, each with a reason specific to the scenario.
- Explain why protocol conformance testing is essential when third-party implementations are untrusted black boxes.
- Explain the role of fuzzing in testing federation message parsers, referencing STRIDE.
Past Paper Questions
The 2025 Tripos Paper 2 Q5(a) is the direct source for this material — a 6-mark part on testing strategies for a decentralised social network. The model answer in the Examinable Material folder expands on each strategy.