13.1 Overview of Blockchain and IoT Convergence
13.1.1 The Trust Dilemma of Centralized IoT Architecture
Imagine a cold chain jointly operated by a manufacturer, logistics provider, and customer. Each party keeps its own temperature records, yet after cargo damage they produce different versions. The problem is not whether the database can scale, but that no party accepts another party's database as the final evidence. This hypothetical case illustrates a dispute across trust domains. If all participants belong to one enterprise and accept a unified audit regime, centralized logs and signed evidence are usually sufficient.
Most IoT platforms use centralized or layered architectures, but "centralized" does not mean that every interaction must pass through a public cloud. Devices can communicate directly over fieldbuses, edge gateways, and local controllers, while platform services can use clustering, cross-region disaster recovery, and independent auditing. Centralized architectures are mature and predictable in performance. Trust in a single operator becomes a business constraint only when multiple independent parties need to write or verify the same facts jointly.
Availability and concentrated control form the first class of risk. A central service without redundancy creates a failure domain, and overly broad administrative privileges expand the impact of an attack. Clustering, backups, least privilege, independent logs, and disaster recovery can substantially reduce these risks. A distributed ledger transforms a single-operator failure into multi-node governance and consensus risks; it does not "eliminate at the root" outages, vulnerabilities, or key theft.
Data interoperability and verifiability form the second class of risk. Data models and authorization policies across platforms can create silos, while highly privileged personnel may modify both a database and logs in the same trust domain. Start with lighter mechanisms such as open interfaces, data signatures, append-only logs, WORM storage, cross-account backups, and third-party timestamps. Evaluate a jointly maintained ledger only when those measures still cannot satisfy independent multi-party verification.
High cross-party trust costs are the deeper drag on large-scale IoT deployment. The participants along a single supply chain may include raw-material suppliers, manufacturers, logistics providers, distributors, retailers, and end users, each running its own information system. To get these systems to agree on the same set of data, the traditional approach is to bring in an authoritative third-party platform or regulator to centrally verify and distribute the data. The result of that approach is that every participant pays steep integration, audit, and legal costs, and the response speed of the whole process degrades noticeably. When something goes wrong in one link — a temperature anomaly in one batch's reefer truck, say — the parties spend enormous time establishing "whose data is trustworthy" rather than "whether the data itself is true." Trust is passed along through layer upon layer of contracts and after-the-fact accountability, with no technical foundation on which every participant can verify independently and in real time.
These three problems do not mean that "centralization inevitably fails." They ask whether the trust boundary matches the governance structure. Technology cannot replace contracts, regulation, and accountability, and distributed systems also require operating rules. Figure 13-1 should be read as a risk checklist for multi-organization scenarios, not as a verdict on every centralized platform.
When multiple parties genuinely need to maintain a verifiable record together, a distributed ledger is one candidate implementation. Signed logs, transparency logs, and regulated third-party evidence services are alternatives. Selection should begin with trust assumptions, not with a prior decision to "put it on chain."
13.1.2 What a Distributed Ledger Can and Cannot Provide
Return to the cold-chain dispute that opened this section. If the parties jointly confirm temperature digests, signatures, and timestamps at each handover, it becomes easier to identify which copy changed afterwards. A distributed ledger can carry that shared record, but it proves only that a digest was accepted under the agreed rules. It cannot prove that the sensor did not drift, that a private key was not stolen, or that the cargo's physical state matched the report.
Blockchain is one class of distributed ledger technology (DLT). Systems differ greatly in data structures, node roles, state pruning, and consensus. Not every node stores a complete copy, and not every DLT organizes data into blocks. Their shared value is that multiple participants can validate state changes under agreed rules and use cryptographic linking to make historical rewriting more detectable.
Dimension one: the distributed ledger delivers global data consistency
A permissioned ledger can let several organizations operate validating nodes and agree on defined state. Devices normally submit digests through gateways rather than broadcasting high-frequency telemetry to every node. Consensus confirms that "a transaction complies with on-chain rules and has been accepted"; it is not a network-wide endorsement that a temperature is true. Whether the system provides non-repudiation also depends on key ownership, the finality model, collusion assumptions, and preservation of off-chain evidence.
Dimension two: digital signatures and consensus make device identity trustworthy
Device identity commonly relies on asymmetric keys. A private key should reside in a secure element or a protected software environment, while verifiers validate signatures against trusted public-key material. The public key may be distributed through a CA certificate, DID document, platform registry, or another directory; a ledger is not a prerequisite for digital signatures. A signature proves that "a party holding this private key signed these bytes." Registration, rotation, and revocation processes must still establish device ownership and current authorization.
If multiple organizations do not accept a single directory operator, they can jointly govern public-key state or the verifiable data registry associated with a DID method. Consensus then records state changes; it need not participate in authentication of every device message. The choice among PoA, BFT-class protocols, and other mechanisms should follow node-admission rules, fault assumptions, and finality requirements.
Dimension three: smart contracts execute trust rules automatically
A great deal of IoT business logic takes the form "if a condition is met, execute an action automatically" — for example, "if the temperature exceeds the threshold and stays there for a while, start the cooling system," or "if a logistics truck enters the warehouse perimeter, open the loading dock." Under centralized architecture these rules are executed by backend business-logic servers; once such a server is attacked or misconfigured, the rules can be bypassed or tampered with.
A smart contract deploys repeatably verifiable state transitions in a ledger execution environment. A contract can be audited, but upgrade privileges, administrator keys, oracle inputs, and off-chain execution remain risk sources. For industrial devices, contracts are suitable for recording authorization, asset transfers, or approval results; they should not bypass local policy and safety controls to drive a valve directly. A typical chain is: the ledger emits a confirmed event; a controlled gateway verifies finality, permissions, and operating conditions; then it passes the candidate action to a deterministic control system or human confirmation.
These three dimensions — consistent state, verifiable identity material, and auditable state transitions — illustrate what a distributed ledger may provide. Under stated consensus, key, and governance assumptions, it can make historical rewriting more detectable, but it offers neither absolute immutability nor automatic proof of source truth. Sensor calibration, device identity, gateway processing, time sources, and human spot checks each require their own evidence. AI anomaly detection can add clues; it cannot serve as proof of truth.
Blockchain is no silver bullet. Its introduction brings new engineering challenges: storage and compute resource consumption far above centralized schemes, constrained transaction throughput (especially on PoW chains), loss of ownership when a private key is lost, and more. The sections that follow in this chapter discuss each of these in turn and give mitigation strategies. But viewed as a trust-building mechanism, blockchain — by rebuilding the rules at the data layer, the identity layer, and the business-execution layer — provides a verifiable trust foundation for cross-organizational collaboration in IoT systems.
13.1.3 Evolution Trends and Engineering Challenges of the Converged Architecture
Trust is not free. The gap between a sensor reporting one reading and a blockchain confirming one transaction — in frequency, in payload size, in latency tolerance — decides that "putting all data on chain" is an engineering non-starter. The converged architecture has therefore evolved through three stages of compromise, each one a trade-off between resource cost and strength of trust.
Stage one: off-chain storage + on-chain hash. Raw data (high-frequency temperature series, video streams, large files) stays in local storage or a data lake, and only a digest such as SHA-256 is submitted to the ledger. Recomputing the hash can show whether the current copy matches the bytes committed at that time. It cannot prove capture-time truth or, by itself, who produced the data and when. Signatures, trusted time, device calibration, and preservation of the off-chain original remain necessary (see Chapter 8).
Stage two: endpoints or gateways participate partially. A constrained endpoint usually does not retain full history or act as a validator. It queries proofs and submits signed transactions through a light client, trusted gateway, or remote RPC. Depending on the protocol, a light client may verify block headers, committee signatures, state proofs, or merely trust a server; those are different security boundaries. Offline transactions also require buffering, replay protection, and clock policy. This stage trades additional trust in gateways or full nodes for lower storage, bandwidth, and energy use. MCU suitability must be measured against the actual SDK, cryptography, memory, and network.
Stage three: business state is coordinated primarily by a ledger. This does not require every sensor to participate in consensus. Organization nodes or gateways commonly validate, while endpoints sign and submit. The stage fits a limited set of cases such as multi-party settlement or joint authorization and brings finality, fees, privacy, contract upgrades, bridges, and offline availability into the primary path. High-frequency fleet telemetry should normally remain off chain, with only necessary state or digests submitted.
Key engineering challenges and response paths
- Sharding: divide state and execution among parallel domains. It may raise aggregate throughput, but gains are bounded by load balance, cross-shard communication, data availability, and the security model; linear scaling cannot be assumed. Whether an endpoint holds shard state depends on its protocol role.
- Sidechains and Layer 2 scaling: high-frequency transactions complete in off-chain channels, and only the final state hash is committed to the main chain. State channels, for example, let devices exchange small amounts of resources off chain, but funds must be locked in advance and settlement risk borne. State channels are a better fit for IoT scenarios with low-frequency settlement; Plasma, an early Layer 2 scaling design, has since been largely superseded by rollups (zk-rollups in particular), which new designs should prefer.
- Candidate ledger platforms: architecture can change fundamentally between releases. IOTA, for example, evolved from its early Tangle narrative to a current architecture based on validators, Starfish consensus, and Move. IoTeX, VeChain, and Hyperledger Fabric have different admission, finality, privacy, and operating boundaries. Table 13-1 therefore avoids perishable TPS and "best for" labels and lists facts that selection must reverify.
Table 13-1 Release-specific verification points for candidate ledger platforms
| Candidate | Verify first | Device-access question | Evidence required before launch |
|---|---|---|---|
| IOTA | Current validators, Starfish, Move, fees, and finality; do not reuse historical Tangle conclusions | Is there an SDK, light client, or gateway proxy for the target hardware? | Current specification, independent throughput/fault tests, upgrade and key plan |
| IoTeX | Current consensus, identity, data availability, and network governance | Endpoint signing, proxy submission, offline buffering, and revocation | Target-network measurements, privacy and fee assessment, operating ownership |
| VeChain | Current validators and governance, transaction fees, and enterprise toolchain | How does device identity bind to the physical asset and accountable party? | Finality, key custody, contract upgrade, and cross-organizational acceptance |
| Hyperledger Fabric | Ordering, endorsement, channels/PDC, and organization admission | Endpoints normally call through an application or gateway; a peer is not a sensor | Node topology, policy, private-data availability, load and recovery drills |
Hidden costs and design constraints
Storage bloat: every participant keeps a complete ledger, and a size of tens of GB is entirely infeasible on an ARM Cortex-M. The common industry practice is for the device to keep only an index of its own transactions and entrust the full ledger to a cloud node — in essence, a partial retreat from decentralization.
Privacy exposure: blockchain's transparency conflicts with the privacy of enterprise business data. Some permissioned-chain platforms isolate private ledgers through a channel mechanism; a few public-chain schemes offer shielded channels.
The converged architecture will not move toward "fully on chain" in the short term; it will stratify by asset value, data sensitivity, and latency tolerance. The sections that follow work out concrete schemes for device identity, data trustworthiness, and supply-chain traceability.