Generic Thin Operating System for Blockchain IOT Devices

Continuing the series of posts related towards concepts that an entrepreneur could develop into a profitable business and company, we will look at the use of the blockchain to control IOT systems. The idea is based on nChain’s patent number WO 2017/187397 Al.

The world will soon be awash in IOT devices. Such devices may be extremely small and contain only limited processing and memory capacity. It would be an advantage to have an operating system that is generic yet small enough to be loaded into any device and yet retains strong cybersecurity. A further advantage is to enable simple, secure, and robust control functionality including the possibility of processing payments for services provided by the device. The preceding goals can be achieved by interfacing IOTs to the Bitcoin-blockchain protocol.

The Metanet is the network of everything.

When you come to understand the idea fully, you start to see that you can capture information and control sensors and gate and control systems in a manner unlike and far superior to anything that came before. Sensors send to and watch the blockchain. They do not ever interact directly with a command system. The ability to set monitor keys that are derived keys means that an external attacker would not even know what keys are used.

Key Elements of the System

  • An operating system: purposefully ‘thin’ (small size) and therefore implementable on any IOT (exact specifications not discussed herein)
  • Easily ‘upgradeable’ as device-specific function is not hard-coded into the device, but rather loaded in from a secure repository such as a DHT
  • Managed by autonomous agents (either resident on the IOT or external)
  • Interfaces with the blockchain to enable functions inluding the processing of payments
  • Robust security (based on the Bitcoin ECC)

The Implementation

A blockchain IOT device (BID) is an agent set up to execute certain instructions that are securely stored off-BID and accessed through cryptographic keys. In a preferred embodiment, the BID resides on the IOT itself, but in other embodiments, it may reside off-device and have internet connectivity to the device. The IOT device has its own key (and an IP address) so it can securely communicate with other devices or DHTs, etc. Its ‘operating system’ is a simple generic system with some embedded functionality for (at least, but not limited to):

  • cryptographic calculations
  • retrieving instructions from an external source (such as a DHT)
  • performing simple actions such as toggling switches (i.e. as on the physical IOT device)

Thus, the BID does not contain its own instructions embedded, and does not ‘know’ what it does or how to do it; it only contains a way to securely retrieve instructions. A BID can only perform a set of simple actions (the following are illustrative only and not limiting):

  • Access to its own master private-and-public key pair
  • Ability to send data to an IP address or receive data from an IP address
  • Secret-sharing-protocol (#42) calculations

In one embodiment, such actions are embedded in machine code, and:

  • look up and interpret data stored on the blockchain; and
  • operate (through a standard API that is essentially a mere set of switches) the physical device it is attached to.

All of a BID’s communications are encrypted (see invention #42). Doing so allows:

(i) greater security from hacking

(ii) simple universal software-upgrade protocols

(iii) device agnosticism

The intention is a generic operating system that is usable in any IOT device. The device itself is not programmed—all programs are stored separately and loaded onto the device at set-up time (or, in some embodiments, at execution time).

Auto-feeder Example

The following illustrative example relates to the auto-feeder IOT device. The following is also a recap of the system.

Carol’s two dogs Archimedes and Bertrand are left alone all day in the backyard, and they are both friendly to each other provided they do not eat at the same time, which for some reason causes them to get very aggressive and fight each other. A and B both have identifying RFID collars, which are detectable by an IOT auto-feeder that dispenses specified quantities of food.

Transactions are set up to hold (through metadata linking to the DHT or even in a Metanet transaction) a set of instructions to control the IOT and a generic agent. The blockchain is used not only as the control mechanism but also to record information (such as for the ability to capture the number of feedings, what time they occurred, which dog ate, has maximum food allocation been dispensed, etc.) and provide cryptographic security. An important function of the transaction is to ensure that food is dispensed only if one dog is present at the feeder at the same time. Such is done with an XOR function as per the truth table:

  • If neither A nor B are at the feeder, do not dispense food;
  • if A is at the feeder but not B, dispense food;
  • if B is at the feeder but not A, dispense food;
  • if both A and B are at the feeder, do not dispense food.

When a dog is at the feeder, its RFID signals to the auto-feeder to unlock the dog’s secure current puzzle solution (which is securely replaced with a new puzzle solution after each iteration). If not, a random number is presented instead.

The BID Operation

The auto-feeder is a BID, monitoring its own state. It stores two secret values (S1 and S2) received from a separate control agent. They are used conditionally when the dogs’ RFID collars are detected within range. Based on its instructions as retrieved from the appropriate DHT, on detection of an RFID within range (along with other conditions related to the time of day, number of previous feedings, other restrictions, etc.), it sends a signal to a generic agent acting as its control agent (see below). The signal includes:

  • S1 (= Puzzle-A Solution)— if Archimedes’ RFID is detected else Random Number
  • S2 (= Puzzle-B Solution) — if Bertrand’s RFID is detected else Random Number

The auto-feeder then:

  • checks for a valid UTXO indicating that the previous related UTXO has been spent (i.e. meaning that it passed the current XOR test) and guaranteeing that required information has been stored (i.e. regarding the feeding event);
  • if the above answer is true, then it performs its conditioned instruction (here dispensing some food)
  • receives a transmission from the control agent enabling it to share two secrets (S1 and S2, as per below) and internally updates the secret values — ready for the next iteration.

The big issue in IOT is valuing data — trust me when I say, people start to set the value of data and create information where there is a cost.

With 50 billion IOT devices expected to be online in the next 5 years, there is an opportunity.

If you think about it, you start to see that we can easily port anything that IFTTT does, but without a company in control.

50 billion machines each making many small transactions and saving and accessing data to and from the ledger… I think the miners will be just fine.