IOTA Research Status Update

January 2020

The start of a new year is a moment to reflect on the past and look to the future ahead of us. It is the moment when we assess our challenges and opportunities and continue to chart a path forward. In this second installment of our monthly Research Status Update, we provide further information about the progress made on components listed in our last update. We’re very excited for 2020!

In December we had another research summit, this time in Berlin, where the teams could connect, share their results and discuss next steps on the Coordicide project. Although some specifications remain to be written, the current overall status of the project is that we have obtained satisfactory answers to all questions necessary in order to complete a “Version 1” Coordicide. From this base of progress, we would like to answer a few questions that surely many people are asking:

How far are we from the prototype? Not very far! We have been gradually implementing the elements of Coordicide into the prototype. There are two components that still need to be coded before GoShimmer can be considered a “complete” prototype. These are the Random Number Generator (RNG) and mana (see below for status updates on these).
What has been left for later? It should come as no surprise to anyone that the IOTA protocol is not an “end-product,” rather, it is an ever-evolving project. The first version of Coordicide will be aimed at IoP (Internet of People), and from there we will improve the necessary parts in order to answer the needs of IoT. The essential questions for Coordicide have been answered, and Coordicide “v.1” is coming! Remaining research questions include: Cellular Automata voting, the sharding mechanism (which we refer to as “slicing”), Arrow autopeering and VDFs. Although our past research has already yielded great progress on those topics, they are not essential to the initial Coordicide. As such, our immediate focus is to deliver a working version of Coordicide in order to fully decentralize the IOTA network. After this has been achieved, we will then turn our full attention to the next steps in the direction of IoT.
What is next? In the post-holiday season, our research groups are coming back at full power to finish up our prototype work, and finalize both the “research” and engineering specifications. Our existing research provides a suitable basis for writing proper specifications for many of the outstanding components. Some of the post-Coordicide topics do still need further research. Looking at the current status quo, we can see how the project works and we just need to fill in some details and send our work to development. We are all very excited about the speed of progress!

The revised Coordicide Whitepaper was finished just before the holidays and sent out to Research Council members and other academics for some “internal” review, in preparation for a public release early in the new year. Of course, many of the updated concepts and approaches have already been discussed on IOTA.cafe, so the contents of the paper will already be familiar to those following IOTA Research closely. But we look forward to public feedback on the compiled Whitepaper.

Our general comment on the progress of our fundamental solution is that there have not been any major surprises. Many of our original hypotheses have been confirmed, and we will continue with Coordicide as envisioned. Please stay tuned for a blog update when we make the public release of the updated whitepaper.

The research (sub)groups were reformulated a bit during our Berlin conference. The current formulation of the groups are as follows: “Networking,” “Decentralized RNG (dRNG),” “GoShimmer Implementation,” “Fast Probabilistic Consensus (FPC),” “Mana and Autopeering” and “Protocol.” Below, we provide some updates from these groups.

Networking.The former rate control team has been “rebranded” as networking as it is currently working on multiple tasks, all related to the networking aspects of IOTA. In the last month, we mainly focused on finalizing a few articles about anti-spam mechanisms for the Tangle. In particular:

“On the Fairness of Distributed Ledger Technologies for the Internet of Things”, where we propose a solution to facilitate IoT devices in the computation of the Proof of Work. Submitted to IEEE ICBC 2020.
“No More Proof of Work: Rethinking Distributed Ledgers through Verifiable Delay Functions”, where we propose an anti-spam mechanism based on verifiable delay functions to replace Proof of Work. Submitted to ACM MobiHoc 2020.
“On the Decentralized Generation of the RSA Moduli in Multi-Party Settings”, where we propose how to generate an RSA modulus in a distributed way, which is fundamental to the correct functioning of a VDF-based anti-spam. Uploaded on ArXiv.
“Smooth Operator — The Use of Smooth Integers in Fast Generation of RSA Keys”, where we propose an optimization to the RSA modulus generation through smooth numbers. Uploaded on ArXiv.

Furthermore, we are designing the congestion control algorithm for Coordicide: when the demand (i.e. the number of transactions) increases, the nodes have to sort and filter out certain transactions based on objective criteria. We are also implementing a Python simulator to test the proposed algorithm and tune the related parameters.

