IOTA Research Status Update

We are happy to share the following updates from several of our groups. It has been a busy month for everyone on the team. In addition to the work described below, we’ve also been busy planning our next ReSum meeting, to be held later this month.

We invite all the community to join the AMA with the IF Team happening next Wednesday (October 14th) at 1PM CEST | 7AM EST on Reddit. We will be answering your questions about Coordicide.

Without further ado, here are the updates!

Pollen Testnet Implementation.This month the team has been focused on cleaning up the entire GoShimmer codebase. We are taking a similar approach to the Hornet team by flattening the packages structure. This will be beneficial for the development progress and increase consistency between the two projects. We have added a new section on our wiki to describe our approach to error handling.

After finishing writing the mana spec implementation, the team started implementing it. We have focused on the base mana functionality such as mana calculations, metrics collection, and an initial integration with the new transaction layout and wallet. We have added new APIs to enable both retrieving mana related information — such as raw values for both access and consensus mana per node, percentile and highest values — and specifying the ID of the node when pledging mana while issuing a value transaction.

Given the importance of mana in our Coordicide solution, we have started building some visualization tools embedded in the node’s local dashboard to better show how it works as well as a set of monitoring tools to study its dynamics. You can see a glimpse of this work in the pictures below.

In addition, this month we have worked on two new RFCs, still in draft version, which address how to reach consensus on timestamps and how to optimize conflict resolution via writing FPC opinions into the Tangle. You can check those out here and here.

From a Continuous Integration/Continuous Deployment (CI/CD) point of view, we have integrated the use of Snykin our pipeline. Its integration has already helped uncover some security issues within the JWT library we currently use to protect the access to the APIs. This tool will help us keep our code more secure throughout its development.

The dRNG experiment, which started last month with the community-driven GoShimmer X-Team, has been fully successful! The community managed to create a distributed committee of 7 members and collectively produce fresh randomness every 10 seconds, with no interruption, for more than 2 weeks already. You can see below a screenshot of some of the randomness shown in the GoShimmer local dashboard:

We are constantly monitoring the performance of our dRNG solution based on the drand project. Within the last 2 weeks, the distributed committee has been able to run a threshold-based signature scheme (4-out-of-7) and exchange the respective contributions to produce new randomness under 300ms on average, as you can see from this plot.

As for the next steps, we will very soon release a new Pollen testnet version v0.3.0 with the community-driven dRNG as the default one.

Pollen Testnet Study Group.As the implementation of the Pollen testnet advances and it incorporates more and more of the Coordicide modules, it is time to analyze the testnet properly. For us researchers these are exciting times!

Coordicide involves many modules that we developed and studiedon paperand validated through simulation studies as stand-alone modules. The time has come to see all these different modules interlock and come to life as a whole.

The dashboard in Pollen already offers an excellent overview of various components and their performance in Pollen. While this information delivers many good indicators about the proper functioning of the testnet, the final aim of this group is to obtain scientifically sound evidence for the claims of Coordicide. We look forward to sharing more results on this endeavor soon!

Protocol.This month the protocol group continued its work wrapping up the few final remaining theoretical questions about IOTA 2.0. One of the main topics we discussed was synchronization between nodes and tools that the node could use to detect if it is out of synchrony. Aside from this, we further developed the specifications about bootstrapping and deepened our discussions about tip selection game-theoretical behavior. Although the URTSA (Uniform Random Tip Selection Algorithm) works very well, IOTA’s philosophy of freedom means it is non-enforceable, and thus it is ultimately up to the node operator to choose which one to use. The research on TSAs has to make sure the TSA is the best option for a node to use under standard assumptions.

Next month we plan to finish the mathematical investigation of TSA, and incorporate our conclusions into the relevant specifications.

Networking.We are focusing our efforts on an extensive attack analysis on the congestion control algorithm. Specifically, we have proved through simulations that attackers cannot affect either fairness (the requirement that a node sends messages proportional to its mana) or the efficient utilization of nodes’ available communication and processing resources. We are currently investigating more elaborate attacks where malicious nodes issue different streams of messages to different neighbors trying to affect consistency. Preliminary results show that appropriate message drop policies and blacklisting are effective countermeasures.

We are happy to communicate that our research paper “Healthor: Protecting the Weak in Heterogeneous DLTs with Health-aware Flow Control” has been accepted for publication at the 4th Workshop on Scalable and Resilient Infrastructures for Distributed Ledgers (SERIAL 2020). The work shows how it is possible to adapt our congestion control algorithm in case of intermittent connectivity through feedback from neighboring nodes.

Additionally, we are designing a distributed random number generator (dRNG) based on verifiable delay functions which can be used as a second source of randomness (the first source of randomness in Coordicide comes from a dRNG based on threshold cryptography).

Sharding

As many of our community members are aware by now, we have been looking closely at our sharding approach, which we call Fluid Sharding. Our goal for fluid sharding is to build the most scalable base layer DLT that one could possibly build. Suffice it to say, this is no small task, although we are very confident in our team’s ability to deliver! A high-level view of this approach can be foundhere.

As we began to engage with this topic more formally, we undertook an extensive literature review of existing approaches and solutions to make sure our team is up to date with all the latest research on sharding. Our aim was to investigate current research to also improve the security of our own solution.

Our readers are likely familiar with the notion of first layer and second layer scaling solutions, and we are looking at incorporating both of these approaches to scalability in IOTA. Fluid sharding refers to our layer one scaling solution. We are also looking closely at what we refer to as “data sharding” as a type of second layer solution.

Our talks with various IOTA stakeholders have been fruitful in understanding that data sharding does indeed serve many needs of normal users and corporate adopters alike. We believe that ultimately both solutions will be developed, and together, they will comprise what might be described as a “fully sharded” IOTA 3.0.

Thanks for reading, and 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.