“What comes after the blockchain?” Part 1 & 2 by Iteratec

Part 1

07.01.2019 by Nico Heinze

In this blog series we give a deeper insight into the topics IOTA and Hashgraph and the underlying concepts:

Blockchain is currently on everyone’s lips, but in the near past more and more skeptical voices can be heard. An in-depth look at the topic can be found in the blog “How Does Blockchain Work?” .
Known weaknesses of the blockchain such as high energy costs, limited scalability and the limited usability for micropayments to be improved or solved by new consensus mechanisms. Whether and how these two technologies (at IOTA the Tangle) will prevail will show the future.

IOTA – Introduction

IOTA is not based on traditional blockchain technology, but on a new distributed ledger technology, Tangle. With this technology IOTA wants to solve the problems of classic blockchain technology such as transaction fees, high energy consumption for mining, low throughput and the ever increasing size of the chain.

(M) IOTA, or a token / coin, is a cryptocurrency currently ranked 12th in the digital market capitalization universe.

IOTA sees itself as a secure communication and payment medium for the Internet of Things (IoT). It is assumed that distributed ledger technology will play a central role in IoT. The technology offers several advantages over today’s centralized platform solutions. These include immutability, privacy, decentralization and transparency.

Immutability : All participants in a distributed ledger system act as a controller. If data is entered into the system, the participants must come to a consensus. Subsequently, the data is stored independently on all participating nodes. This makes subsequent modification or counterfeiting difficult and requires control of the majority of nodes in the network.

Privacy : All Distributed Ledger technology is based on cryptography. By creating a private key you can participate in the network.

Decentralization : Data reconciliation no longer requires any trusted institutions in the distributed ledger that all participants trust. Today, for example, the classical banks fulfill this role for the settlement of payments between two persons.

Transparency : Distributed-ledger technologies make it possible to share data with many users. It is then possible for everyone to understand exactly which information was provided at what time.

Behind IOTA today is the IOTA Foundation, which was founded in 2017 as a foundation under German law. The founders are Dominik Schiener, David Sønstebø, Sergey lvancheglo and Serguei Popov, who developed the idea behind IOTA and the Tangle architecture.

use cases

For IOTA a multiplicity of application cases is propagated. Which will prevail, or whether IOTA prevails for it, will show the future.

Supply chain security:
Globally distributed suppliers are increasingly struggling with transparency issues. Again and again, counterfeits appear on vendor parts. If every manufacturer in the supply chain saved the current progress at Tangle, everyone involved could review the supply chain at any time. This would allow companies to ensure that a part with the serial number X left the factory at time T1 and was further processed elsewhere by another company at time T2.

Sensor Networks:
If each sensor writes its current measured values ​​into the tangle, they are stored forgery-proof and users can read the current values ​​in real time. Building on this, a pay-per-use model is conceivable: anyone interested could buy the current crypto key of a sensor via IOTA and then read the sensor data.

Instead of administering the patient data in different places as before and transferring them between different doctors error-prone, one could store the patient data encrypted in the Tangle. A physician may, upon authorization by the patient, view the data and add new data to the patient record.


IOTA is based on the so-called Tangle. Tangle is a Directed Acyclic Graph (DAG).

Unlike the blockchain that links all the blocks in a chain, tangle involves a lot of transactions across a directed edge.

Each node in a tangle corresponds to a transaction that can contain any payload. The payload can be for example a transfer, but also sensor data. The edges between the nodes show validation. A new transaction must always confirm two previous transactions. In Figure 2 below, transaction [4] confirms transactions [2] and [1], which is represented by the directed edge.

The two transactions [3] and [4] are not yet validated. Such non-validated transactions are also called “tips”. A transaction can also be validated by other tips over time, resulting in a higher score. The amount of the score increases the likelihood that the transaction will be valid. This is shown in Figure 3, in which Tangle has evolved.

Looking at transaction [3] in Figure 3, it can be seen that they have been validated directly by transactions [6], [7] and [8] and indirectly by transaction [9].

Consensus finding in Tangle

The consensus for a transaction in tangle is reached when all hints indirectly confirm a transaction. That is, all hints reach this transaction via the path. In the following figure 4, the transactions in the green rectangle are validated multiple times and those in the blue rectangle only enough times. The two tips [7] and [8] reach the transaction [1] via a path. Transaction [4] is only achieved by transaction [8].

