28 How Distributed Ledgers Work

28.1 Start With the Trust Boundary

This section: Start With the Trust Boundary — Imagine a food shipment handled by a farm, carrier, warehouse, and shop.

Imagine a food shipment handled by a farm, carrier, warehouse, and shop. 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.

Start with one small event, such as a signed handoff. Decide who may write it, who checks it, and when it is final enough to use. Keep large sensor records outside the ledger and store only the proof that matters. Then test a false entry, a missing party, and a late correction.

Use a fit test before choosing a ledger. List the parties. Mark which parties do not fully trust one another. Name the shared event. Keep its raw evidence in the right system. Decide who may add a record. Decide how others check it. Set the time at which work may continue. Plan for a wrong or late entry. Name the law or owner that can correct the real-world record.

If one trusted owner can run the record well, a normal database may be simpler. 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. Under the Hood explains agreement, finality, and cost limits.

A distributed ledger starts with a trust boundary: one organization can no longer be the only keeper of a record that other organizations depend on. The chain is a mechanism for accepting records across that boundary.

Start simple: choose one compact event and decide who signs it, who validates it, where the raw evidence stays, and when the record is final enough. The ledger pattern follows from those facts.

28.2 Why This Matters

This section: Why This Matters — IoT systems often cross organizational boundaries.

IoT systems often cross organizational boundaries. A shipment may move through a manufacturer, carrier, warehouse, clinic, and insurer. A building may contain devices maintained by different contractors. A shared energy system may need a neutral record of meter events and settlement actions. In those settings, the architecture question is not “Can we add blockchain?” The useful question is “Which facts must several parties be able to verify later, without letting one party rewrite the shared history?”

Distributed ledgers can help with that narrow trust problem. They do not make a compromised sensor honest, they do not make noisy measurements accurate, and they do not remove the need for device identity, secure transport, access control, monitoring, or a reliable operational data store.

The filter in Figure 28.1 sends one-owner data to a database; check shared history for ledger fit.

+

Locate IoT need in the diagram Figure 28.1, then compare Shared history? with fit. The three labels prevent a one-box why this matters reading. Their relevance to Shared history? is: A blockchain fit filter separates single-party telemetry and real-time control from multi-party, tamper-evident event history.

28.3 Learning Objectives

This section: Learning Objectives

By the end of this chapter, you will be able to:

• Explain the trust problem that distributed ledgers can solve in IoT systems.
• Distinguish append-only evidence from normal telemetry storage.
• Describe how hashing, signatures, consensus, and finality support tamper-evident records.
• Choose between public, permissioned, and off-ledger anchoring patterns at a conceptual level.
• Prepare an architecture review record for an IoT ledger decision.

28.4 Quick Check: Ledger Fit Boundaries

This section: Quick Check: Ledger Fit Boundaries

28.5 The Trust Boundary

This section: The Trust Boundary — Blockchain becomes architectural when it changes who is allowed to own the record of truth.

Blockchain becomes architectural when it changes who is allowed to own the record of truth. A single organization monitoring its own devices usually needs strong identity, audit logging, backup, and database controls. It usually does not need a distributed ledger.

A ledger review becomes relevant when all of these conditions are present:

• Several parties need to rely on the same event history.
• No single party should be able to silently rewrite that history.
• Later verification matters more than immediate control.
• The records placed on the ledger are small, meaningful, and durable.
• The organization can operate identity, key handling, governance, and failure recovery.

If any of those conditions are missing, a normal database with signed events and audit logging is usually a cleaner architecture.

28.6 How a Ledger Record Is Created

This section: How a Ledger Record Is Created — The basic flow is simple, even though production ledgers add many details.

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.

Figure 28.2 follows a device observation into a shared ledger record.

+

The device observes an event but usually does not run a full ledger node. A gateway signs or batches its record and sends it to participants, which validate the accepted data under their agreed rules. The ledger keeps that accepted history for later review. The gateway boundary matters because it determines where keys live, how repeated events are handled, and what happens during an outage. A later reviewer can compare the accepted ledger entry with the gateway record, but neither proves the original sensor was accurate. Use this path only when shared validation answers a real custody or audit question.

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. That boundary must be explicit because it determines key storage, replay handling, outage behavior, and who can prove what happened.

28.7 Ledger Patterns for IoT

This section: Ledger Patterns for IoT — Different ledger patterns make different tradeoffs.

Different ledger patterns make different tradeoffs. The names matter less than the responsibility they create.

