Cloud, SDN & Production Architectures · Study deck

Smart Contracts for IoT

Picture two firms sharing cold goods.

Cloud Clara is your guide for this deck.

blockchainsmart

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

After studying this chapter

Learning objectives

You will be able to:

Explain: The contract can apply the same rule to the same input every time, but it cannot tell whether a freezer door really opened, whether a sensor was calibrated, or whether a gateway skipped a failed reading.
Explain: If a gateway key is compromised, a clock is wrong, a telemetry batch is missing, or a sensor is miscalibrated, the contract may still run perfectly and record the wrong business outcome.
Explain: If one gateway hashes JSON with fields in insertion order and another verifier sorts fields alphabetically, the replay may fail even when the readings are the same.

Major section

Start With the Agreement Logic

A temperature sensor reports a warm period, and an automatic agreement may release or hold payment.

The rule can apply a clear decision to an accepted record, but it cannot inspect the box, repair a bad sensor, or judge an honest exception by itself.
A smart contract is code that applies agreed rules to records shared on a ledger.
Shared history does not make input true, private, fair, or lawful.

Major section

Key Concepts

Accepted record: A signed, validated summary that the agreement logic is allowed to evaluate.

Validation gateway: A gateway or service that receives device events, checks context, signs summaries, buffers during outages, and submits compact records.
oracle problem: The fact that ledger logic cannot directly observe physical-world data and must rely on a trusted record path.
Trigger condition: The objective rule that determines whether an accepted record changes an agreement state.

Major section

The Accepted Record Path

The accepted-record path is the most important part of the design.

If the path is weak, the contract only automates weak assumptions.
This supports the accepted record path.

The seven-stage accepted-record path keeps raw telemetry off ledger while a gateway checks identity, timing, duplicates, and plausibility, stores proof, signs a compact summary, submits the ledger record, runs deterministic agreement logic, and supports proof replay.

Major section

Worked Example: Shared Cold-Room Handoff

A campus has several teams using shared cold rooms for temperature-sensitive materials.

The teams want a shared record of handoffs and exceptions, but they do not want every sensor reading replicated to every participant.
If the summary is complete, signed, timely, and inside the agreed operating band, the handoff closes.

A cold-room exception flow records accepted handoff, exception verification, proof replay, and final verified outcome while raw telemetry remains off ledger.

Major section

Worked Example: Shared Cold-Room Handoff (continued)

If the summary is incomplete, delayed, disputed, or outside the band, the outcome moves to exception verification.

Raw readings remain in the monitoring system for replay.
The contract does not decide whether the physical room was safe by itself.
It records which summary was accepted, which rule was applied, and which verification path was chosen.

Major section

Readiness Record

A checklist alone cannot settle readiness record.

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.

A readiness record gathers record schema, telemetry retention, gateway duties, participant governance, exception states, update process, proof replay, and monitoring signals.

Major section

Contracts Evaluate Records

A smart contract is only as trustworthy as the record it receives.

The contract can apply the same rule to the same input every time, but it cannot tell whether a freezer door really opened, whether a sensor was calibrated, or whether a gateway skipped a failed reading.
This supports contracts evaluate records.

Keep the smart contract behind the accepted-record boundary: physical events and raw telemetry stay operational, while signed records feed deterministic agreement and replayable verification.

Major section

Contracts Evaluate Records (continued)

The visual summarizes: Keep the smart contract behind the accepted-record boundary: physical events and raw telemetry stay operational, while signed records feed deterministic agreement and replayable verification.

Mobile summary:: The contract can evaluate accepted records, but gateway checks, off-ledger evidence, exception states, and replay rules make the outcome trustworthy.
The physical box contains readings, door openings, charger states, and alarms.
The evidence box contains signed summaries, fingerprints, timestamps, and participant identities.

Major section

Contracts Evaluate Records (continued)

The design has to name the accepted record, the gateway checks, the off-ledger evidence, the exception path, and the proof replay method before the ledger outcome can be trusted.

The agreement box contains the rule that changes shared state after an evidence record is accepted.
If a proposed contract tries to live in the physical box, it is doing the wrong job.
If it lives in the agreement box but the evidence box is vague, the outcome will be hard to defend during a dispute.
A practical smart-contract design therefore starts with a modest promise: make a narrow shared decision replayable.

Major section

Contract Boundary Record

For each automated outcome, write a boundary record that says exactly what the contract is allowed to decide and what remains outside the ledger.

