Exploring the Role of Blockchain in Industrial IoT Systems (Part 1)

We're almost halfway into 2018 and blockchain is approaching the Gartner Hype Cycle's "trough of disillusionment". While that sounds ominous, I’m not convinced of its imminent descent since "blockchain" continues to garner a lot of press coverage. For many, blockchain is a technology hammer in search of a market nail. I'm sure you've heard or read about blockchain and wondered if it is relevant to your systems. We've wondered about this too and decided to spin up our research group to dig into it a bit deeper.

While cryptocurrency continues to steal the blockchain limelight (and sucks down staggering amounts of energy to support it), efforts have been moving ever so slowly into more relevant industrial use cases like supply chain management, inventory management, transactive energy, etc. For those of you using RTI Connext DDS in critical real-time systems around the world, we realize that cryptocurrency and supply chain management are not high on your list of capabilities that you might need RTI's attention.

RTI's stealthy but hyperactive research group has been working with the Department of Energy (DOE) to investigate how blockchain might be leveraged to secure industrial systems like yours. While we have many advanced research efforts underway with the Army, Navy, Air Force, DARPA, DOE and Missile Defense, this blog is focused on how our research on blockchain may be useful to your real-time industrial systems.

What is Blockchain Technology?

In order to set the stage for a discussion on industrial blockchain, let's take a quick look at blockchain technology for those of you who are new to it. Skip to the next section if you’re a pro already.

Today, we trust our banks, credit card companies, notaries and others as centralized arbiters to handle contracts or the transfer of money to someone that we owe. In online gaming, we trust the game server as a centralized arbiter to advance the state of game play between all participating players based upon the data we send to the server about our own actions. In industrial systems, the central arbiter of the truth is the company that owns and manages the system. In those and many other domains, that central arbiter manages databases (in blockchain-speak, "ledgers") about all of the data within a given system. That arbiter has complete control over what is written to the ledger, including the ability to modify (tamper with) the history in the ledger if desired. Malicious agents could also compromise those arbiters, and thus could tamper with the ledgers. So a single arbiter (ledger manager) can be a single point of data integrity failure. Blockchain technology is disruptive because it allows this ledger to be distributed and managed by multiple untrusted and mutually distrusting parties, while providing strong guarantees that this decentralized solution preserves data integrity. Each party participating in decentralized ledger management maintains and manages a local copy of the ledger. The number of parties may vary widely (from a few to thousands) depending on the desired characteristics/use of blockchain.

So what do you store in a ledger? First, information is written to the ledger in chunks called (as one might guess) "blocks." Blocks are composed of units of information which could contain practically anything – a corporate or personal contract, a warranty, an insurance policy, a patent idea, patient data, a bitcoin purchase, a photo, encrypted personal data, etc. This data can be encrypted if desired. For your industrial applications however, it's more likely to include sensor data, system state, and really any data samples you may want to immutably persist. How the information is chunked into blocks is really specific to the use case.

The concept of a chain is fundamental to the blockchain design because each newly added block is inextricably dependent upon the previous block, which is itself dependent upon its previous block – thereby forming a logical chain. An adversary seeking to modify the content of any block recorded in the past must then also change all blocks recorded since the beginning, in all distributed copies of the chain. The cryptographic technology used in blockchains makes change attempts clearly visible; in combination with distributed replication of the ledger, it makes the "rewriting of history" nearly impossible. An attacker would need to rewrite all (or most) copies at the same time.

When Do You Need Blockchain?

Blockchains are applicable in situations where two or more distributed groups do not trust each other or do not trust some centralized arbiter, yet where all have a stake in immutably recording data or the state transition of some system (e.g., a game, your bank account, etc.). In contrast, in systems where only one party is involved, such decentralized arbitration is not an issue. Within a company, for example, if the concern is about ensuring historical data is not tampered with, then a secure write-only database (utilizing write-once drives) might be sufficient. So, if your applications do not have any issues with a single central arbiter, if there is no mistrust of the data, then blockchain may not be needed. However, if you have multiple companies doing business, such as in a supply chain or on an oil rig, there may be concerns about whether the data can be trusted.

Traditional Transactional Blockchain

Now, in perhaps most use cases you've read about, blockchain is all about actively recording transactions, i.e., a transactional blockchain. The intent of this blockchain use case is to immutably capture and persist the transitioning of some system from one state to another. For example in the financial transaction domain, these state transitions are changes in account balances as transfers occur. This is why the data store is called a ledger and not a database.

What's important to understand is that the state of the system will not advance unless/until a transaction is accepted and stored into the chain. Moreover, if transactions can compete (like concerns about double-spending Bitcoins), then it will introduce latencies into processes that must be accounted for. As an extreme example, in Bitcoin, "to be safe" one might wait up to an hour to ensure that a transaction went through. While the insertion of a transactional blockchain will absolutely fit some industrial use cases (albeit, with far smaller latencies), let's defer this discussion and its solutions to a future blog.

Blockchain for Industrial Systems

In the use case I am focusing on here, we're grabbing specific data off the secured Connext Databus and storing it directly into the blockchain. We collect data selectively and store it immutably into several separately owned and secured ledgers. There is no concept of a transaction because we are not attempting to control the state of the system, we're just observing it. This is similar to non-real-time use cases for storing things like patent ideas, patient data and contracts on a blockchain. While smart contracts can be used, they are not part of the data validation process to control whether the data is added to the chain or not.

For real-time industrial applications, what is important is that the blockchain is not part of the process control chain, so it injects no latency. This application of the technology required a unique blockchain design specifically for this. Our design is much more conducive to being deployed within real-time industrial systems because we can eliminate the notorious latencies and transactional nature that blockchains are known for (while still maintaining consistency). For many use cases, any introduced latency may be a dealbreaker to their adoption.

This paradigm is ideal for a fully decentralized and secure industrial databus like DDS. It is fairly straightforward to integrate this type of blockchain – even into a fully operational system with zero downtime. How to employ a blockchain in your system is driven both by its design and by the use case you want to solve.

Read part 2 as I dive into how we applied blockchain to an Oil & Gas use case. I also delve into a specific prototype we implemented and explain why blockchain is just part of the answer.