A checklist alone cannot settle ledger patterns for iot. Inspect Figure 28.3 for this relationship: Public, permissioned, off-ledger anchoring, and DAG-style ledger patterns serve different IoT trust and throughput needs. Compare broader shared verification with many small events.

+

Locate broader shared verification in the diagram Figure 28.3, then compare many small events with fingerprints on ledger. The three labels prevent a one-box ledger patterns for iot reading. Their relevance to many small events is: Public, permissioned, off-ledger anchoring, and DAG-style ledger patterns serve different IoT trust and throughput needs.

28.8 What Goes On Ledger

This section: What Goes On Ledger — Most IoT telemetry should not be written directly to a 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.

Put only durable, review-worthy facts on the ledger:

• Device registration, transfer, suspension, or retirement events.
• Custody handoffs between organizations.
• Hashes of telemetry batches stored elsewhere.
• Agreement outcomes triggered by verified events.
• Maintenance or inspection attestations.
• Exception records that several parties must review later.

Keep off ledger:

• High-frequency raw readings.
• Large files, images, or logs.
• Real-time control commands.
• Values that may need correction or deletion.
• Sensitive data that should not be replicated across many parties.

Treat what goes on ledger as a system decision around Devices. The visual in Figure 28.4 places Fingerprints within this relationship: A practical IoT blockchain architecture keeps high-volume telemetry off ledger and records only fingerprints, custody events, identity actions, and agreement outcomes on ledger.

+

The boundary in Figure 28.4 keeps fast IoT work off ledger. Devices send raw readings to telemetry storage, where they can be queried, corrected, expired, and used for alerts without waiting for agreement. A compact batch fingerprint can then be written to shared history with custody, identity, or agreed outcome records that several parties may need to verify later. Keep the raw batch and its metadata, because a hash alone cannot replay a disputed reading. This route preserves immediate response while giving participants a durable shared proof. It also limits replicated sensitive or high-volume data to the small facts the ledger is meant to hold.

28.9 The Trust Boundary Creates the Ledger

This section: The Trust Boundary Creates the Ledger — A distributed ledger is useful only when the record owner is part of the problem.

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.

In IoT, that boundary often appears around custody, inspection, metering, maintenance, or settlement. 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 ledger is therefore not the whole IoT architecture. Devices still need secure provisioning, protected keys, firmware integrity, calibrated sensors, reliable gateways, and a telemetry platform that can query and alert quickly. The distributed ledger sits beside those systems as a shared proof layer. 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. If the answer names durable facts such as custody transfer, batch fingerprint, inspection attestation, participant admission, or settlement outcome, the ledger review has a concrete boundary to evaluate. The boundary should also state who can see each proof record, because replicated evidence can create privacy and commercial exposure.

28.10 Route Facts to the Right Store

This section: Route Facts to the Right Store — A useful ledger decision routes each fact to the place that matches its job.

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. Treat the route as an architecture contract: the telemetry store owns sampling, retention, query, correction, and alerting; the ledger owns compact records that several parties must verify later; governance owns who may write, validate, suspend, and recover records.

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. A custody handoff, signed inspection, batch hash, or final exception outcome can wait for ledger settlement because its value is later verification. Mixing those paths creates bad behavior: alerts become too slow, ledgers become bloated, and proof replay becomes unclear.

Before approving the route, write down the signer and failure behavior for each ledger record. 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.

28.11 Consensus Accepts Records

This section: Consensus Accepts Records — Hashing, signatures, consensus, and finality solve a narrow problem: they make an accepted record hard to alter without detection.

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 permissioned ledger can agree that a gateway submitted a batch fingerprint at a certain sequence point, but it cannot infer whether the gateway was mounted in the right container or whether the temperature probe was placed near the cooling outlet.

A replayable proof chain has several links. The device or gateway signs a scoped event. The raw batch remains retrievable off ledger. A hash is computed with a known method and ordering rule. Participants accept the compact record. Later, an auditor recomputes the hash from the stored batch and compares it with the ledger entry. 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.

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. 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.

Break any link and the ledger still contains an entry, but the architecture loses proof value. A missing raw batch, unknown hash method, lost signing key, disputed timestamp source, or unassigned governance owner can make an immutable record operationally weak. The review should therefore test not only the successful write path, but also duplicate submissions, delayed writes, participant outage, key rotation, key compromise, record redaction constraints, and the exact steps needed to replay a disputed proof months later.

