9 Factors of a Well-Tuned IoT Network Architecture

There are nine factors IoT firms must be aware of to achieve success in the coming years. They involve ensuring that IoT tools can connect to other standards and systems, remembering that IoT Interacts with the real world, achieving future-proofed scalability through a hub-and-zone model, and more.

Factor 1: IoT Is Naturally Multi-Party

One brand’s device needs to talk to another brand’s device, and this needs to be controlled by an app that runs on another machine (multi-party). Connecting devices is an n-squared problem. To connect nodes of a network, you need as many connections as the number of devices and apps in the system, squared. This is typically done with APIs. Each device, or back-end server, needs to work with as many APIs as it is connected to. Changes to APIs require changes to firmware. This is impossible to scale across all the permutations of APIs that any one device could connect to.

Multiple parties need a simple and common way to trustfully interact. Open-source tools are shared by the entire ecosystem, as opposed to some of the emerging IoT platforms that are centrally controlled and operated by a potentially competitive stakeholder. A well tuned IoT network is designed around community building in multi-party open source IoT systems.

Factor 2: IoT Tools Need to Connect to Other Standards and Systems

In a previous blog, Matthew Gregory, Ockam’s CEO, discussed why developers hate the idea of universal, siloed, do-it-all, top-to-bottom IoT platforms. The cloud developer’s open-source tools and services are organized into horizontal specialized layers that make up stacks. IoT tools must be interoperable with other layers in a software stack and fit into the cloud OSS frameworks that developers love.

For example, the open identity standard called decentralized identifiers (DIDs) make it easy to create cryptographically-secure identities for an array of entities. This feature extends not just to devices, but it’s also possible for DIDs to represent people, organizations, or any type of entity you could think of that is compatible with a DID registered device. In this way, developers are able to easily codify complex graph relationships between people, organizations, devices, and assets and to make these relationships available across the service stack.

Factor 3: IoT Relies on Certainty

IoT systems should rely on an immutable and unique cryptographic identity that has been claimed by each device in the network. Every time a device sends data to another device, or to a data store, it should sign that data with its cryptographic key. Moreover, a developer should be open to choose whatever cryptography method is appropriate for the security needs and hardware capabilities of their device without sacrificing system interoperability.

Each device also needs to know what type of cryptographic method was used to sign messages they received. This is solved technically and through open availability through the aforementioned DID standard. This guarantees that every bit of data that moves through the network can be trusted and that every device can be certain of who sent what data.

Factor 4: IoT Interacts with the Real World

IoT systems require fast finality in a state machine and consistent data everywhere in the network. Blockchain is a great state machine tool; however, many general purpose or financially-tuned blockchain networks are OK with temporary forks (aka data partitions) because the digital world can be corrected upon group consensus as time passes. Unfortunately, in the case of IoT, finality affects real world outcomes.

Consider the case of a remote-controlled floodgate. If an actuator on a floodgate gets a command to open the gate, water will rush down the hill. However, after a couple minutes, if the actuator learns it was connected to a partition of the network that had bad data, it can’t go back and put the water back where it’s supposed to be. This type of partitioning happens regularly in probabilistic finality blockchains such as Ethereum.

In distributed systems, what I just described is referred to as the CAP theorem. The CAP theorem states that a distributed system can’t have consistency, availability, and partition tolerance all at the same time. You must pick two at the expense of the third. Many blockchain networks are available and partition (“AP”) tolerant . However, because IoT affects the real world, the network needs to be a consistency and partition tolerant (CP) orientated system so there is consistent data everywhere in the network.

Factor 5: The Network Should Be Close to the Device

The closer a device is to the network, the faster and more reliable the connection is between device and network. If the network is broken up into zones, they can be distributed globally, thanks to the global footprint of public cloud infrastructure. This proximity maximizes performance between the IoT device and the network.

Factor 6: Achieve Scalability Through a Hub-and-Zone Model

Future scalability is a hot topic in IoT. Today’s IoT networks need to process high volumes of data. Tomorrow’s will need to produce tremendous amounts!

A hub-and-zone structure solves this problem. As IoT demands increase, a network can scale horizontally by adding as many zones as needed for throughput demand.

Factor 7: IoT Systems Produce a Ton of Data

As we previously discussed, we love blockchain’s structure as a state-machine that enables multi-party ecosystems. However, a blockchain network also needs to be tuned for IoT so it can accommodate the huge volume of data that IoT devices generate. In isolation, this data is of relatively low value. However, the true value of IoT is unlocked when huge amounts of data feed higher-order processes such as AI/ML. A blockchain network must have very low compute costs, which means developers can get more value (and trust) out of their applications.

To put it simply: moving data in an IoT network can’t cost more than the data packet is worth! This means compute resources need to be used to process transactions and not wasted on generating consensus through other mechanisms, such as proof-of-work-based systems.

Factor 8: Flexibility for Public and Private Consortia

A device owner may only want to share data among trusted business partners. However, they may also want to deliver a zero-knowledge proof on the state of their data to an external regulator, partner, or customer.

This is another benefit of a zone-based infrastructure footprint. Private zones should keep the data in the zone private to the zone but still allow permissions and proofs to be represented externally to public zones.

Factor 9: IoT Devices Need to Validate Network State

Most IoT devices are built to extremely tight tolerances and don’t have resources to spare. Low-power wireless devices with simple hardware need a low bandwidth way to stay in sync with the current state of the network.

Network clients need to be offered a light version that is honed for low-power devices. Moreover, devices need to sync with the state of the network when a device is turned on or comes back online. Catching up to the state of the network requires a network design that enables a low-power device that has intermittent connectivity to get caught up in a couple kilobytes.