We use this tagline all the time when we tell people about the Ockam Blockchain Network. But did you notice what we didn’t say? Blockchain. Why? Because blockchain is not what Ockam is; rather, blockchain is just one component in how Ockam works. While it’s true that blockchain’s killer feature (identity) is one of its core components, Ockam is so much more than blockchain. The heart of the expression is the word “tuned”. At Ockam, we are building a new backbone for the Internet of Things, and we are doing it by building infrastructure and tools that let developers tackle their trickiest challenges.
So what exactly goes into tuning a network for IoT? Let me tell you about the the nine-factors that influence IoT network design:
Factor I: IoT is naturally multi-party.
One brand’s device needs to talk to another brand’s device and it needs to be controlled by an app that runs on another machine: that’s multi-party. Connecting devices is a 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 and 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. The open source Ockam is 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. The Ockam Network is designed around community building in multi-party IoT systems.
Factor II. Cloud technologies are organized horizontally, so IoT tools need to connect to other standards and systems.
In a previous blog I discussed why developers hate the idea of universal, siloed, do-it-all, top-to-bottom IoT ‘platforms’. The cloud’s developer tools and services are organized into horizontal specialized layers that make up stacks. Ockam must be interoperable with other layers in an IoT stack.
Ockam Network uses a common identity standard called DIDs (Decentralized Identifiers). This makes it easy to create cryptographically secure identities for an array of entities. This feature extends not just to devices, but also possible for DIDs that represent people, organizations, or any type of entity that you could think of compatible with an did:ockam registered device. In this way, developers are able to easily codify complex graph relationships between people, organizations, devices, and assets.
Since the Ockam Network leverages Tendermint as its node messaging layer and consensus protocol, Ockam Network is fully interoperable with the Cosmos Blockchain network. The purpose of the Cosmos Network is to join all of the Tendermint enabled networks to each other. This means that devices in the Ockam Network can be interoperable with any functionality that is connected to Cosmos. Finally, the Ockam’s Open Source Developer Experience (DX) layer makes it trivially easy for developers to build embedded software and web applications and to build embedded software that connect and interact with the Ockam Network with a couple lines of code.
Factor III. IoT relies on knowing ‘who sent what data’ with 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 datastore, it should sign that data with its cryptographic key. Moreso, 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.
Ockam Network solves this by utilizing the universal did:ockam identity scheme that enables best practices around key management. Regardless of the signature cryptography capability of the device on the network, a device can generate a did:ockam that can be reconciled by any other device with a simple verification to the Ockam Network. Every transaction on the Ockam Network must be cryptographically signed; it’s part of the Ockam protocol. This guarantees that every bit of data that moves through the Ockam Network can be trusted and any device can be certain of ‘who sent what data’.
Factor IV. IoT interacts with the real world — there’s no going back.
IoT systems require fast finality in a state machine and require consistent data everywhere in the network. By comparison, 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 of minutes if the actuator learns that 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 not 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 + partition tolerant (AP). However, because IoT affects the real world, the Ockam Network is consistency + partition tolerant (CP) orientated system. I’ll devote a later blog specifically to the CAP Theorem where I will discuss balancing benefits and tradeoffs in the CAP framework to meet the unique needs of IoT. For now, however, all that you need to know is that throughout the entire Ockam Network, there can only exist only one state (i.e. no forks) and, therefore, only one truth. The Ockam Network also has fast finality with new blocks every 1–5 seconds, which means that once new data is added to the state of the Network it is distributed everywhere — fast. Moreover, the revolution in trusted execution environments allows Ockam Network to run entirely in public cloud infrastructure. This helps to increase validator-node, storage, and networking stability which gives the Ockam Network rock solid availability and huge scaling potential.
Factor V. 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.
Ockam Network can be broken into zones that commit the merkle root of their state to a master hub. These zones can be distributed globally thanks to the global footprint of public cloud infrastructure that the Ockam Network is built upon. This means that an Ockam Zone can be located as close as possible to any device anywhere in the world. This proximity maximizes performance between the IoT device and the Network.
Factor VI. IoT devices are already deployed at massive scale, and growth is only accelerating
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!
The hub and zone structure of Ockam Network solves this problem. As IoT demands increase, Ockam Network can scale horizontally by adding as many zones as are needed for throughput demand.
Factor VII. IoT systems produce a ton of data
A blockchain network tuned for IoT needs sufficient efficiency to 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 with low compute costs 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!
In the Ockam Network transaction fees are low because consensus is derived efficiently by Tendermint’s BFT consensus algorithm. This means that compute resources are used to process transactions and not wasted on generating consensus through other mechanisms such as proof of work based systems, such as the bitcoin network.
Factor VIII. Flexibility for public + private consortiums
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.
The Ockam architecture allows private zones to interact with the public root zone. A private zone will commit the merkle root of its state to the main hub. This will keep the data in the zone private to the zone, but still allow permissions and proofs to be represented externally. This feature is further enabled by how did:ockam identifiers are specified.
Factor IX. Lots of IoT devices are hardware and connectivity challenged, but still 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.
The open source Ockam Client comes in a light version that is honed for low power devices. Devices can quickly get into sync with the state of the Ockam Network. For example, when a device is turned off it can catch back up with the state of the Ockam network by downloading a ~1kb header from the network. By comparison, some general purpose blockchain networks require a download of dozens of MBs for a client to catch back up to the current state — this is untenable, if not impossible, for an low power IoT device with intermittent connectivity. Ockam Network can support tiny IoT devices thanks to its architecture that leverages trusted execution environments in public cloud.
…And that’s it.
Those are the Nine-Factors that go into make “Ockam tuned for IoT”. The combination of the Ockam Network and the Ockam DX make Identity, Trust and Interoperability as simple as it should be.