Skip to main content

Preface

Written on 2 June 2021

IOTA 2.0 Research Specifications

This document contains the research specifications of the IOTA 2.0 Protocol. Their purpose is to carefully explain the current state of the IOTA 2.0 protocol to developers, both internal and external, who wish to build on or test Nectar, to academics who want to analyze, model and optimize the protocol and need rigorous description of each module, and to community members and anybody who just want to learn more about the protocol.

We hope this document is a useful guide to the IOTA 2.0 research specifications, and we hope that you dive into them to learn as much as you can about how the IOTA 2.0 DevNet works! However, before reading the specifications, we would like to explain a few points to the reader.

What Are Research Specifications?​

This collection includes specifications on each key experimental component of Coordicide. However, there are two important caveats regarding these documents.

First, none of the parameters are finalized. Although our previous studies give certain ranges for each of these parameters, tuning each parameter to its optimum value requires a lot of testing and research. Luckily, we can conduct this research while the software is being developed since the parameters we are fine tuning are very easy to change in the code. In these specifications, each parameter is set to an educated estimate.

Second, several non-experimental components of the protocol are omitted from this document. For example, snapshotting (the module which manages the pruning of old messages in perma-nodes) and a description of the gossip protocol are omitted. Both of these components are well understood parts of the current Chrysalis mainnet, and thus we felt including them was not worth delaying the specifications release. In the table of contents on the readme file, you can find the missing specifications that we will add over the summer.

A final point to note is that these specifications are not stable nor are they subject to a strict versioning system. Nectar is a research prototype. As such, it will be used to conduct research and refine the specifications as necessary to optimize the protocol. Over the coming months we will be collecting data and performing experiments on the IOTA 2.0 DevNet. We learned a great deal about the protocol just by building it, and the information gained from testing at this stage will further improve the protocol and future implementations.

Specifically, we will:

  • Optimize parameters
  • Improve the software implementations of the protocol in conjunction with developing the Bee and Hornet nodes
  • Identify and remove any potential performance bottlenecks
  • Optimize the performance of each module
  • Simplify the protocol by eliminating any elements which are found to be unnecessary.

As we make these improvements to the protocol, these specifications will change.

Any protocol which reaches adoption continuously evolves and improves, and the IOTA protocol will be no different. The IOTA Research Department will always strive to make new discoveries to perfect the protocol, and we will also always maintain some sort of research specifications to track the proposed changes.

Nectar Documentation vs Research Specifications​

The reader may notice the GoShimmer repository on GitHub contains its own documentation describing the protocol. How does that documentation relate to these specifications? What is the relationship between Nectar and these specifications?

The Nectar documentation describes how the protocol works on the IOTA 2.0 DevNet, whereas the IOTA 2.0 research specifications describe what the IOTA 2.0 protocol should look like. In theory these should be the same (and someday they will be), but currently there are some differences.

The Nectar documentation was developed for two purposes. First, it was to help our research engineers figure out how to code certain modules, since parts of the prototype were written before the specs. Second, the documentation helps others, both internally and externally, to navigate the code base. As a result, the Nectar documentation is not complete, only covering the core portions of the protocol.

Also, since Nectar is a prototype, a few shortcuts were taken in the implementation. For example, the dRNG committee is fixed, rather than rotating based on consensus mana. This simplifies the implementation while allowing us to conduct the requisite research. The research specifications tell how the committee is supposed to be selected.

Protocol vs Implementation Specifications​

A protocol is an agreement between several nodes on how to exchange and interpret data. The implementation of the protocol is the software that performs the actual operations dictated by the protocol. The protocol is unique and fixed, while the implementation varies. For example, HTTP (HyperText Transfer Protocol) dictates how your browser should communicate with internet servers. There are several browsers (Firefox, Chrome, Safari, etc.) which run this protocol. Internally, these browsers work very differently from each other, having different features and designs, but they all communicate with a server in the same way.

IOTA 2.0 is a standardized protocol, and thus will have special protocol specifications dictating how IOTA nodes must behave. The IOTA Foundation will create two software implementations of this protocol: Bee and Hornet, written in rust and go respectively. However, each of these implementations will have implementation specifications which describe exactly how the software works. Using the protocol specifications, anybody can (and hopefully eventually will) write their own software implementations with their own implementation specifications.

These research specifications are a mix of both the protocol specifications and the implementation specifications. Why is this the case? Because all of our ideas must be tested in code, we have to develop the protocol and an implementation of the protocol at the same time. Any ideas which cannot be efficiently implemented have to be rejected. Now that we have a working prototype, we can begin separating the protocol from these specifications while the engineering department works on the implementation.