Getting started: the road to integration Part 1
The full article was originally published by Michele Nati, PhD on Medium. Read the full article here.
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.
The IOTA Foundation (IF) 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, adopt and scale the IOTA protocol into new IOTA-powered solutions.
First things first: Why is IOTA 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-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.
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. 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.
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 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 IoT data, such as a car’s current battery status, are 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 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 low-cost or free to use infrastructure to share immutable data, irrespective from the amount of shared data? This is often a desirable property when designing a new solution, 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 sharing data using Ethereum users need to own crypto tokens first, then 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 possible to issue 0-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 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 likely that IOTA is your choice to build your solution.
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 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 on the IOTA mainnet, utilizing 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 is fully under your control and can be used to explore, test applications or showcase IOTA’s technology offline.
To understand this, start asking yourself: Does the solution require to process 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 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 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 IRI node and thus maintains 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 in 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 aiming for a 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 being shared. The IOTA Token is being 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.
IOTA building blocks: which one to use?
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 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 authorized nearby charging stations but not by anybody else. MAM channels allow implementing 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 customize 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 which building- and application infrastructure blocks (MAM, chronicle nodes, etc) your solution should include.
In the future, we will release another blog post 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.