Cloud, SDN & Production Architectures · Study deck

How Distributed Ledgers Work

Imagine a food shipment handled by a farm, carrier, warehouse, and shop.

Cloud Clara is your guide for this deck.

blockchain

Cloud Clara, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: Practical designs record the hash algorithm, canonical serialization, batch window, clock source, signer identity, ledger transaction id, and storage location together, because a hash without those details can be impossible to reproduce.
Explain: Each party may trust its own internal database, but disputes arise when one party claims a handoff time, an exception record, or a temperature batch was changed after the fact.
Explain: If a key is lost or suspected of compromise, the governance path must say who suspends that identity and how later records are distinguished from older accepted records.

Major section

Start With the Trust Boundary

Each group needs the same handoff history, but no single group should be able to rewrite it alone.

A distributed ledger is a shared record that several parties check before accepting new entries.
Telemetry means readings sent from a remote device.
If one trusted owner can run the record well, a normal database may be simpler.

Major section

Start With the Trust Boundary (continued)

If fast control is the job, keep it off the shared ledger.

The ledger must solve a real trust boundary.
This simple chain does not make device data true, private, or fast.
It only changes how parties share and protect selected records.
The Practitioner section tests whether the pattern fits.

Major section

In 60 Seconds · Why This Matters

In practical IoT architecture, raw telemetry usually stays off ledger; the ledger records proofs, custody events, identity actions, and agreement outcomes.

A shipment may move through a manufacturer, carrier, warehouse, clinic, and insurer.
A building may contain devices maintained by different contractors.
Distributed ledgers can help with that narrow trust problem.

A blockchain fit filter separates single-party telemetry and real-time control from multi-party, tamper-evident event history.

Major section

Key Concepts · The Trust Boundary

Append-only history: A record structure where new events are added without editing earlier accepted entries.

Hash link: A cryptographic fingerprint that connects an entry or batch to prior records, making later alteration detectable.
Consensus: The process by which ledger participants agree which records are accepted.
It usually does not need a distributed ledger.

Major section

How a Ledger Record Is Created · Ledger Patterns for IoT

The basic flow is simple, even though production ledgers add many details.

A device or gateway observes an event, signs or packages it, sends it to the ledger network, and participating nodes validate the event according to agreed rules.
Once accepted, the event becomes part of an append-only history.

An IoT ledger transaction begins with a device observation, moves through a gateway record, is validated by participating nodes, and becomes part of an append-only history.

Major section

What Goes On Ledger

Most IoT telemetry should not be written directly to a ledger.

Sensor streams are frequent, noisy, and operational.
They belong in a telemetry platform that can query, aggregate, correct, and expire data according to the system design.
This route preserves immediate response while giving participants a durable shared proof.

A practical IoT blockchain architecture keeps high-volume telemetry off ledger and records only fingerprints, custody events, identity actions, and agreement outcomes on ledger.

Major section

The Trust Boundary Creates the Ledger

A distributed ledger is useful only when the record owner is part of the problem.

If one organization owns the devices, gateways, database, and reports, a normal telemetry system with signed events and audit logs is usually enough.
The ledger question starts when multiple organizations must rely on the same record and none of them should have unilateral edit power over that shared history.
The ledger is therefore not the whole IoT architecture.

Major section

The Trust Boundary Creates the Ledger (continued)

A cold-chain shipment may pass through a manufacturer, carrier, warehouse, and clinic.

Each party may trust its own internal database, but disputes arise when one party claims a handoff time, an exception record, or a temperature batch was changed after the fact.
The ledger is useful only for the small set of shared facts that must remain tamper-evident across that group.
The distributed ledger sits beside those systems as a shared proof layer.

A ledger approval record captures trust statement, record boundary, identity path, failure behavior, proof replay, and governance owner before approval.

Major section

The Trust Boundary Creates the Ledger (continued)

Devices still need secure provisioning, protected keys, firmware integrity, calibrated sensors, reliable gateways, and a telemetry platform that can query and alert quickly.

Its job is to make accepted records difficult to alter silently, not to make measurements true, networks fast, or operational response automatic.
A good first review question is: "Which exact fact would be disputed if one participant controlled the database?" If the answer is vague, the design usually needs a signed audit log, not a ledger.
The boundary should also state who can see each proof record, because replicated evidence can create privacy and commercial exposure.

Public, permissioned, off-ledger anchoring, and DAG-style ledger patterns serve different IoT trust and throughput needs.

Major section

Route Facts to the Right Store

A useful ledger decision routes each fact to the place that matches its job.

The raw signal, the operational alert, and the shared proof are different artifacts.
For a cold-chain system, raw temperature samples may arrive every few seconds from BLE or cellular gateways and belong in time-series storage.
Alerts for an excursion must fire through the operational path immediately, even if the ledger network is unavailable.

Major section

Route Facts to the Right Store (continued)

Mixing those paths creates bad behavior: alerts become too slow, ledgers become bloated, and proof replay becomes unclear.