28.12 Cold-Chain Ledger Records

This section: Cold-Chain Ledger Records — A cold-chain shipment passes through a manufacturer, carrier, warehouse, and receiving site.

A cold-chain shipment passes through a manufacturer, carrier, warehouse, and receiving site. 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.

28.12.2 Architecture Decision Record

Decision: Use off-ledger telemetry storage for raw temperature readings. Use a permissioned ledger for custody events, batch fingerprints, and agreed exception records.

Why this is architectural: The decision separates operational monitoring from shared records. It changes data placement, identity handling, outage recovery, and dispute handling.

Records to verify before approval:

• A telemetry batch can be hashed, anchored, retrieved, and verified later.
• Handoff events include device identity, shipment identity, actor identity, timestamp source, and signature.
• Alerts still fire through the operational path when the ledger network is unavailable.
• Delayed ledger writes can be replayed without changing event order.
• Each participating organization understands who may write, read, suspend, and recover records.

Before approving architecture decision record, test the depicted proposition in Figure 28.5: The cold-chain example separates fast operational alerts from shared ledger records, then verifies later disputes by replaying batch fingerprints against off-ledger telemetry. Read from Container toward Operations team.

+

The cold-chain path in Figure 28.5 separates action time from dispute review. The container sends readings to telemetry storage, where alert rules notify the operations team even if the ledger is unavailable. Manufacturer, carrier, warehouse, and receiving site share custody events and batch fingerprints on the ledger. Later, a reviewer retrieves the stored raw batch, recomputes its hash, and compares that value with the ledger fingerprint and any correction record. The replay needs the raw batch, hash method, timestamp source, and ledger reference. A ledger entry can show whether a batch changed after anchoring; it does not make the sensor reading true or replace the fast alert path.

28.13 Security Limits

This section: Security Limits — Blockchain is not an IoT security shortcut.

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.

Use ledger records alongside the normal IoT security stack:

• Secure provisioning and device identity.
• Key storage and rotation.
• Firmware integrity and update controls.
• Encrypted communication.
• Plausibility checks and anomaly detection.
• Monitoring for missing, delayed, duplicated, or replayed events.
• Recovery paths for lost keys and retired devices.

28.14 Ledger Approval Checklist

This section: Ledger Approval Checklist — Keep Ledger review, Identity path, and rules and recovery separate while reading Figure 28.6.

Use this approval checklist before adding a distributed ledger to an IoT architecture:

1. Trust statement: Which parties do not fully trust one another, and which facts must they share?
2. Record boundary: Which records go on ledger, and which stay in operational storage?
3. Identity path: Which device, gateway, or organization signs each record?
4. Failure behavior: What happens during network outage, participant outage, duplicate submission, or key loss?
5. Proof replay: Can a reviewer recompute an anchored fingerprint from stored telemetry?
6. Governance owner: Who admits participants, changes rules, handles suspension, and approves recovery?

Inspect Figure 28.6 before judging ledger approval checklist; it depicts: A ledger approval record captures trust statement, record boundary, identity path, failure behavior, proof replay, and governance owner before approval. Focus first on Ledger review, then on Identity path.

+

Keep Ledger review, Identity path, and rules and recovery separate while reading Figure 28.6. The diagram makes Ledger review a visible ledger approval checklist cue; its Identity path relationship advances the claim: A ledger approval record captures trust statement, record boundary, identity path, failure behavior, proof replay, and governance owner before approval.

28.15 Knowledge Check

This section: Knowledge Check

28.16 Knowledge Check

This section: Knowledge Check

28.17 Match Concepts To Roles

This section: Match Concepts To Roles

28.18 Sequence A Ledger Decision

This section: Sequence A Ledger Decision

28.19 Summary

This section: Summary — Blockchain fundamentals for IoT are less about fashionable technology and more about responsibility.

Blockchain fundamentals for IoT are less about fashionable technology and more about responsibility. Use a distributed ledger when separate parties need shared, tamper-evident records and no single party should own the history alone. Keep real-time control and high-volume telemetry off ledger. Put only durable, decision-worthy records on ledger, and approve the design only after identity, failure behavior, proof replay, and governance are clear.

28.20 Key Takeaway

This section: Key Takeaway — Use blockchain in IoT only when shared trust, auditability, and multi-party coordination justify the extra complexity, latency, privacy, and operations burden.

Use blockchain in IoT only when shared trust, auditability, and multi-party coordination justify the extra complexity, latency, privacy, and operations burden.