Like many others in the data-driven innovation arena, you may have started to grasp the value of decentralization already. 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 only on one organization.
You are looking to build a DLT- or blockchain-based solution. And you are thinking of using the IOTA protocol.
The IOTA Foundation (IF) can support you to achieve your goal. We build solutions and we can consult you 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 and allow them to replicate, adopt and scale the IOTA protocol into new IOTA-powered solutions.
First things first: Why IOTA is good for you?
Before looking at how to integrate the IOTA protocol, it is good to understand the reasons why IOTA is good for your purpose.
Why a DLT?
We assume that you already asked yourself and answered this key question: Do I need a DLT (or a blockchain)? Assuming the answer was yes, you surely asked yourself this second question: why should I use IOTA?
Let’s try to understand together why IOTA is a suitable technology for your needs.
To help you with that, we consolidated 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 this situation: “My solution requires sharing data across a multi-stakeholders ecosystem, where the parties do not trust each other, or do not want to trust a central sharepoint for data sharing”. If this is the case, it sounds like you DO need DLT.
However, there are so many DLT’s nowadays and it is hard to determine the correct one to use. So, let’s try to understand why IOTA should be your choice.
Let’s do this by considering the following example.
A city council wants to promote electric vehicles (EVs)-based transport. 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 in order to provide the power required for charging cars. This will maximise 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). The payment should also happen ‘peer-to-peer’, so directly from the car to the specific charging station operator without the need of a middle man.
It is clear that because there are different charging stations providers and drivers, it will be a big competitive disadvantage to share all this data into a central sharepoint 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 IoT data, such as a car’s current battery status, are shared but a mix of them and other data, such as power tariffs, charging stations schedule and so on might be required. The latter non IoT data are usually more structured and only occasionally shared when an update is needed. Contrary 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 data is 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 consensus and 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 fast, thus 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 cheap or free to use infrastructure to share immutable data irrespective from the amount of shared data? This is often a desirable property in a new solution design, as it removes the barriers for adoption and does not impose any extra fee on the 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 for storing data using an Ethereum smart contract users need to own crypto tokens first, then they can use the infrastructure by paying to run a smart contract. 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 crypto currency related aspects, which are inevitably tied to it.
But if you are looking for an infrastructure which costs are fixed, then the choice is simple. Differently from many blockchains and DLTs, IOTA utilizes feeless microtransaction. This makes it possible to issue 0-value transactions, used solely for sharing immutable data. Thanks to its feeless transactions, your IOTA solution provides a far better economic scalability. This is not possible with other ledgers, where each transaction has to incur in 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 questions above is yes, it is recommended that you build your solution using IOTA.
IOTA is my choice: what’s next?
Now that you understand why IOTA is your go-to choice, it is good to identify a few design principles that should 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 if you are ready to deploy your solution in the production ready IOTA mainnet, taking advantage of its permissionless nature, or rather you need to test it first in an experimental permissioned Private Tangle setup. A private Tangle is a permissioned private IOTA network that can be used to explore the technology, test applications or showcase IOTA’s technology offline.
To understand this, start asking yourself: Does the solution require to process payments with real 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 cars 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.
In our charging scenario, you definitely need to use the IOTA mainnet. IOTA value tokens only exist in such a 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 understand the use of private Tangles in production scenarios you should 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 or 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 mainnet permissionless ledger 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 again 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 authorised parties (i.e., a consortium) can write information on the ledger. In this case it is also likely the case 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 IRI node and decide who can connect and send transactions to it.
A Private Tangle is also preferred when the different parties want to share regulated data. Some of this data might need to remain confined in a specific geographic area. In the example above, this is the case for the EV data. Car 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 allows 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.
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.
IOTA building blocks: which one to use?
Once you have decided 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 this question: can any party read all the information? If yes, your solution architecture does not require additional IOTA building blocks. But if the answer is no, the use of 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 authorised nearby charging stations but not by anybody else. MAM channels allow to implement 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 ten 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 customise your solution architecture by considering a few options:
- 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.
- 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 IPFS.
We have so far understood when IOTA is the right choice for you and what building- and application infrastructure blocks (MAM, chronicle nodes, etc) your solution should include.
In the future we will release another blogpost where we will dive into PoC’s, applications and how the IOTA Foundation can support you in the development of your IOTA-powered solutions and services.