IOTA Research Status Update September 2021

We are pleased to share the following update from our research groups. The department remains focused on improving the IOTA 2.0 protocol implementation on the DevNet.

This month, our update introduces two new groups: the Consensus Group and the Communication Layer Group. The Consensus Group was formed to address the message propagation delay issue outlined in our July monthly update. Work on simulation and testing of our improved consensus mechanism has yielded good results so far. The Communication Layer Group, as the name suggests, works on various aspects of communication in the IOTA 2.0 protocol. This includes topics such as verification of network performance, optimizations, and timestamps. As always, please read below for all of the details.

DevNet Implementation. Since the last update, the team has released v0.7.4 and v0.7.5, which improve the overall stability of the software, fix several bugs and move the scheduler component towards the end of the data flow. This allows for a better synchronization process as well as simplification of the overall flow. There are still some issues related to the marker assignment that make it difficult for some new joiners to successfully sync their nodes. For this reason, the team is working on a new feature that will allow the community nodes to download a recent database in order to sync up faster and more reliably.

The implementation of the new improvements to the consensus is progressing at a very fast pace, as the team is already in the testing phase. More specifically, a modular consensus interface, the On Tangle Voting (OTV) mechanism, a new parent type (i.e., the Like switch), and a refactored message syntactical validation have been already added to the codebase but not merged yet. The amount of approval weight built on each message can now be translated into grades of finality (GoF): low, medium, and high. The collection of new metrics specifically designed to analyze OTV have also been added and a new conflicts summary page has been developed for the node’s local dashboard so that each node operator can check in real-time the behavior of her/his node while voting on conflicts.

Other components of the protocol, including the rate setter, the core component of the congestion control, have been integrated into the flow. Finally, a considerable amount of effort is being directed towards code quality improvement. Use of dependency injection in plugin initialization, unification of the parameters, a more generic serialization, and deserialization library are just some examples.

The official documentation has been migrated to docusaurus and you can check that here.

Networking. The current focus of the team is analyzing the performance of the IOTA congestion control algorithm (ICCA) and on the improvements of the user experience. More specifically, ICCA has been designed with the objective of minimizing the maximum delay, which is the time needed to deliver a message to all nodes. This means that the thresholds used by ICCA (blacklisting, self back-off, and minimum mana) act as a regulator of such a maximum delay. To get the intuition behind this, think of a buffer with infinite size, where delays could potentially be infinite; if the same buffer has a small size, a new message only has to wait until all the existing (few) messages are scheduled. For this reason, we are working on the analysis of the various parameters to figure out how they affect the actual performance of ICCA, and how these parameters can be optimized. As a preliminary result, we have found that the way the deficit is assigned and capped has a strong impact on the performance.

In parallel, we are working on load balancing among nodes trying to answer the following question: assume that a user (wallet or node) has a new message to issue, what node should be chosen so that this message is created in a short time? Remember that each node has a message creator module and the rate of addition of new messages into the scheduler is regulated by the rate setter algorithm; hence, this project tries to assign new messages to nodes that are less busy at a given point in time. We formulated this problem as an optimization problem and we are testing a few proposed policies based on message creator occupancy or delay per node.

In the context of verifiable delay functions (VDFs), we are optimizing the computation and evaluation time of our proposed algorithm for spam prevention by using multi-exponentiation techniques which we have previously studied. We found that one of the most expensive (in terms of time) aspects of the verification of the VDF is finding the minimum number so that the hash of this number plus an input message is prime. We are currently focusing on speeding up this function.

Sharding. The past weeks saw several different focuses for the Data Sharding Group: Mainly discussions about ISCP Chains and motivation on data sharding, simulations regarding the model and formalising our findings, definitions and discussions.

Two different simulations were done by members of the Data Sharding Group. The first one was a user-based model, where we considered different users with different MPS (messages per second) requirements joining the network and optimally allocating themselves. From this model, we checked interesting data such as allocation of mana per shard, expected MPS per mana share, and MPS per layer. The second model is a shard-based model, where we mainly focused on the overhead caused by communication between the shards. Both simulations gave us results that were either expected or positive. The results will be formalised and contribute to our ongoing work.

Consensus. The Consensus Group is newly formed to tackle all things related to consensus changes. As such, it is an interdisciplinary group that currently mainly focuses on implementation and testing of the modular consensus changes and Like switch, simulation of OTV, writing a paper on OTV, and discussing further ideas to simplify and enhance the protocol.

Based on the multiverse simulator, the team is building a general simulation framework that will help us gain an in-depth understanding of the consensus mechanism, its perks, and limitations. It will also serve as a battleground for various attacks on pure OTV and OTV with FPCS as a metastability breaking mechanism and potentially others. Currently, the simulation framework is in a very early state and no meaningful results can be obtained. In the near future the framework will help us to make informed decisions on parameter settings (e.g., when should FPCS be turned on?), get a feel for confirmation times with different mana distributions and statement rates, and provide content for our papers on OTV.

The team is also discussing further simplifications of the protocol. For example, with the like switch, we now have a clear separation between approval weight (AW) for branches and markers. By using a single marker sequence to approximate AW, we can separate these components, speed up AW computation and make things easier to understand. Furthermore, we are discussing the notion of active cMana (cMana that is taken into account for current conflicts/messages) and the termination of consensus since following the heaviest branch is a never-ending voting scheme, just like the longest chain rule in blockchains.

Communication Layer. The Communication Layer Group is another newly formed team. Its focus is on communication and synchronization topics which came up during the research in the Networking as well as in the GoShimmer Group.

This month, the team performed tests and benchmarks for the scheduler and rate setter components recently added to the DevNet. Here, various virtual network configurations were set up to verify that the existing implementation matches the expected results from the networking research. Another aspect of these tests was to identify potential performance bottlenecks in certain edge case scenarios.

On a more theoretical level, we have been evaluating different timestamping methods. Timestamps allow for direct comparison and ordering of messages, which is helpful for a variety of components. These different methods need to be evaluated concerning their precision, reliability, and computational complexity.

We hope that you 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 hello, 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.