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

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.
The gateway checks identity, time, whether the event makes sense, and whether it is a repeat.
The next service accepts that summary into the ledger path, where fixed agreement rules record an outcome.

A gateway validates device events, retains raw proof off ledger, and submits signed summaries for deterministic agreement and later 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.
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.

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)

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.
That keeps the ledger useful as a shared record without moving monitoring, control, or judgment into the ledger.
The shared ledger can record that accepted handoff, but an incomplete, delayed, disputed, or out-of-band result opens an exception rather than closing the case automatically.

Major section

Readiness Record

The readiness test has three linked questions.

The packet then records the schema, signing method, off-ledger telemetry and retention, exception states, and verification duties among its entries.
A smart contract can evaluate a signed summary consistently, but it cannot repair missing device evidence or assign an unowned incident.
A smart-contract IoT design is not ready just because the rule is clear.
@fig-blockchain-smart-contracts-readiness-record checks whether the accepted-record path and operating roles are defined.

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 boundary decides what the smart contract can honestly claim.
It makes the decision concrete by showing 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, so the relationships can be checked before they are turned into a design claim.

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)

A fixed rule reads that record and writes a shared result; it does not see the room, meter, or door.

This split supports replay and keeps a contract result from being mistaken for direct proof of the real event.
Participants can then agree on the submitted record, but that agreement cannot establish whether the sensor was mounted correctly or the physical event really occurred.
The physical box contains readings, door openings, charger states, and alarms.

The smart-contract pattern map centers the accepted record and connects it to four safeguards: a validation bridge, off-ledger data retention, an exception workflow, and upgrade governance, with proof replay tying ledger outcomes back to raw records.

Major section

Contracts Evaluate Records (continued)

Mobile summary: The contract can evaluate accepted records, but gateway checks, off-ledger evidence, exception states, and replay rules make the outcome trustworthy.

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 evidence box contains signed summaries, fingerprints, timestamps, and participant identities.
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.

Major section

Contracts Evaluate Records (continued)

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.
The contract records the accepted state transition, while the IoT system keeps enough operational evidence for another participant to check why that transition happened.
That separation is what keeps automation useful without pretending software consensus can inspect the physical world.

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.
The contract does not decide whether the physical room was safe by itself.

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?

AMove room control and all sensor readings into the contract as physical proof.

BTreat one accepted handoff as proof against outages, delays, and key changes.

CPostpone membership, keys, rule updates, and recovery until contract launch.

DRecord handoff, gateway validation, batch, trigger, exceptions, governance, replay, and retest.

Show answer

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

AKeep the ledger result because deterministic code proves the room state was true.

BMove all raw readings into contract to eliminate gateway clock faults.

CPause or correct under governance; replay telemetry, signatures, rules, and clock evidence.

DLet partners patch local ledger history until their results agree.

Show answer

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