IOTA, connecting the world

How many times have you heard about Blockchain and DLT in the past few months? A lot, right? In this post we want to give you another alternative to this type of technologies.

Although it has some of Blockchain’s features, it also has some particularities that make all the difference in certain IoT-based use cases. Today we are going to talk bout IOTA.

Context

At this point it is hard not to know anything about Blockchain and the benefits it can have for society. In other posts we have discussed terms like Bitcoin, Ethereum, cryptocurrencies or the Internet of Value.

But what new perspectives do technologies such as Tangle and IOTA bring to the DLT ecosystem?

A DLT (distributed ledger) is a consensus of digital data which are replicated, shared and synchronized by and are geographically distributed across many sites, countries and institutions. There is no central administrator or centralized data store.

IOTA is basically that: a DLT. What does set IOTA apart from other blockchain networks? Although it is true that there are many types of blockchain networks and many implementations with different characteristics (some of them similar to IOTA’s), we can sum it up as follows.

It does not use miners

The role of miner does not exist in IOTA’s ecosystem. It is a blockchain-type DLT with PoW that uses a block system to consolidate transactions. Blocks are mathematically solved by a group of nodes which are constantly trying to solve a mathematical problem by brute force and obtain a reward in return.

Currently there are on average 1,900 transactions for every mined block, so the computational effort is huge. Thus, it is necessary to use pools of miners working at the same time.

IOTA does not work like this because it does not require groups of dedicated miners. It only needs to validate two previous transactions per every transaction by means of a small proof of work, which is similar to that of other networks but less difficult.

There are no fees

Transactions are free.

It is scalable

There are no time or shape restrictions as to the DLT’s structure. Blockchain’s DLTs have a specific format, ie a number of time-limited transactions.

For example, the Bitcoin network currently has 1,900 transactions per block on average, every block lasting 10 minutes.

It is resistant to brute force (quantum computing)

As in the other DLT networks, there is a figure known as a wallet, ie an address where transactions are written down. Since these wallets are digital, they are protected by private keys.

However, the encryption systems that are used today could be compromised in the future by technologies such as quantum computing. IOTA has decided to solve this potential problem by implementing the Winternitz signature service.

A very important feature of Winternitz is the way in which it affects the use of wallets. We understand a wallet to be the receptacle where cryptocoins are kept. Contrary to other DLTs’ wallets, a wallet in IOTA is not reusable: it is like a money box in which you put coins, which you cannot take out unless you are willing to break it.

It is a that moment when you can grab the money you need and send it to another user – but you need to put the remaining coins in a new money box. As a result, the broken money box is accessible to all, so it must not be reused since any funds placed in it might disappear.

IOTA’s wallet software has the above rule coded in it and warns users about not using broken address. Therefore, if we program our software without taking this precaution, we might lose all the funds we put in the wallet.

The reason for this is that Winternitz shows part of the private key in the transaction’s hash – which, together with the address, would allow the funds to be accessed by brute force. This is why every time we use a new wallet, we are refreshing the security. We have explained how wallets are generated and the associated security levels below.

Zero value transactions and messaging

Text transactions to a wallet are allowed. In addition to being capable of sending and receiving coins, IOTA wallets have the capacity to send and receive messages.

At first this might not seem useful, but when there is an event as a result of the incoming message, we can react by sending a payment or another message.

In other words, if I receive the agreed text in my wallet, I could either make a payment or send another message – free of charge, since it is possible to send transactions with a message that do not have an economic value.

Light PoW

As in other DLTs, IOTA uses the PoW method to prevent spam, overloading the network through misuse or Sybil attacks. In IOTA the concept of ‘difficulty in the proof of work’ is static and is sufficiently light as to be able to make it from devices that have few resources.

Based on the above, a system has been created that is capable of making transactions between electronic devices or people through messaging, at no cost, without block time limitations, without dedicated mining nodes and without affecting the difficulty of the PoW.

For instance, up until now, with Bitcoin’s blockchain, miners have carried out the tasks of saving a copy of the database and finding and distributing the solution to the PoW; in return, they have received a financial reward, which ensures the stability of the network.

IOTA’s architecture is unique in that the interest of having a node that keeps the database and can provide PoW on demand is not a financial reward but that of generating its own transactions.

In other words, the tendency is for each user that makes transactions to keep their own data instead of involving a third party. This situation opens the doors to the data market.

The example in the preceding paragraph can be seen on this website. It is a PoC, where the owners of the data can monetize the information.

Tangle as a transaction support

In IOTA transactions are done without the intervention of a third role – the miner. This is possible because transactions take place between the issuer and the recipient only, with the particularity that the issuer must validate two other transactions that are to be sent to their respective recipients.

In other words, this action represents a directed acyclic graph. This graph has three layers:

  1. A layer of transactions that have been validated and consolidated within the graph (green).
  2. A layer of transactions that are undergoing validation and consolidation (red).
  3. A layer of new transactions that launch a request to be included in the graph and are waiting for new transactions (gray).

In this structure there is no time restriction, so all new transactions are sent without having to wait for the mining of other transactions that belong to a certain block. This is so because there are no blocks.