A device may sign an observation with a hardware-protected key, a gateway may sign a batch summary, and an organization may countersign a custody transfer.
If the network is down, the design needs a queue with event ids, timestamps, idempotency rules, and replay order.
If a key is lost or suspected of compromise, the governance path must say who suspends that identity and how later records are distinguished from older accepted records.

Major section

Consensus Accepts Records

Hashing, signatures, consensus, and finality solve a narrow problem: they make an accepted record hard to alter without detection.

They do not prove that the sensor was calibrated, that the gateway was honest, or that the business rule was fair.
A replayable proof chain has several links.
The raw batch remains retrievable off ledger.
Participants accept the compact record.

Major section

Consensus Accepts Records (continued)

A hash is computed with a known method and ordering rule.

Consensus and finality also need context.
Public blockchains, permissioned ledgers such as Hyperledger Fabric, and DAG-style systems make different assumptions about membership, throughput, settlement, privacy, and governance.
Break any link and the ledger still contains an entry, but the architecture loses proof value.

Major section

Consensus Accepts Records (continued)

IoT architecture usually favors permissioned or anchored designs because participants are known, telemetry is high volume, and raw data often cannot be replicated to every node.

Even then, finality is not a substitute for operational safety: control commands, alarms, and device recovery must work without waiting for ledger agreement.
A missing raw batch, unknown hash method, lost signing key, disputed timestamp source, or unassigned governance owner can make an immutable record operationally weak.
Practical designs record the hash algorithm, canonical serialization, batch window, clock source, signer identity, ledger transaction id, and storage location together, because a hash without those details can be impossible to reproduce.

Major section

Cold-Chain Ledger Records

Each party needs confidence that handoff times, container identity, and temperature records were not quietly rewritten after a dispute.

The temperature stream is frequent, and alerts must be handled quickly.
It changes data placement, identity handling, outage recovery, and dispute handling.
Manufacturer, carrier, warehouse, and receiving site share custody events and batch fingerprints on the ledger.

The cold-chain example separates fast operational alerts from shared ledger records, then verifies later disputes by replaying batch fingerprints against off-ledger telemetry.

Major section

Security Limits · Do Not Put Control Loops On Ledger

Blockchain is not an IoT security shortcut.

It records what authorized participants submit.
If a device key is stolen, a sensor is physically manipulated, or a gateway signs bad data, the ledger may preserve a false event very reliably.
Real-time control needs predictable local response.

Deck summary

Key takeaways

Each group needs the same handoff history, but no single group should be able to rewrite it alone.

If fast control is the job, keep it off the shared ledger.
In practical IoT architecture, raw telemetry usually stays off ledger; the ledger records proofs, custody events, identity actions, and agreement outcomes.
Append-only history: A record structure where new events are added without editing earlier accepted entries.
The basic flow is simple, even though production ledgers add many details.

Retrieval practice

Recall check 1 of 3

Cloud Clara says: answer from memory, then check your reasoning.

Q1A cold-chain shipment moves through a manufacturer, carrier, warehouse, and receiving site. What must be proven before choosing a distributed ledger?

APut readings, alerts, dashboards, and custody handoffs on one ledger so every record has one home.

BUse one successful handoff transaction as proof of outage, replay, duplicate, ordering, and key recovery.

CLet the carrier keep the only database, then export signed reports after delivery disputes.

DName parties, disputed facts, ledger records, off-ledger data, signing, replay, recovery, and governance.

Show answer

Answer: D A cold-chain ledger decision starts with the multi-party trust boundary, the exact custody and fingerprint records to share, the off-ledger temperature and alert path, and the signing, replay, recovery, and governance rules.

Retrieval practice

Recall check 2 of 3

Cloud Clara says: answer from memory, then check your reasoning.

Q2A cold-chain consortium stores batch fingerprints on a permissioned ledger. During a dispute, the original telemetry batch cannot be retrieved. What does the ledger still prove?

AConsensus proves every physical temperature value was accurate.

BAlerts should wait for finality because disputed batches settle later.

CA fingerprint exists, but replay still needs raw batch and metadata.

DRaw telemetry can be reconstructed from the hash, signer, and time.

Show answer

Answer: C A ledger entry is only one link in the proof chain.

Retrieval practice

Recall check 3 of 3

Cloud Clara says: answer from memory, then check your reasoning.

Q3A company owns every sensor, gateway, database, and dashboard in its building monitoring system. No outside party needs to verify the records. What is the strongest architecture choice?

AUse a public ledger to let future auditors verify sensor records without relying on the company's database

BUse a permissioned ledger to make internal departments agree before a monitoring record is accepted

CUse a normal telemetry store with signed events, access control, backup, and audit logging

DPut raw readings on a ledger so an auditor can inspect the original values without retrieving separate batches

Show answer

Answer: C Distributed ledgers solve shared trust problems across parties.

Print reference

Answers

Answer key.

D · A cold-chain ledger decision starts with the multi-party trust boundary, the exact custody and fingerprint records to share, the off-ledger temperature and alert path, and the signing, replay, recovery, and governance rules.
C · A ledger entry is only one link in the proof chain.
C · Distributed ledgers solve shared trust problems across parties.