IOTA Research Status Update

We’re pleased to share the latest news from the IOTA Research department. We hope that you enjoyed the Introduction to Coordicide Specifications presentations we released recently. Below are the latest updates on our progress.

“Naming” meeting. Several researchers met with additional members of the Foundation to name many of the new Coordicide structures. This may seem trivial, but it is actually difficult due to their importance and permanence. Both internal and external developers need to understand how IOTA works in order to build applications. Besides slowing production, an unintuitive naming scheme can even hinder adoption by discouraging people from building on the IOTA platform.

We have made good progress. Because we expect most of the traffic on the IOTA network to be “0 value transactions”, we have tentatively decided to rename the objects in the Tangle “messages” instead of “transactions.” Each message contains a payload, and we have developed names for several of the core payload types. In addition to core payloads, users can define their own payload types which need not be processed by all nodes. With this flexible message/payload format, IOTA can serve a diverse number of applications.

In conjunction with the naming process, we are close to finalizing, on a high level, the layout of messages and several core payloads. In order to name things, we need to understand what we are naming. This is an important step in developing a standardized protocol.

We expect, by the next update, that the terminology will be finalized and made public.

Specifications. We have made great progress on the specifications of Coordicide, and are currently working on the blueprints and a yellow paper. Mike Bennett from OMG and our Head of Standardization is assisting in this process. The work on GoShimmer (first Coordicide implementation) is well underway and we intend to launch the first testnet in several weeks. This is a joint work between the research and engineering team. In order to have both teams aligned on the theoretical level, we developed a series of presentations in which we give a brief explanation about the topics to appear in the main specifications file. The presentations were quite well received and enabled the engineers to join researchers in each topic to work with. The writing of the specifications has started and we hope to have great development on them in the coming month.

Networking. We finalized a first complete solution to deal with network congestion. In particular, our proposed protocol is made up of two modules on top of rate control: (i) scheduling, which gives priority to transactions issued by certain nodes to share the throughput proportionally to mana; (ii) rate setting, which deals with local congestion, and it is inspired by AIMD. We are currently running extensive simulations, and also comparing with existing scheduling policies and congestion control algorithms. Our results show that fairness is guaranteed, and latency is bounded. We plan now to add a packet drop policy to deal with transaction bursts, and subsequently evaluate how this policy affects the consistency requirement.

Concerning the adaptive PoW algorithm, we solved the so-called collision problem by removing sequence numbers (you can read more here). The protocol is ready for specifications. Additionally, in the context of VDFs, we are studying lower bounds on the number of gate operations needed to solve modular squarings, which will provide estimations on the physical limits to solve a VDF. Our talk on IOTA and VDFs at Stanford Blockchain Conference is available on YouTube.

dRNG. We finalized the bulk of the concept work on a decentralized Random Number Generator (dRNG) for the IOTA network. Our work involved the adaptation and adjustment of the drand protocol, to make it work in the DLT, permissionless environment. We designed a special Tangle messages layout that allows for the committee selection, distributed key generation and seamless acquiring of the randomness.

At the moment the main focus of our group is to write the specification for the developers. We are also developing, however, additional security features of IOTA dRNG. The final specification is planned to have backup randomness generators as well as detection mechanisms of the committee failures and methods of appointing the new one.

GoShimmer Implementation. Our community has been tremendously helpful at testing our prototype and as a result, we have released v0.1.3 which includes several bug fixes, improved autopeering and dashboard and more stability.

Meanwhile, the GoShimmer team has been working on the upcoming next release v0.2.0. We have integrated support for traditional public key cryptography based on elliptic curves (e.g., Ed25519 and BLS) as well as binary hash functions such as SHA-256, SHA-512 and Blake2b.

Goshimmer modularity has made further progress by implementing a layer-based approach. Although the naming of the layers is not yet finalized, we can give you a sneak peek: the first layer deals with messages; each message contains some metadata such as trunk, branch, timestamp and other information related to the issuer node’s identity as well as a payload. Each payload has a type and some data. Based on its type (e.g., dRNG type, value transaction), the included data can be interpreted accordingly. This “interpretation” layer is our second layer. On top of that, we have the “application” layer where a protocol can leverage on the information provided by the underneath layer. For instance, a smart contract protocol could be implemented on top of the value tangle (i.e., the protocol that implements value transaction), or a decentralized lottery protocol could be implemented on top of the dRNG protocol.

Value transactions and the UTXO model are now completed in the develop branch. We are also connecting the FPC protocol to the value tangle so that conflicting transactions can be resolved by voting. A faucet application will allow users to request funds for testing purposes.

The dRNG has also been integrated into its first iteration: committee members will run an IOTA version of the drand application and will send “collective beacons” to the network via a GoShimmer node. Each node will be able to verify the correctness of the collective beacons by verifying their signature against the distributed public key (i.e., the public key derived from the public keys of all the committee members).

Finally, we have been working on some minor improvements: a better network visualizer, both client and server sides; a plugin manager that allows developers to easily add and manage GoShimmer plugins; automated integration tests; a more flexible autopeering that resolves previous NAT and reverse-proxy related limitations.

FPC. In the FPC group, we continued to work on optimizations of the FPC. Simulation studies show that these adaptations decrease the failure rate at least one order of magnitude. Currently, we are summarizing these results in a research paper; the video may give you a first idea of our approach and of the kind of results we are able to show. The specifications of FPC are advanced and the remaining details will be decided in collaboration with the engineering team.

Mana and Autopeering. The mana and autopeering projects are beginning to wind down. We discussed the final questions regarding the specifications and made some final design decisions.

We have also continued to work on our research papers. We have decided to write two papers: one analyzing our simulations made with our GoShimmer simulator. The second will contain our mathematical calculations. We also hope to write conference proceedings that summarizes the results in both of these papers.

We now have three tasks left:

Write the specifications
Finish our research papers
Set the parameters

Although the first task is clearly the most important, we expect to continue to make progress on our papers. We have decided to wait on researching the final parameters till after we are done with the spec.

Protocol. The protocol group this month dealt with the finality problem on the Tangle, where we developed a series of tools to allow the user to check the security of its transactions. We also discussed optimizations and how to make finality calculable within reasonable computational cost. We are in the process of determining probabilities values for the finality tools, so we know exactly how safe we are. The next step of the group will be to determine the bottlenecks to be optimized in the current approach by analyzing the processing procedure of a node, as well as start to write the specifications.

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.