Mic Bowman is a principal engineer at Intel and a member of CoinDesk’s advisory board. Camille Morhardt is the director of IoT strategy at Intel.
The following article originally appeared in Consensus Magazine, distributed exclusively to attendees of CoinDesk’s Consensus 2018 event.
The edge is messy.
And the edge, where billions of interacting devices that will make up the Internet of Things will reside, is where IoT data is generated and acted upon.
There are often no secure physical perimeters where the raw sensing of the physical world takes place: on rooftops and space stations, inside mines and aircraft engines, on container ships and solar panels. Even edge counterparts that aggregate, filter, normalize, and increasingly interpret data, or send it to a cloud for additional analysis, are often mobile, have intermittent connectivity, and are subject to shock, vibration, or extreme temperatures.
As Things increase their connectivity and intelligence, so too will our demand for them to autonomously form networks, exchange information, and coordinate action on our behalves.
When we order an article of clothing online, for example, we indirectly call on, among others, a fashion designer, raw goods suppliers, logistics companies, customs, a distributor, an importer, a buyer, an inventory management system, a customer management system, a bank, a web management system for product placement and pricing, a retailer, and a last-mile delivery driver.
Were each of these participants able to gain near real-time insight into our purchase and its progression from factory to front door, they might be able to collaborate to optimize multiple independent systems near real-time to get me the product as fast and in as good condition as possible – especially if there are unforeseen setbacks en route – a flat tire! – while preparing for their next order.
Yet the formation of these networks is rife with problems. In the best case, information collected, shared, and acted upon is inconsistent in quality and availability. In the worst case, it provides a completely new attack vector for malicious participants. When Things plan and act on our behalves, we want assurance that the data they utilize to make decisions is trustworthy.
Ensuring that information is trustworthy is hard enough when a central authority orchestrates device configuration, data collection and cleaning, and data dissemination. However, distributed networks can’t rely upon a central authority.
Traditional means to assert and verify participant identity and integrity fail, because participating Things are made by different manufacturers, run different operating systems, communicate with different protocols, and act on behalf of different owners who have different motives. The answer may well lie in the emerging technology that has become known as “blockchain.”
Blockchain – or distributed ledger technologies in general – offers hope for expressing and establishing shared trust in information created and exchanged by Things: the immutable log of events that is the blockchain provides a means to establish authoritatively the provenance of information; to record and enforce policies for accessing the information; and to act on the information autonomously through “smart contracts.”
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.
Technology requirements
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.
Economic Requirements
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.
However, the competitive environment in which these incumbents operate in is rapidly changing, with 3D-printing enabling distributed manufacturing, and barriers to entry around machine learning and other fast-developing technologies lowering. To compete, enterprises may be forced to adopt more open systems. The IoT industry is inevitably expanding into more complex ecosystems. As a result, we expect compelling use cases for blockchain will become more apparent.
Herein lies a conundrum. Single strong purchasers orchestrate ecosystems around a supply chain because they accrue revenue by doing so. Distributed collaboration results in distributed value, so there is little incentive for any single, incumbent entity to set up the infrastructure to distribute orchestration. Blockchains are uniquely suited to micro-transactions, so scale may help solve this problem. The IoT community has seen a few subscription models and nonprofit models. However, until there emerges a clear, repeatable, compelling business model, adoption of blockchains for IoT will be slow.
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 will 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.
Finally, we will likely see commensuration of data generated at the edge – not just across autonomous Things or organizations, but across autonomous ecosystems. At this point the blockchain will be more efficient than centralized systems at managing the complexities of non-linear supply chains, managing identity, provenance, shared data sets, and running smart contracts.
While we will be trusting machines to make some decisions and take some actions on our behalves, businesses in IoT will always want to retain the ability to revoke or reverse the actions taken by a smart contract, since humans are notoriously bad at contingency planning or future prediction, and the equipment that will be acting on our behalves will also often be responsible for keeping us safe.
Recommendations
We often talk about a blockchain as a replacement for a trusted third party for interactions within a community; that is, the community ascribes to the blockchain ultimate authority about “truth.” For applications built around a network of Things, however, the blockchain must be situated within a much larger context that incorporates institutional relationships, legal requirements, and regulatory control.
There is a very real danger for those deploying blockchain-based solutions for IoT to believe that the tamper-proof nature of the blockchain provides assurances about the integrity and trustworthiness of information (and about actions driven by that information).
A more realistic view is that the role of the blockchain transitions from a source of “shared truth” about the state of a system to a log of “decisions and actions” that might need to be adjusted in the future.
Network visualization via Shutterstock