However, while there is tremendous promise, blockchain technologies must evolve substantially to meet IoT’s unique demands. The unique characteristics of IoT applications impose both technical and economic requirements that lead us to conclude that IoT applications must be situated within an economic, legal and regulatory context that extends beyond the blockchain. In particular, whereas traditional blockchain applications ascribe all authority to the blockchain, we believe IoT applications must achieve a balance of authority.
Requirements in Blockchain Tech
Establishing trust in the information shared among Things creates new requirements for blockchain technologies. Generally, blockchain technologies operate as an authority for well-defined, deterministic systems. However, information created by Things sits outside the blockchain and is notoriously ambiguous and non-deterministic. Providing information assurance for qualitative data imposes new requirements on the technology.
Requirement 1: Identity and reputation of participants is central to trust and must be exposed.
Public blockchains like Bitcoin typically provide a history of the transactions on assets while anonymizing (or at least attempting to hide) the identity of those performing the transactions. For IoT applications, however, information becomes more complex than simple ownership of an asset. In particular, most information generated at the edge is strongly qualitative; and once information becomes qualitative, its provenance – including the identity and reputation of the source – is critical. For example, a blockchain can accurately record the transfer of access rights to a piece of information that asserts that a container was shipped across town. However, a blockchain is unable to assert the authenticity of the GPS readings captured in the shipping record.
Purists from the cryptocurrency world will argue that a “permissioned blockchain” is an oxymoron; however, some form of identity verification is required for participants who join the network so they can trust the information the Thing contributes to the collective. This demand has led to the formation of private, permissioned, closed, and enterprise blockchains – all variants on the theme of restricted participation in the distributed network. There is another possibility that Things may be identified or otherwise certified to contribute information to an otherwise public blockchain – some sort of hybrid model that attempts to validate input but not restrict inputters. Other possible solutions involve the use of anonymous credentials and verifiable claims.
Requirement 2: Controlled access to information is critical.
Typically, blockchain transactions are transparent. The introduction of smart contracts that codify and execute detailed agreements between participants complicates this notion. Businesses don’t like to share confidential data with competitors. Smart contracts will be powerful tools in IoT, particularly in supply chains that include third party logistics companies. It’s quite common for disputes to arise at handoff points where there is transfer of custody of an asset. The ability to prove that the temperature of the container remained within contract parameters should allow immediate trigger of payment. Or conversely, proof that the good spoiled under party eight’s custody in a twelve-party supply chain that all participants can view will quickly resolve finger pointing. And this proof must be constructed without revealing additional confidential information. For example, if an organization is collecting bids on produce that was in that container, the organization may not want all bidders to see every bid or to know the final sale price. In general, the information shared through transactions is subject to a potentially complex set of access policies.
Requirement 3: Efficiency matters.
Another core principle of blockchain is redundant compute and storage: every participant processes all transactions and maintains the ledger, creating an ever-growing demand for storage across the network. In IoT, where lightweight nodes at the edge frequently have extremely limited storage and compute power (because their primary purpose is to sense raw data as economically as possible), IoT blockchains will likely need to recognize the variety of nodes in the network and their relative capabilities. The blockchain itself may need to orchestrate which clients act as lightweight nodes, and which act as validators. Further, we are likely to see an increasing variety of consensus mechanisms that do not require massive quantities of computing power or specialized hardware, and are thus easier to scale or run on existing deployed equipment. (Note, also, that while redundancy is often viewed as a feature for blockchain integrity, one that increases the cost to a malicious actor that seeks to break network consensus and introduce fraudulent transactions, it also simultaneously expands confidentiality risks. Ledger replication offers a wide surface area for attackers seeking access to individual nodes’ sensitive data.)
Requirement 4: Connectivity is intermittent; action must be taken when disconnected.
Intermittent connectivity seems paradoxical to the Internet of Things. As Jacob Morgan defined IoT in Forbes in 2014, “Simply put, this is the concept of basically connecting any device with an on and off switch to the Internet (and/or to each other).” The IoT community spent a lot of time espousing pervasive connectivity and a reduction in transmission and storage costs; however we now confidently make tradeoffs between connectivity and battery life, connectivity and transmission cost, connectivity and infrastructure cost. There are many, many edge nodes which by design receive or send data only intermittently and in small quantities. In essence, the same forces that drive autonomous interaction to the edge also require blockchains to accommodate connectivity constraints.
Requirement 5: Actions must be reversible.
To this point, the requirements we’ve discussed have been rather peripheral to the core of blockchain technology, focusing on performance and deployment characteristics; this one, however, represents a fundamental shift in one of the central tenets of the technology. Specifically, blockchain technology is founded on the principle of immutability; once something is committed to the log it never changes. This principle is particularly appropriate for the preservation of a record of unambiguous and deterministic events (such as transactions that represent the transfer of ownership of assets). However, data from the edge is often messy.
Precision and accuracy are limited by the physical capabilities of the Thing. And information generated at the edge is subject to a variety of malicious attacks that are difficult to detect. The messiness of data created (and consumed) by Things leads to a level of ambiguity and non-determinism that conflicts with blockchain technologies. Consider, for example, a smart contract that adjusts the target speed of vehicles on a road based on measured traffic flow. Weather issues that affect the accuracy of the flow sensor might trigger adjustments in the target speed that are unintended. A more troublesome example might occur when automatic payments are triggered when a shipping container arrives at a facility. A faulty RFID reader could report the existence of a container that has not actually arrived triggering an inappropriate transfer of funds.
Often, some form of external recourse can audit and prescribe corrective transactions that address these problems (though this implies the existence of an external authority). However, issues arise where the information itself is problematic. For example, personal information might leak into a transaction; the effect of GDPR and other privacy regulations may require that information be removed from the record. This problem is not unique to IoT applications though we expect it to be more common in them.
Beyond the technical requirements are simple economic barriers to blockchain adoption in IoT. Enterprises are familiar with centralized systems and in traditional, linear supply chains, they work well. When there is a strong purchaser at one end of a supply chain, there is every reason for that entity to simply set up a distributed database (that it manages centrally) and require all vendors participating in its supply chain to enter their data into it.
Until we enter the realm of multiple overlapping ecosystems and complex non-linear, dynamic supply chains (think: distributed manufacturing with over a dozen contributors to any given Thing printed, each with unique IP, equipment, and certifications), it is difficult to find an economically compelling use for truly decentralized ledgers.
Over the next couple of years we will likely see an increasing number of pilots and small scale deployments using the technology in sub-optimal usages, e.g. standard supply chains with a dozen or so participants to improve speed of asset tracking or provenance and reduction of disputes through audit – all important advances in IoT. In these early trials, industry and ecosystem leaders will seek to prove cost savings or incremental revenue.
We may then witness the evolution of standards that allow for cross-organizational device identity and configuration, with early methods for partitioning workloads across the variety of IoT devices, and protecting data or its meta-inputs via linked trusted execution engines or retention of encrypted states as data moves across edge, fog, and cloud nodes. Devices will autonomously form communities, exchange information, and present us with options for action based on their interactions.