This keeps the implementation from drifting into raw telemetry storage, direct control, or unreviewable judgment.
Include an idempotency key so a retry cannot close the same handoff twice.
Include the rule version so a later review can distinguish an old threshold from a new one.

Major section

Determinism Cannot Verify Input

If a gateway key is compromised, a clock is wrong, a telemetry batch is missing, or a sensor is miscalibrated, the contract may still run perfectly and record the wrong business outcome.

Smart contracts are deterministic so peers can reach the same ledger outcome.
Every peer can recompute that transition.
Canonicalization is a common failure point.

Major section

Determinism Cannot Verify Input (continued)

That preserves the shared history while still letting the system recover from faulty gateways, bad clocks, or disputed summaries.

Determinism protects agreement about state transitions; it does not validate the physical event that produced the input record.
A weak evidence chain can feed a perfect state transition with bad input.
Corrections should also be explicit state transitions.

Major section

Determinism Cannot Verify Input (continued)

The ledger can make that outcome visible and replayable, but the correction has to come from gateway controls, exception workflow, governance, and retained evidence.

The system is ready only when both chains can fail visibly, pause safely, and be replayed by a participant who did not operate the original device.
If one gateway hashes JSON with fields in insertion order and another verifier sorts fields alphabetically, the replay may fail even when the readings are the same.
If timestamps are rounded differently, a batch fingerprint can become unreproducible.

Deck summary

Key takeaways

A temperature sensor reports a warm period, and an automatic agreement may release or hold payment.

Accepted record: A signed, validated summary that the agreement logic is allowed to evaluate.
The accepted-record path is the most important part of the design.
A campus has several teams using shared cold rooms for temperature-sensitive materials.
If the summary is incomplete, delayed, disputed, or outside the band, the outcome moves to exception verification.

Retrieval practice

Recall check 1 of 3

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

Q1A shared cold-room workflow will let a smart contract close a handoff or pause it when a signed summary is late, incomplete, or disputed. Which first check keeps the contract decision traceable?

ADefine the accepted handoff summary, validation gateway checks, off-ledger telemetry batch, trigger rule, exception state, governance owner, replay method, and retest trigger.

BMove the cold-room control loop and every temperature reading into the contract so the ledger can observe the physical room directly.

CTreat one accepted handoff transaction as proof for every gateway outage, delayed submission, key rotation, disputed summary, and lifecycle change.

DPostpone rule updates, participant membership, gateway key suspension, proof replay, and recovery ownership until after the contract is live.

Show answer

Answer: A see answers page

Retrieval practice

Recall check 2 of 3

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

Q2A shared cold-room workflow uses a smart contract to record handoff outcomes. Which design choice best protects quality when sensor input is delayed or disputed?

ALet the contract close the handoff whenever any temperature value arrives.

BKeep raw telemetry off ledger, submit a signed summary, and route uncertain input to exception verification.

CPut every sensor reading into the ledger so the contract has all possible data.

DMove the cold-room control loop into the contract so the ledger can handle the problem directly.

Show answer

Answer: B Smart contracts should evaluate accepted records, not raw physical reality.

Retrieval practice

Recall check 3 of 3

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

Q3A contract deterministically closes a cold-room handoff when it receives a signed summary, but later the team discovers the gateway clock was wrong during the handoff window. What should the architecture rely on?

AUse exception governance to pause or correct the result, then replay retained telemetry, signatures, rule version, and clock evidence.

BKeep the ledger outcome unchanged because deterministic execution proves the signed handoff record was physically correct.

CMove all raw telemetry into the contract so peers can recompute sensor timing and prevent future clock errors.

DLet each participant patch local ledger state and device timestamps until the shared disagreement disappears.

Show answer

Answer: A A deterministic smart contract can produce a replayable ledger outcome from a submitted record, but gateway clocks, signatures, telemetry retention, exceptions, and governance determine whether the submitted record is trustworthy.

Print reference

Answers

Answer key.

A · A practical smart-contract IoT decision is traceable when the team can replay the accepted handoff summary against retained off-ledger telemetry, explain the deterministic trigger, and name the exception, governance, recovery, and retest records before the contract becomes a dependency.
B · Smart contracts should evaluate accepted records, not raw physical reality.
A · A deterministic smart contract can produce a replayable ledger outcome from a submitted record, but gateway clocks, signatures, telemetry retention, exceptions, and governance determine whether the submitted record is trustworthy.