Within the Tangle you as a user can freely determine the confirmation level. This level is a percentage of how many tips confirm the transaction. This level is determined by the n-time execution of the Monte Carlo Markov Chain (MCMK).
If you get 80 tips in 100 runs, which have a direct route to the transaction, then this transaction is 80% confirmed.


The concept of IOTA envisages Tangle working in a distributed network of IOTA Nodes. There are Light-Nodes, Full-Nodes and Permanodes. The first two already exist, there are currently no permanodes. An overview of the functions of the different nodes can be found in Table 1.

Light nodes are not real nodes in the network. They only use full nodes.
The IOTA Reference Implementation (IRI) runs on full nodes. Each full node must be connected to other full nodes (so-called neighbors) so that it can distribute transactions.


Currently, the IOTA network works exclusively with a so-called coordinator. This is operated by the IOTA Foundation and its source code is also not visible. Its address is permanently programmed in the reference implementation (IRI). The role of the coordinator is to protect the network from attacks. In the Bitcoin Blockchain, for example, with 51% of the computing power one is able to carry out manipulations. Due to the still relatively small number of nodes in the IOTA network, the hurdle for an attacker would be relatively low to create malicious transactions with their own nodes.

The coordinator creates so-called milestones every minute. These are signed transactions and all transactions validated directly or indirectly by this Milestone are considered confirmed. This coordinator is again monitored by the nodes involved in the network and can not create new tokens or reuse existing ones.

With a sufficient size, this coordinator should be removed from the IOTA network. When this will be so concrete is unclear. In November 2018, it was reported that the coordinator should now be phased out.


As described above, the tangle consists of transactions. There are two different transactions:

  • Value transactions (transfer of an IOTA token, the currency) and
  • Zero value transactions (transfer of data)

The process of processing a transaction is always the same.

A transaction in the IOTA network has a defined structure. The individual attributes of the transaction can be found in Table 2.

In case of a transfer of a token (transfer of IOTAs) it is necessary to combine several transactions into one bundle.

Transaction Bundle

A transfer of IOTAs is a bundle of four separate transactions consisting of in and out transactions. However, it is the case that the bundle represents an atomic transaction. This means that all individual transactions must also be confirmed.
IOTA uses a UTXO (Unspent Transaction Output) similar scheme in its platform. UTXO is used for example in Bitcoin.
The bundle structure shows the following table.

In the second part of the blog series we show some implementation examples based on the offered JAVA client library using the IOTA Devnet.

Read the full Article

Part 2

In this blog series we give a deeper insight into the topics IOTA and Hashgraph and the underlying concepts:

  • IOTA – Introduction
  • IOTA – Practical examples
  • Hashgraph – Introduction
  • Hedera Hashgraph – Practical examples

After giving a rough overview on IOTA and the basic technology in the first part of the blog series, in the second part we show some implementation examples based on the offered JAVA client library using the IOTA Devnet .

For a better understanding, we will explain some basic terms in more detail.


A seed is the starting point of everything.

To create an account and addresses a seed is necessary. This seed should consist of at least 81 tries and forms the access key to an account. So you should never give them out of your hands as it is like a purse.

But what are Tryts actually?

IOTA uses the ternary system instead of the binary system (triple system). This leads to its own alphabet, which consists of 27 characters: 26 capital letters (AZ) and the 9.

A trit (trinary digit) can assume three states 3 1 (-1,0,1). Three Trits result in a tryt 3 3= 27, which corresponds to the number of above-mentioned characters in the alphabet. A tryt can be used to represent a character in the alphabet.

For the sake of clarity, in the following example, the word HOLD will be converted to trytes to be written in Tangle.

As a result of the conversion results from the word HOLD RBYBNBVB in Trytes. For the seed consisting of 81 Trytes there are 2781 combinations.

Create a seed

There are several ways to create a seed. The example below shows the creation using the Mac terminal:

cat /dev/urandom |LC_ALL=C tr -dc 'A-Z9' | fold -w 81 | head -n 1

The result is a seed consisting of 81 characters (trytes) (the seed is not fully represented here):


Private key and addresses

A seed is the starting point for generating the private key and the public key that represents the address. The entire process is visualized in Figure 1.

