IOTA Resarch Status Update
IOTA Research Status Update
March 2020
Our research groups are pleased to share our latest progress updates from February & March 2020. All groups are progressing nicely toward our goals. Much progress has been made since our February ReSum — where we were engaged with the topics outlined below, as well as liaising with several of our engineers, with whom we are working together to translate our results into end-user products
Research Meeting — Lisbon Summit: This Research Meeting had a different approach than previous meetings. With most Cordicide questions answered and a large number of its components well specified, it was time to discuss in detail how our research is to become the Coordicide. Therefore, much of the meeting focused on defining the structure of nodes, the transaction structure, and how transactions will be processed, among others. We also defined our communication processes with the Engineering team so work on specifications will be as streamlined as possible. We have now begun work on the specifications of Coordicide (think of it as a “yellowpaper”), and our whole team looks forward to seeing the final result.
Networking. We have built a Python simulator in order to evaluate the performance of the Additive-Increase/Multiplicative-Decrease (AIMD) congestion control protocol in the Tangle. The metrics we are interested in include (i) probability of transaction drop, (ii) throughput and (iii) fairness (i.e., the capacity of a node to issue transactions based on its reputation score). Our goal is to customize the protocol in order to prioritize transactions based on their size, type and timestamp.
Additionally, we are delighted to communicate that the paper “On the Fairness of Distributed Ledger Technologies for the Internet of Things” has been accepted to the Poster track of the 2020 IEEE International Conference on Blockchain and Cryptocurrency (ICBC 2020) and the papers “Implementation Study of Two Verifiable DelayFunctions” and “Parasite Chain Detection in the IOTA Protocol” have been accepted for publication and presentation at the 2nd Tokenomics on Blockchain Economics, Security and Protocols.
dRNG. The development of a decentralized Random Number Generator (dRNG) for IOTA is well on its way. After the analysis of available options, we decided to use thedrandprotocol, based on the threshold version of the Boneh-Lynn-Shacham (BLS) signature scheme. This protocol seems to be better suited for our purposes than schemes based on commit-reveal and VDFs, for example. We also started working on the committee selection among high mana nodes (those nodes are going to be producing randomness). We have a few available options for committee selection. One promising result of our research thus far is related to nodes being able to declare their own mana simply by issuing a special transaction.
GoShimmer Implementation. We have finally released GoShimmer v0.1.0 [blogpost], which supports zero-value transactions and includes a set of new features such as the salt-based autopeering, a rewritten gossip layer, and new APIs and dashboard, to list a few. We are so excited to see the full Coordicide solution implemented into GoShimmer that we have already started working on the next release.
We have also completed an initial integration of the drand protocol into GoShimmer [see this branch on Github]. This integration enables a distributed committee to generate and broadcast fresh and publicly verifiable randomness into the Tangle. In order to speed up dRNG testing independently from other sub-modules, such as the committee selection, we are planning to temporarily run a community-based committee for the first test of our drand integration. Stay tuned for more information about this in the following weeks!
Moreover, we are working on implementing other important aspects of GoShimmer, such as value transfers. You can follow our progress on the develop branch.
FPC. In the FPC group, we worked on reducing the communication overhead for the voting protocol. The amount of mana a node holds proved to be a core element in deciding in which way a node should communicate. In order to make the voting communication efficient, it was required to consider various concepts depending on various network assumptions. Additionally, we have worked on several improvements to the voting protocol itself, in the sense that the agreement failure rate could be reduced greatly, also in the context of various mana distributions in the network.
Mana and Autopeering. For autopeering, we have largely completed the first round of simulations and we are currently analyzing our results. We have begun organizing our simulation and analytical results on autopeering into research papers. These results, however, mainly consider the case where mana is not used in the Autopeering. Thus we need to add mana to our model.
For mana, we established some goals and questions. We have decided to use Mana 2, and to compute it using a moving average. Using these tools, we can bound the difference between any two nodes’ perceptions of mana in terms of the network delay. However, under these assumptions, mana growth is governed by a number of equations that we are now studying.
Protocol. The protocol team has been focused on answering questions about some details of the protocol specification, so we’re now preparing to pass them to the development team. Of the many discussed ideas, the “Levels of Knowledge” approach was found to fit many of our needs, especially our desire to reduce the number of voting rounds, and also giving a fair threshold for filtering bad timestamps or existence of conflicts, for example. We also worked on how we would handle the parameters for the “Levels of Knowledge,” such as how resynchronization of small sets of transactions occurs and when to transition this resynchronization to a restart of the node (large scale resynchronization). Finally, we discussed the use of finality criteria and which tools we should provide for users to be able to accept transactions. Among the three good proposals we have, checkpointing is particularly suitable since it is also useful for local snapshotting.
In the coming month, the protocol team will finish the discussions about the few details that still need to be addressed, and will write the specifications of those components which remain to be coded in the prototype.
Extra Discussions: Coming out of the Lisbon Summit, we decided there were some research questions around which we would like to fine tune our conclusions. So the teams have held smaller meetings aimed at tackling them. These topics included resynchronization, snapshotting and the “realities” approach for ledger state calculation. The extra discussions were successful in enabling us to optimize our approach to each topic.
Finally, we wanted to say a few words about how the Research team collaborated with other teams in the Trinity Attack mitigation process. Research team members were quick to jump into action following the exploit. Researchers and engineers worked closely to develop the master plan, and several researchers were involved in tracking funds, as well as planning around the migration tool. The open dialogue among the teams helped ensure that the “big picture” of the mitigation strategy included all the best approaches.
We look forward to sharing further updates with you soon! 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.