dRNG. We decided to create a new research (sub)group in the Research department. The new group is called the ‘’dRNG group’’ and its main goal is to provide a suitable decentralized random number generator (dRNG) for the IOTA network. A dRNG is a necessary part of Coordicide as the FPC consensus mechanism requires it. The group will analyze existing dRNG solutions such as drand, which is used by, among others, League of Entropy, which is an already functioning distributed randomness beacon. We have already started describing how drand could fit into IOTA in this blog post. We will adapt and develop a decentralized random number generator which is optimal for the IOTA network. Currently, the most promising candidate seems to be a combination of already existing solutions which are based on drand with decentralized committee selection in reputation (mana) systems.

GoShimmer Implementation. The Research Team has finalized the integration of the new core modules for the next GoShimmer release supporting 0 value transactions:

Autopeering: automatic peer discovery and distance-based neighbor selection
Gossip: network layer for sending and receiving new transactions
Rate control: a temporary non-mana based rate control to limit transaction issuance
API: interface to send 0 value transactions and query the Tangle

We have focused our efforts particularly on the reliability of these components so that integrating the ledger state and voting layer to support value transactions can be our main target for future releases.

We will release an update to GoShimmer this month, as planned in the roadmap.

FPC. We have performed simulation studies on the effects of mana on the performance of FPC. The results obtained have provided valuable insights into how to improve the finalization of opinions and make the protocol more stable. We also released a blog post on berserk detection which demonstrates that honest nodes can actively engage with each other to identify and blacklist malicious nodes that follow a berserk strategy. In FPC, so far, the responses of nodes to queries have been unchecked and this allows for a larger amount of freedom for the attacker to affect the security of the protocol. In its most severe form, we call this a berserk attack. Initial research indicates that the communication overhead for the detection method is manageable and that it can be implemented as an optional addition to make the protocol more secure.

Mana and Autopeering. This group passed through a restructuring this month with the decision to focus our manpower on the first version of Coordicide. Our first decision was about which of the many researched versions of the mana system would be used, and this decision with some details was already specified in the new version of the Whitepaper. Although the mana system is well defined and many discussions led us to a good general understanding of it, how mana will be used by the other parts of the protocol still needs to be specified and simulated. During the next month, the group will be focused on fast calculation of mana by nodes, writing proper specifications and defining how mana will be used together with the Salt Autopeering. We have been discussing our ideas with the GoShimmer group, and we expect to conduct simulations soon which will allow us to come to a final decision about all remaining questions.

Protocol. During the last month, the Protocol Team focus was on three topics:

IRI Implementation: It is already known that there are many ideas from Coordicide (or born from Coordicide discussions) that are going to be implemented in IRI in order to improve the network performance and security. The Protocol Team is the one responsible for such communication with the Development and Engineering Team and during the month we have often been supplying them with all the information needed, including the new URTS tip selection, the milestone selection and the conflict white flag. Those changes will remove many bottlenecks of the current network and the group is quite excited to see them implemented.
Time and Order in the Tangle: During this month we had many discussions about the different time systems that will coexist in Coordicide. The most important one being the timestamp system (a signed value where you declare your issuance time) that will be widely used in other parts of the network. The use of checkpoints was also discussed and it looks quite useful for simplifying a variety of situations as snapshots. We are currently continuing discussions about when we trust a timestamp. For this the best perspective will be the use of the “Levels of knowledge” system that is being currently discussed.
When a node receives a transaction: The protocol includes several steps that a gossiped transaction received by a node needs to go through, such as signature validation, rate control, congestion buffer, ledger state calculation, voting, propagation and BelowMaxDepth criteria. We now have enough information about all those steps so we are able to determine how these “phases” can be organized within the protocol in a way that minimizes the computational overhead. This task lead us to another interesting question: When should a node, after receiving a transaction, include that transaction as a tip in its tip selection? The answer is somewhat simple: when it cannot be disliked by voting anymore. To give an objective criteria for this, we will again make use of the Levels of Knowledge.

In the coming month the group will continue its work with the IRI Team and further develop the “Levels of Knowledge” approach.

CA. Finally, we want to note that we decided that Cellular Automata will not be part of v.1 Coordicide. Simulations have shown that FPC alone will be robust enough to meet the needs of the network in this initial version of Coordicide. We remain highly interested in developing CA, and will do so at the appropriate time.

We hope this update was informative and helpful. As always, you can stay up to date with the IOTA Research team in the #tanglemath channel on our Discord. And you are welcome to follow and participate in our technical discussions on our public forum: IOTA.cafe.