As in blockchain, in order for a transaction to be sent, it must contain a valid proof of work.

To make the PoW, the values that make up a transaction are taken:

  • Address: the address of the destination wallet that receives the tokens.
  • Tag: this value is for information purposes only and serves to organize the type of transaction.
  • Timestamp: the moment when the transaction took place.
  • Value: the number of tokens that are sent.
  • currentIndex and lastIndex: these two values are related to one another and attempt to identify the current transaction within a set of transactions, which form a bundle. Therefore, currentIndex is the ID of my transaction in a list of transactions and lastIndex is the last ID in the list.
  • SignatureMessageFragment: This field is the text field that can be used for messaging purposes within the transaction. For example, it can contain a json. It is 2,187 characters long.
  • branchTransaction and trunkTransaction: each of them respectively contains the hash of a transaction prior to the current one.

The PoW is considered to be correct if the generated hash ends in as many ‘0’ characters as have been configured as the difficulty in the network, ie the mwm (minimum weight magnitude) value. To homogenize the PoW, a minimum value (14 by default) has been set in all nodes or in all validators.

This ensures that incoming transactions will meet this minimum requireme

As shown in the image above, the value of:

Value B in trits =
 0 -1 -1  0  0  1  0 -1  1  0  0  1  1 -1  1  0  1  0  1  1  1  0  0  0 -1  1  0  0 -1  0  1  1  0 -1  1 -1 -1  1 -1 -1 -1 -1 -1 -1 -1  0 -1  0  0  0
 1  1 -1  1  1 -1  0 -1 -1  0 -1 -1  1  1  0  1 -1  0  0  0 -1  1  0  1  1  1  0  1  1 -1  0 -1  1 -1 -1  1  1 -1 -1  0 -1 -1  1 -1  0 -1 -1  0 -1 -1
-1  0  1  0  1  0  1 -1  1 -1  0  1  0  1  0  1 -1  0 -1  1  0  0  0  1 -1 -1  0  0  0 -1  0  1 -1  1 -1  0  1 -1 -1  0 -1 -1  0  1 -1  0 -1  1 -1  0
-1 -1  0 -1  1  1  1  1  0  1  0 -1  1  1  0 -1 -1 -1  0  0  1  1  1 -1 -1  0  0  0  0 -1  0 -1 -1 -1  1  1  1  1 -1  1  0 -1 -1 -1  1 -1  1 -1  0  1
-1 -1  1 -1  0  0  0  0  1  0  1  0  0  0  0  1  0  1  0  0  1  0 -1  1 -1 -1 -1  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

Note: Its tail end has at least as many zeros as the value of MNW (14 by default)

User A wants to send user B a transaction. To this end, it randomly selects two new transactions using the equilibrium algorithms known as Nash and Montecarlo, which aim to balance the transaction selection load.

In addition, it verifies that the proof of work of those two transactions is correct and matches the value predetermined by the network.

Next, it makes the proof of work of its transaction by signing it and leaving it available so that a user C may include it in another transaction therefrom.

Walkthrough of a transaction


Source

The above diagram shows how a user 5 checks to see, in order to carry out its transaction, whether the PoW of transactions-edges 2-3 is correct and includes them as a trunk/branch in the calculation of its transaction.

User 6 is called a Tip, ie the last user in the chain. User 6 refers to user 5 as a branch and checks whether the latter’s PoW has been properly generated.

To send its transaction, user 6 needs to check the PoW from another user, eg user 4; this user would be the trunk. Bear in mind that two previous transactions – known as trunk and branch – are needed.

Once user 6 has checked this, it will make the PoW of its own transaction, sign the transaction as a whole, including the trunks/branches from previous users, and then send a broadcast to the network saying that there is a transaction available, the cycle thus being repeated.

Another important aspect for making the transaction is the depth of selection of TIPs. This will be defined as the legacy needed to consolidate a transaction. Just as the minWeightMagnitude value is necessary to prevent spam, depth ensures our transaction has a history.

For example, all transactions are indirectly related to the genesis 0.

Transaction 6 is directly related to transaction 5.

Transactions 0, 1 and 2 have been validated, so transaction 6 will also be validated once transactions 3, 4 and 5 are validated. The minimum depth is set to 3, so it is understood that, according to the hierarchical order, my transaction will be validated when my father’s, my grandfather’s and my great grandfather’s transactions are validated.

Explained this way it all seems very strange. To explain things more clearly, let us use the simulator to see how it works:The result over time is that transaction graphs are generated, which look like the ones below:


Example of a transaction. The set of three nodes that take part in the transaction are known as a bundle. A node is linked to another two nodes. Source.

The result over time is that transaction graphs are generated, which look like the ones below:

These pictures are different representations of transactions in IOTA. The set of transactions is called a Tangle. It is different from the block system in blockchain, which is sequential and is represented thusly:


Source

IOTA minimizes some of the drawbacks of the main blockchain networks, such as:

  • The validation time between blocks,
  • single transactions, and
  • the consolidation of the chain stemming from uncle or orphan blocks, which can pose a problem in certain use cases.

