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: That observation connects this visual to the chapter's running narrative: use it to justify the next design decision and to record what evidence would confirm it in operation.
Explain: 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.
Explain: Different ledger patterns make different tradeoffs.

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

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

How a Ledger Record Is Created (continued)

That boundary must be explicit because it determines key storage, replay handling, outage behavior, and who can prove what happened.

That observation connects this visual to the chapter's running narrative: use it to justify the next design decision and to record what evidence would confirm it in operation.
The important architecture detail is that the device is rarely a full ledger participant.
Resource-constrained devices normally send signed observations to a gateway or service.

Major section

Ledger Patterns for IoT · What Goes On Ledger

Different ledger patterns make different tradeoffs.

A checklist alone cannot settle ledger patterns for iot.
Their relevance to many small events is: Public, permissioned, off-ledger anchoring, and DAG-style ledger patterns serve different IoT trust and throughput needs.
Most IoT telemetry should not be written directly to a ledger.

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

Major section

The Trust Boundary Creates the Ledger · Route Facts to the Right Store

The raw signal, the operational alert, and the shared proof are different artifacts.

A distributed ledger is useful only when the record owner is part of the problem.
A cold-chain shipment may pass through a manufacturer, carrier, warehouse, and clinic.
The ledger is therefore not the whole IoT architecture.

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.
This supports architecture decision record.

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?

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

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

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

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

Show answer

Answer: A 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?

AOnly that an accepted entry exists; replay proof is broken until the original batch and metadata are restored.

BThat every temperature value was physically accurate because consensus accepted the stored fingerprint.

CThat future alerts should wait for ledger finality because disputed batches settle later.

DThat original telemetry can be rebuilt from fingerprint, signer, and timestamp fields.

Show answer

Answer: A 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.

A · 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.
A · A ledger entry is only one link in the proof chain.
C · Distributed ledgers solve shared trust problems across parties.