The private key is derived from a sub-seed key index. Based on this key, the address is finally generated. The generation can be done for three different signature security levels. The difference lies in the key length (81 Trytes, 162 Trytes, 243 Trytes).

For security level 2, a hash is derived from the seed and the index. This consists of 2 x 27 segments, each with a 81 Trytes long hash value. (81×27 = 2187 trytes). This results in a key length for the private key of 2 x 2187 = 4374 tries. For the key fragments, in turn, an 81 Tries long hash value is formed from the two blocks of the private key. From these two blocks, a 81 Trytes long hash is again determined, which is the address. For security level 1, only one block is used and for level 3 three blocks are used.

Generating addresses

The method for generating the addresses completely reflects the presented concept for address generation. This is also shown by the corresponding call parameters.

The following method creates new addresses that have not yet been used.

GetNewAddressResponse res = iotaAPIClient.generateNewAddresses(seed, securityLevel, checksum, index, amount);

As a result of the method, we obtain the following addresses, for example for the various security levels (see Table 1). The gray characters form the checksums. When executing the method with checksum = false, the last 9 characters are missing.


Non-value transactions

Based on the described process of a transaction ( see Part 1 ), the transaction is initially generated (transfer data).

Transfer transaction = new Transfer(address, value, message, tag); transfers.add(transaction);

Here, the necessary data of the transaction, such as the address and the message, are recorded. The value remains zero in this case.

The second step is the transfer. The method sendTransferis an extended API call that summarizes the individual steps described in the first part.

SendTransferResponse str = iotaAPIClient.sendTransfer(seed, security, depth, minWeightMagnitude, transfers, inputs, remainderAddress, validateInputs, validateInputAddresses, tips);

Important parameters that need to be filled here are:

All other values ​​can be null or empty. After sending the transaction you get the following response:


In signatureFragmentsthere is the actual message as a tried string. In Devnet Tangle Explorer you can then view the message as text or JSON.

The two transactions validated by our transaction can be found as trunkTransactionand branchTransaction. Devnet Tangle Explorer makes it easy to visualize this relationship. Here is the transaction that validated our transaction.

Value transactions

In a value transaction, IOTAs, called tokens, are now transferred from one owner to another.

The condition is that I create a second seed with an address to make a corresponding transfer. Furthermore, it is necessary to obtain a token. For this purpose, a service is offered that issues appropriate tokens for the devnet.

A token is obtained by entering a generated address on the page https://faucet.devnet.iota.org . The receipt can then be checked again in the Devnet Tangle Explorer. The figure now shows a balance of 1.000i.

A key difference to the non-value transaction is the need to provide the transfer inputs. These are the transactions that have credits to transfer from.

The following example should make the whole thing a little clearer.

We would like to perform a transfer of 1i from person A to person B.



Balance / balance = 2.000i



Balance / Credit = 1.000i

The following methods should be executed in the given order:

1. Define transfer for person A transfers person B 2i

Transfer transaction = new Transfer(address, value, message, tag); transfers.add(transaction);

For addressis the recipient address, so the address is person B and that valueis 2 The entries for messagetagyou can set arbitrarily.

2. Now you have to determine the credit of Person A, from which “debited” should be.

GetBalancesAndFormatResponse res = iotaAPIClient.getInputs(seed, security, 0, 1, 1);inputs= res.getInputs();

For this, the seedperson A’s must be used. It searches for all addresses of the corresponding security level. The result is then passed as inputsin the sendTransfermethod.

3. Trigger transfer

SendTransferResponse str = iotaAPIClient.sendTransfer(seed, security, depth, minWeightMagnitude, transfers, inputs, remainderAddress, validateInputs, validateInputAddresses, tips);

After the transfer has been executed, the response contains a bundle of transactions that were necessary to complete the transfer.

In Tangle Explorer you can find the bundle via BundleID.


Figure 5 now shows both the input and output transactions.

From here you can then look at the individual transactions of the bundle in more detail. The first transaction (index 0) shows that person B has received 2i. The address of the “recipient address” of person B is entered here.

Now, if person B looks at the transactions for his address, she sees that the balance is now 1002i.

The three further transactions relate to the address of person A and are found there again. Here we see in the first entry the remote “old” credit and in the third line the “new” credit. Line two is the transaction with the second part of the signature.

In the third of the blog series we are dedicated to the distributed ledger technology hashgraph.

Read the full article

You might also like

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. AcceptRead More