Here it is important to remember that there are private networks and semiprivate networks, eg Corda R3, Alastria and HyperLedger, which are capable of processing a high number of transactions while maintaining the features of DLTs and which are currently the networks of reference in projects where the distributed nature of the network provides great added value.

Basic concepts

Before launching into programming a transaction, two elements are needed:

  • Seed: a chain of characteristics of 81 positions that has been randomly generated and is used for generating the addresses and signing the transactions.
  • Address: the wallet where the funds and messages are stored. Below we will see how they are generated.

Both have the ‘9ABCDEFGHIJKLMNOPQRSTUVWXYZ’ alphabet in common and cannot contain any other character.

This chain must be random for each user and can be manually generated using a bash script. For example, in Linux it would look like this:

cat /dev/urandom |tr -dc A-Z9|head -c${1:-81}

‘STKGY9PTOTVOGGQENVQMARJQIDKDSZVHIGZTBOT9BHQHWCZXESAAXA99GZRYGESQLQLSJVGEFPIJFZEYY’

Note: It is important not to share this need with anyone, since it gives access to all funds in the wallet. Never generate a seed from an untrusted web platform or third-party programme.

Once we have a seed, the next step is to generate a wallet in which to store the funds and from which to send transactions and messages.

IOTA’s API uses a deterministic function to generate the wallet, which receives the seed as a parameter. This API essentially calculates the wallet addresses and returns an indexed collection of addresses.

When it is generating addresses, it must also take into account that there are three security levels (1, 2 and 3). A set of fully independent addresses is generated for each security level. The addresses of security level 1 are completely different from the addresses of security level 2 or 3.

In short, a security level indicates how difficult it is to generate a private key from the wallet, ie to reverse engineer it. The predetermined security level is 2.

Therefore, the API uses a seed to generate a sequence of private keys with which it will generate the wallets.


Source

Bear in mind that we are unconsciously used to thinking in binary code: 0 or 1, true or false, etc.

IOTA uses a ternary system (base 3) with the states 0, 1 and -1, and by analogy with the binary code, it uses the trit (trinary digit), instead of the bit, as the minimum unit.

On the other hand, we can use another unit known as tryte, which is made up of three trits (33 = 27). This yields 27 possible combinations.

In addition to, IOTA has its own alphabet, which ranges from A through Z and the character 9.

Let us see one example: Turning text written in ASCII into trites

The value of 1 byte can be represented by 2 trytes. Therefore, we can obtain the decimal value of a character in ASCII.

We can go from a decimal value to 2 trytes by calculating their equivalence (eg 100 is expressed as 19 + 3*27).

Since the tryte alphabet has 27 tryte values:

  1. The first tryte value is the decimal value module 27 (which is the length of the alphabet).
  2. The second value is obtained by subtracting the first value from the decimal value and dividing the result by 27.

The two returned values from Step 2 are inputted as indices in the available tryte alphabet (9ABCDEFGHIJKLMNOPQRSTUVWXYZ) to obtain the correct tryte value.

Let us say we want to convert ASCII character Z.

  • Z has a decimal Unicode value of 90.
  • 90 can be represented as 9 + 3*27
    • To convert it, we must do the following:
      • The first value is 90%27 = 9
      • The second value is (90 – 9)/27 = 3

Thus, our two values are 9 and 3.

In order to obtain the tryte value, we just have to enter them as indices in the tryte alphabet:

  1. The first test value is ‘9ABCDEFGHIJKLMNOPQRSTUVWXYZ’ [9] = I
  2. The second test value is ‘9ABCDEFGHIJKLMNOPQRSTUVWXYZ’ [3] = C

Therefore, ASCII character Z is represented as IC in trytes.

As an example, the function of IOTA’s API that expresses a tryte value in trits is as follows:

TryteString(b'YZJEATEQ9JKLZ')
'Number of Trytes: 13'
[1, -1, 0, -1, 0, 0, 1, 0, 1, -1, -1, 1, 1, 0, 0, -1, 1, -1, -1, -1, 1, -1, 0, -1, 0, 0, 0, 1, 0, 1, -1, 1, 1, 0, 1, 1, -1, 0, 0]
'Number of trits: 39'

Conclusions

To sum up the features of IOTA we have just seen, we can say that IOTA is a permisionless distributed ledger technology that is completely free and secure against quantum computing and whose main use case is the generation of transactions among IoT devices.

IOTA posits an ecosystem of processes to facilitate communication among IoT devices so that there can be a machine economy among them. In other words, that a IoT device may have a digital wallet with which to send and receive value transactions.

In future posts we will provide small examples for getting started in programming in IOTA’s API and Tangle as the support for transactions among IoT devices with and without an economic value.

Happy coding!

Foto de dblanco

Desde ya bien pequeñito empezó mi curiosidad de cómo Donkey Kong era capaz de arrojar barriles por las escaleras en aquella Nintendo Game & Watch de pantallas LCD. Hoy en Paradigma sigo manteniendo la misma curiosidad por la tecnología e ilusión que el día de Reyes del 82.

See all David Blanco activity

Escribe un comentario