Home|Contents|Prev|Chat


CSC 718 Answers 7 - Decentralised systems & blockchain

IS-Q7a How DHTs find data without a central directory

In P2P every node is client and server, so there is no single server to fail. A DHT treats the key space as a giant table split across peers ("a shredded phone book"): each key is hashed into the space, each node keeps a small slice plus a few routing hints, and a lookup hops node to node getting closer each step in about O(log N) hops - no central index. It scales, survives churn, and has no single point of failure.

IS-Q7b Lightweight consensus for an IoT sensor network

Three-tier "edge-offloaded ledger": Tier 1 (sensors) sign readings and sleep - no consensus/PoW. Tier 2 (edge gateways) are mains-powered; collect signed readings, run local anomaly detection, hold the ledger, and run lightweight consensus (delegated PoS, PBFT-style voting among a few gateways, or trust-score voting). Tier 3 (cloud) optionally stores hashes of gateway blocks for audit. Integrity: each reading is hashed and signed; readings form hash-chained blocks; only signed readings enter the ledger. This keeps immutability while respecting constrained devices (PoW is impossible on battery nodes).

IS-Q8c CA tasks and the practical assignment

CA1 (protocol simulation): in NS-3/Mininet compare TCP Cubic vs BBR over a bottleneck link, varying loss (0-5%) and buffer sizes; report throughput and latency.

CA2 (design): a lightweight decentralised telemetry network for 5,000 low-power sensors - protocol choices (6LoWPAN, MQTT, CoAP), edge caching with local anomaly detection, and a lightweight ledger/consensus for tamper-proof auditing.

Practical: boot a minimal Linux (Alpine/TinyCore) from USB as a constrained edge node; run an encryption benchmark comparing AES-256 vs ChaCha20 (cycles, memory, latency); publish metrics via MQTT and hash the payload for ledger prep.


Home|Contents|Prev|Top|Chat