IOTA Research Status Update July 2021

Following the excitement of the DevNet release at the beginning of June, our team has somewhat returned to our normal cadence, with work continuing on finalizing specifications, continuing to optimize certain aspects of the protocol such as the congestion control algorithm, and picking up our work on Data Sharding.

One thing that is different, however, is that we have the benefit of data gathered from the DevNet to inform our work. We hope the following updates are informative for you, as we explain exactly how that data is being used, and what the next steps will be for the IOTA Research Department.

DevNet Implementation. We are gathering precious data from most of the nodes on the DevNet. With that data, we have been able to discover some bugs in our network stack causing some messages to be propagated through the network with higher than expected delays.

Independently from having fixed this issue with v0.7.3, this problem highlighted a drawback regarding FCoB, the protocol by which nodes set their initial opinion of each transaction. More specifically, due to the current implementation of FCoB and FPC, it can happen that two (or more) conflicts can both be rejected. Without a clear winner, new nodes joining the network, or existing nodes that are solidifying missing messages, might only get one such message and thus try to attach their new messages on a side of the Tangle that will not get enough approval weight to be ever confirmed.

Although we could improve FCoB by adding communication redundancy for the rejected conflicts, we would like to take this opportunity to study a variant of FPC dubbed “FPC on a set”, that would always pick a winner within a conflict set. This would also allow us to start experimenting with a mechanism more similar to On Tangle Voting (OTV) combined with FPC on a set as its metastability breaker.

Other aspects of the implementation are also being improved. For instance, we are moving the scheduler (the core of the congestion control) after the booker. This results in a more natural behavior while syncing, as the node does not need to explicitly bypass the scheduler to catch up with the network.

Moreover, the team is re-working the solidification mechanism such that a message is considered solid if its parents, as well as its payload (i.e., its transaction), is solid. This will allow us to remove the expensive past-cone check.

Protocol Update. With the DevNet implementation came the first wave of feedback regarding the many components that will make up our IOTA 2.0 network. While most of the components showed promising results, we also realized that some of them would require changes in order to be up to the standards we expect from the future network. Luckily, the modular nature of IOTA 2.0 makes it possible for us to develop components we are satisfied with while at the same time we research and improve the ones that require attention.

The whole research department got together to determine which components could benefit from further research and decide how we will organize this in a way that will not hinder the other projects going on. The main improvements we will be working on are:

• Increase modularity of the consensus algorithm by introducing the “Conflict Selection Function,” which generalizes all consensus mechanisms that may be implemented in IOTA 2.0. Updating FPC to the “On Tangle FPC on a set” by using the conflict selection functions.
• Remove the need to vote on timestamps and classify messages as eligible for tip selection by introducing the “Inclusion Score” mechanism.
• Remove the need for weak approvals and study how the protocol behaves under conflict spamming.

After defining these research topics, we divided ourselves into two groups to tackle them. The main focus of this research is to come to results that can be included in the specifications. We hope to have some results to share by the next research update.

Specifications. After extensive work to get the first batch of specifications ready to be shared with the community, the team took a survey of our current research to decide on the next objectives. In order to appropriately do this, the recent launch of the DevNet was crucial. The new tasks that were decided were: update the specifications according to the recent results from the DevNet; proceed with the standardization process for the files that will not be affected by the DevNet results; and work on the second batch of specifications in order to have all files written.

Since the main focus of the research department in the next couple months will be on research, the specifications work will naturally follow. As research is completed, we will add the relevant results into the specifications.

Networking. The research in the networking team is currently focused on the implementation of the congestion control algorithm in the DevNet and its integration with the rest of the protocol.

As a result, we are studying a set of optimizations that allows us to simplify the code while improving performance. The most important change compared to the original idea is the fact that messages can be booked immediately after they are solid, hence the scheduler only determines which messages are gossiped and added to the tip list. This permits a much faster synchronization for out-of-sync nodes, which can recover old messages at a rate faster than the scheduler rate. On the other hand, moving the scheduler to the end of the data flow opens the possibility of attacks, which are currently being studied. We can mitigate potential attacks by the introduction of the inclusion score, a metric measuring the likelihood of a message becoming a permanent part of the Tangle in the future.

As a second research topic, we are currently investigating a model to improve the users' quality of experience. In particular, the rate setter determines the throughput of a given user, depending on access mana. Questions like “How many messages can I as a node send with X mana?” or “When am I allowed to issue the next message?” will be answered by this model.

Finally, we are proud to announce that our paper, written in collaboration with Professor Bob Shorten and his team at Imperial College London, “Access Control for Distributed Ledgers in the Internet of Things: A Networking Approach,” has been accepted for publication at IEEE Internet of Things Journal (Impact Factor 9.936), a top-ranked journal in computer science.

Sharding. During the last two months, the entire research department was focused on two things: DevNet development and the release of the specifications. Therefore the sharding group entered, together with some other groups, a hiatus to allow our workforce to be properly allocated to those tasks. With the release of the DevNet and the first specifications completed, the research department is back working on its sharding solutions. The first proposal, a whitepaper on Data Sharding, is in production right now, and we expect a release soon to share our ideas with the community.

We expect the development of the Data Sharding to significantly improve the throughput of the network for data messages, and its implementation can be parallelized with the future Fluid Sharding.

We hope our readers find these updates informative and useful for following along with the department’s progress. If you have any questions or would just like to say hi, you can find our Research team members in the #tanglemath channel on our Discord. You are also welcome to follow and participate in our technical discussions on our public forum: IOTA.cafe.