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:

[code light="true"]
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
[/code]

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

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:

% block:caption
% image:https://www.paradigmadigital.com/wp-content/uploads/2019/03/IOTA-4.png
% caption: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.

% endblock

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:

% block:caption
% image:https://www.paradigmadigital.com/wp-content/uploads/2019/03/IOTA-10.png
% caption:Source

% endblock

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:

[code light="true"]
cat /dev/urandom |tr -dc A-Z9|head -c${1:-81}

‘STKGY9PTOTVOGGQENVQMARJQIDKDSZVHIGZTBOT9BHQHWCZXESAAXA99GZRYGESQLQLSJVGEFPIJFZEYY’
[/code]

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.

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:

[code light="true"]
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'
[/code]

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!