Go up to the Table of Content!

3. IOTA in a Nutshell

At the end of 2016, the execution rate of IP traffic was around 1.2 zettabytes per year — enough data to fill over 9 billion of the iPhone’s highest available storage capacity at the time [CISC17]. Over the next five years, global IP traffic is expected to increase by fivefold, with monthly IP traffic reaching an 31 gigabytes per capita in 2021. But there is one big problem. In the same period, broadband speed expected only to double, and the electromagnetic spectrum is a fundamental limit for wireless communication. The global data pipelines will be overloaded. It will not be possible for all these devices to continuously connect to centralized cloud silos for all the data they will produce, nor will it be possible for the analytics engines in these clouds to react to the actuators to respond to the data in real time. This is where ’fog’ and ’mist’ computing come into play. The resources like memory, storages, and bandwidth must be distributed across the whole landscape, which immediately raises the question of how this can be done in practice with all the bureaucracy when there are 10, 100 or even 1000 actors involved in this new machine economy. This mystery was the reason for the foundation of IOTA. Through feeless transactions, these devices can share these technological resources locally in real time over a distributed network, eliminating central points of failure, relieving resource infrastructure. The objective of IOTA development was therefore to create a transactional backbone of the machine economy for data and monetary streams, with the purpose, to fulfill their four requirements of a secure, lightweight, affordable and scalable technology, see Fig. 13.

Fig. 13: Features of IOTA ‘s Tangle. Image: © WZL | Anton Shirobokov

In an IOTA economy, people, cars, robots or other IoT devices exchange data with the IOTA Peer-to-Peer (P2P) network. Each IOTA node of this P2P network executes a copy of IOTA’s Tangle, which allows you to attach your own and third-party unconfirmed transactions. The design of the tangle allows any operator to operate an IOTA Full or Light node on almost any device. Currently, the IOTA Foundation recommends providing at least 4 cores, 6 GB of memory and 40 GB of storage, requirements that probably exceed those of any top of the line smartphones. Of course IOTA supports remote PoW for delegation in case resources are limited.

In order for a transaction to be accepted by the tangle one has to confirm two previously unconfirmed transactions and perform a PoW. This makes the new transactions a tip. A tip transaction is an unconfirmed transaction waiting to be validated and confirmed, see Fig. 14. The premise is that as more transactions occur, the network will be able to scale faster since there are more verifications being performed in parallel.

Fig. 14: From IOTA node to bundle hash. Image: © WZL | Anton Shirobokov

A transaction consists of a bundle of information, such as the transaction ID, a message to send, the recipient’s address, a value if someone wants to transfer financial resources/money with the transaction, a tag to summarize messages or transactions, a timestamp, and much more necessary to participate in a validation process.

A typical IOTA transaction

Imagine two machines in a common hall that are running autonomously. Those machines have to perform different production steps that cannot be standardized or automated due to process fluctuations and a large variety of products. Those two machines were not procured through traditional method, but instead leased via pay per use model. In order for the machine complete their activities, ‘Alice’ negotiates a price with ‘Bob’ depending on the activity to be performed. see Fig 15.

Fig. 15: Overview of an IOTA transaction. Image: © WZL | Anton Shirobokov

IOTA transactions are encrypted and it is based on Trinary logic. Each encrypted transaction is 2673-trytes large. Once decoded, the transaction object consists of the following elements [SCHI18]:

- hash: string: 81-trytes unique transaction (tx) hash

- message: string: 2187-trytes signature message. If values are spend, the message contains the signature of the private key. If no values are spend, either the message is empty or contains a arbitrary input

- address: string: 81-trytes address, either of the recipient or the sender

- value: integer: tx value in iota

- timestamp: integer: time and date of the tx

- currentIndex: integer: the index of this tx in the bundle

- lastIndex: integer: the total number of tx in the bundle

- bundle: string: 81-trytes bundle hash to group bundle's tx

- trunk: string: 81-trytes hash of the first tx that was approved with this tx

- branch: string: 81-trytes hash of the second tx that was approved with this tx

- nonce: string: 81-trytes hash. The nonce is required for the tx to be accepted by the network. It is generated by doing PoW.

In our example, a transaction object (TR0) looks like this: Machine Alice and machine Bob have agreed on a value of 62 iota. This sum must be paid by machine Bob to machine Alice, for which machine Alice carries out a production step called C2123.

Getting the meta infos and transaction number

In this case the message field corresponds to the signature of the private key ( message:Signature part 1 ). Since this is an outgoing transaction, the address field contains the address of the sender Bob ( address: Address Bob ). The value field is logically -62, since Bob sends money and does not receive it ( value: -62 ). For simplicity’s sake, any string is used as a tag ( tag: for service C2123 ). The timestamp results from the day and the date of the transaction ( timestamp: 16.05.2018 11:22 ) [LULO18].

