Like many others in the data-driven innovation arena, you may already have begun to grasp the value of decentralization.

You know that data shouldn’t remain trapped in silos, with the custodians of these silos being the only ones responsible (and liable) for the data’s integrity and its correct use.  

You know that data generates more value when it is shared and when trusting its integrity does not have to depend on one organization only.  

You are looking to build a solution based on either a distributed ledger technology (DLT) or blockchain. And you are thinking of using the IOTA protocol.  

The IOTA Foundation can support you to achieve your goal. We build solutions and we can provide consultation on how to best use and integrate IOTA technology or develop new enabling components and interfaces using our blueprints. We organize workshops and we can help educate an emerging class of IOTA developers to replicate, adapt and scale the IOTA protocol into new IOTA-powered solutions.  

Before looking at how to integrate the IOTA protocol, it is important to understand the reasons why IOTA is fit for your purpose.  

Why DLT?  

We assume that you have already asked – and answered – this key question: Do I need a DLT or a blockchain? Assuming the answer is yes, you surely asked yourself a follow-up question: why should I use IOTA?  

Let’s explore together why IOTA is a suitable technology for your needs.  

To help you with that, we have created a simple model that allows you to identify the unique IOTA features to be leveraged for your solution.

Building on the first two questions derived from a previous model, our model focuses on IOTA-specific questions and features.  

If you are considering this model, you might be in the following situation:  

“My solution requires sharing data across a multi-stakeholder ecosystem, where the parties do not trust each other or do not want to trust a central storage for data sharing.” If this is the case, it sounds like you DO need a DLT.  

Why IOTA?

There are so many DLTs nowadays, it is hard to determine the correct one to use. So let’s try to understand why IOTA should be your choice.  

We can do this by considering the following example:  

A city council wants to promote transport based on electric vehicles (EVs). To incentivize citizens to use EVs, the city council wants to provide a platform for exchanging information on the availability of power from connected EVs and charging stations. With such information, AI agents can perform optimal allocation of charging stations to cars. This will maximize global efficiency, reduce delay and balance grid load. Charging stations can be installed and offered by different service providers. To reduce the compliance burden, the platform should allow payments for power to be processed on power usage (pay-as-you-use). To allow market flexibility, payments should also happen ‘peer-to-peer’, so directly from the car to the specific charging station operator, without the need of a middle man.  

Because there are different charging stations, providers and drivers, it is clear that it will be a big competitive disadvantage to share all this data into a central storage, and no party would agree to do so. So a DLT is required. But why IOTA?  

The first question to answer is: are the parties required to share a mix of Internet of Things (IoT) and non-IoT data? In the example above, not only is IoT data (such as the car’s current battery status) shared, but a mix, including power tariffs, charging stations schedule and other event notifications. The non-IoT data is usually more structured and only occasionally shared when an update is needed. Instead, IoT data such as battery status is usually more frequent small time-series data points.  

IOTA transactions support any kind of payload

IOTA’s flexible transaction payload can support any type of data. Financial transactions are obviously also supported by other ledgers too, but where IOTA excels is in being a trusted data layer for connected devices. Due to its lightweight transaction protocol, any device can issue IOTA transactions.

However, sharing data and guaranteeing data integrity among untrusted parties through a DLT often comes at a cost. Most of the time this depends on the quantity of information shared. In the example above, the information shared for each transaction might not be much. However, the number of involved parties and transactions might grow very quickly, resulting in a large quantity of information being secured through a ledger.  

Sending IOTA transactions does not require fees

Hence, the aspect of economic advantage must be considered: do the parties benefit from a low-cost or free-to-use infrastructure to share immutable data, irrespective of the amount of shared data? This is often a desirable property when designing a new solution as it removes barriers to adoption and does not impose any extra fees on future solution users in order to cover the infrastructure costs. Most of the existing blockchains and DLTs, where users have to pay fees to issue transactions, not only limit future business models but add an economic disadvantage. For example, to share data using Ethereum, users need to own crypto tokens first before they can use the infrastructure to send data transactions. Together with the decision to utilize a DLT with transaction fees, additional legal, financial and regulatory considerations have to be made on how to manage the cryptocurrency-related aspects, which are inevitably tied to it.  

Unlike many blockchains and DLTs, IOTA utilizes feeless transactions. This makes it possible to issue zero-value transactions, used solely for sharing immutable data. Thanks to its feeless model, your IOTA solution provides a far better economic scalability. This is not possible with other ledgers, where each transaction has to incur a fixed or variable fee, varying with the variation price of the associated token.  

If you got this far and the answer to all the above questions is yes, it is likely that IOTA is the right choice for you to build your solution.  

Now that you understand why IOTA is your go-to choice, it could be helpful to identify a few design principles that allow you to understand the different building blocks of the IOTA technology stack that you might want to use.

Production or experimentation environment?

First, it is good to understand whether you are ready to deploy your solution on the IOTA mainnet, utilizing its permissionless nature, or whether you need to test it first in an experimental permissioned private Tangle setup. A private Tangle is a permissioned private IOTA network that is fully under your control and can be used to explore, test applications or showcase IOTA’s technology offline.  