Machine Bob would like to give an additional message to Machine Alice. However, since the signature of the private key is already stored in the message field, it cannot store any further messages there. Therefore, Machine Bob must initiate another transaction TR1 of zero value ( value:0 ), which he can submit with the first transaction TR0 of -62 iota. In the message field of TR1 machine Bob can send any text ( message: Signature part 2 ).

On the other hand, machine Alice receives only one single transaction TR2, namely the one with a credit of +62 iota ( value:+62 ). However, the address field of TR2 contains Machine Alice’s address ( value: Address Alice ), since she is the recipient of the +62 iota.

In summary, 3 transactions must therefore be carried out. The value of lastIndex is therefore 2 in all three transactions (because counting starts at 0, 1, 2). The currentIndex of TR0 for +62 iota is 0 , the currentIndex of TR1 for the additional message is 1 and the currentIndex of TR2 is 2 .

Calculating the bundle hash and signing

The Bundle hash can only be calculated from the above fields. The Kerl hash function and sponge/squeeze constructor are used for the calculation. This means that the above fields ( address, value, tag, timestamp, currentIndex and lastIndex ) of all CurrentIndex are successively absorbed in exactly this order. As a result, the Bundle hash is squeezed out. The Bundle hash is identical for all three transactions ( bundle: Bundle hash for TR0, TR1, and TR2) [HOPE18].

Although for didactic reasons we have already discussed above, which content comes into the message fields, the signature for the message field can only be calculated with the bundle hash. Thus, the message fields are filled in only now (TR0(-62 iota): message: Signature part 1 = signed(AddressPrivateKey,BundleHash , TR1(0 iota): message: Signature part 2 = Not signed message string ).

Selecting tips, trunk and branch

The Monte Carlo Markov Chain algorithm is used to get two tips of the tangle. Simply put, these are the transaction hashes of two previous transactions that need to be confirmed. This allows you to attach your own transaction to the tangle. The tips are distributed to sender and receiver branches and the trunk hashes reference themselves if necessary, if additional messages are sent, see Fig. 15. For more information, please refer to the IRI Handbook [IRIA18].

Proof-of-Work (PoW)

In addition to the actual transaction data, a transaction also consists of a nonce. A nonce is a random pseudo number from cryptography used to validate transactions. The proof of work is thus carried out by iteratively finding a certain pattern. IOTA’s proof-of-work algorithm is comparable to hashcash approach, see Fig. 16. A random nonce is hashed and converted to trits using the hash function curl. If the last 13 trits are 0, the pattern has been fulfilled and the PoW is complete. If the hashed nonce deviates from this pattern, a new nonce must be advised and the process starts again. Once the nonce is found, the transaction hash can also be determined and the bundle is complete. IOTA nodes then check the nonce, verify the transactions and attach them to the Tangle. Once transactions are validated by other transactions they are immutable.

Fig. 16: How to find a nonce. Image: © WZL | Anton Shirobokov

Development of further technology layers

Three developments are to be highlighted here, as they open up special possibilities in the course of the machine economy: Masked Authenticated Messaging, Flash Channels, and Data Marketplaces, see Fig. 17:

Fig. 17: MAM, Flash Channels and Data Marketplaces extend IOTA functionality. Image: © WZL | Anton Shirobokov

Masked Authenticated Messaging

Masked Authenticated Messaging (MAM) is a way to send encrypted messages over the tangle. Three types are supported (public, private, and restricted) [HAND17].

In public mode, the messages are broadcast similar to a radio broadcast. Possible use cases are announcements of devices or persons, with the advantage that they are now immutable and their data integrity can be checked.

mode, the messages are broadcast similar to a radio broadcast. Possible use cases are announcements of devices or persons, with the advantage that they are now immutable and their data integrity can be checked. In private mode, only the recipient can decrypt the MAM stream.

mode, only the recipient can decrypt the MAM stream. In restricted mode, an authorization key is added to the private mode. This means that access can be given and revoked to particular subscribers.

Flash Channels

Flash is a bidirectional off-tangle payment channel that enables instant, high-throughput transactions. Essentially, they provide an opportunity for parties to trade at high frequency without waiting for every transaction in the public IOTA network to be confirmed. Instead, only two transactions will ever take place on the IOTA main network: opening and closing transactions on the Flash channel. An off-tangle approach reduces overhead per transaction to a negligible level by creating signed transactions outside the tangle and opening a fee-less transaction model for instant token streaming [FREI17].

Data marketplace

The biggest obstacle to achieving the size targeted by Big Data is the fact that the vast majority of data remains enclosed in data silos. Data silos do not or very rarely pass on their data outside their own closed environment. This leads to enormous data loss, often over 99% of the data is lost [MANY15b].

Fig. 18: Oil rigs only store and analyze 1 % of data. Image: © WZL | Anton Shirobokov

However, siloed data can contain very valuable information when it flows freely into data streams that form an open and decentralized data lake (data marketplace) accessible to any compensator [SONS17].