To understand this, ask yourself: Does the solution require processing payments with IOTA tokens? With reference to the example above, this might be the case when a car pays directly to a charging station that provides the power required for the car's battery. With IOTA, any connected device can have an address and manage an IOTA wallet for unified identity management and to send and receive (micro-)payments. As a result, the problems associated to exchange fees when using other currencies can be avoided.  

In this case, you definitely need to use the IOTA mainnet. IOTA value tokens only exist in this network, which thanks to its nature, allows these tokens to be spent anywhere.

If you do not need IOTA value tokens, then you could also consider deploying your own private Tangle.  

Permissionless or permissioned environment?

To better understand the use of private Tangles in production scenarios, consider the following: Will any unknown/untrusted parties need to write data to the ledger? For example, this happens when the city council wants to deploy an open infrastructure without knowing in advance if new charging stations will be deployed in the far future and who would own them.  

If the answer to the above is yes (unknown parties might join later), the permissionless IOTA ledger should be used. IOTA’s permissionless mainnet is an infrastructure as a service and you can connect to it by simply connecting to an IRI node and start publishing transactions, using our client libraries.  

But if the answer to the above question is no, then a private Tangle might be more suitable. This can be the case when the city council wants to form a closed consortium and select and vet all the providers and certify their charging stations, before allowing them to advertise services on the provided infrastructure.  

The reason for using a private Tangle in a production-ready environment is when only authorized parties (i.e., a consortium) read and write information on the ledger. In this case, it is also likely that each party wants to maintain a copy of the ledger and knows who the other parties accessing the ledger are.  

In the example above, each charging provider will run an IOTA reference implementation (IRI) node and thus maintain a copy of the ledger state, as well as an access point through which his own charging stations connect to the network.  

A private Tangle is also preferred when the different parties need to share regulated data. Some of this data might need to remain confined to a specific geographic area. In the example above, car and driver data might be subject to different regulations, depending on the different countries where the infrastructure is deployed or the nationality of their drivers.  

In this case, a private Tangle would allow the infrastructure providers (i.e., the consortium members) to control where the data is replicated and avoid that data is spread on various nodes across the world.  

However, in the example above, a desirable scenario would be the city council aims for fair competition between providers. Car owners and tourists can join anytime and charge their cars without going through a registration process. No regulated data is shared. The IOTA Token is used as an integrated payment part so that IOTA provides the underlying trust for all data transactions, as well as the monetary payments without a break in security. In this case, IOTA’s mainnet is the optimal choice to ensure all of that.  

The figure below recaps the different criteria to decide between mainnet and a private Tangle.

Our Developer Handbook provides you a good starting point to understand why and how to use the different available IOTA networks.  

Once you have decided on your IOTA network, the next step is to understand what other building blocks of the IOTA stack you need to integrate.

Consider restricting access to certain data

So far, we have considered who should write into the ledger. One additional point to consider is who should be reading this information. Start by asking yourself: can any party read all the information? If the answer is yes, your solution architecture does not require additional IOTA building blocks. But if the answer is no, the use of Masked Authenticated Messaging (MAM) channels should be included in your architecture. In the example above, for instance, you might want that battery data from a given car should only be accessible by authorized charging stations nearby but not by anybody else. MAM channels allow the implementation of granular access control to the data shared on the Tangle. Without the information about the location (root) of the channel or the key to decrypt it, any information in a MAM channel stays private.  

Does data need to be stored permanently?

One final design principle to consider is: do the parties need to store data permanently? This is the case when regulation requires a given retention time for the collected data. In the scenario above, this could also be the case when payment data from the charging stations needs to be kept for 10 years due to financial regulations.  

If the answer is no, you don’t need to store data permanently, you can always use the permissionless IOTA network as a public layer of trust to share data and (micro)payments securely and in real/near-time.

However, if the answer is yes, you need to permanently store transaction data, then you might need to customize your solution architecture by considering a few options:

  1. Deploy your own node, configure it for long-term transactions storage (by disabling snapshots and following these best practices) and connect it to the IOTA permissionless mainnet. This way, your node will maintain all your transactions and you will be able to create a public reference to prove the immutability of a transaction. Remember that searching historic information lacks efficiency on a public DLT, as no content is indexed. You can always retrace your transactions from your seed  but would need to optimize the performance by storing your transactions references also locally, where you can deploy your own tagging or indexing.
  2. Deploy one or more chronicle nodes, the IOTA permanode solution with efficient information search, redundant storage and resilience to protocol updates. By installing multiple nodes every party will retain a complete history of transactions across protocol updates.

For more ideas on how to manage permanent and trusted file storage, we recommend looking into this blueprint on how to integrate IOTA and InterPlanetary File System (IPFS).  

We have so far understood when IOTA is the right choice for you and which building- and application infrastructure blocks (MAM, chronicle nodes, etc) your solution should include.

In the future, another blog post will dive into PoCs, applications and how the IOTA Foundation can support you in the development of your IOTA-powered solutions and services.  

In the meantime, if you have any questions, don’t hesitate to get in touch with our team through our Discord server or [email protected].

Follow us on our official channels for the latest updates:
Discord | Twitter | LinkedIn | Instagram | YouTube |

Tags

Michele Nati

Head of Telco & Infrastructure Development @IOTA Foundation, PhD in Computer Science, Data and Digital trust expert, Internet of Things researcher. Leader for IF engagement with TMForum. Runner.

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.