- IOTA 3.0 is to become “the most scalable base layer DLT” and will combine fluid sharding and data sharing.
- The Pollen testnet version v0.3.0 will be released “very soon” and will include the distributed random number generator (dRNG).
In the recently published research update for October 2020, IOTA co-founder Serguei Popov reported on the progress of IOTA 2.0. But even more interesting for many may have been Popov’s statements about its successor, IOTA 3.0. It is well known that the IOTA Foundation has been investigating the possibilities of sharding for quite some time, but the new details may have stunned the IOTA community.
As Popov explained, the IOTA Foundation refers to its approach as “fluid sharding” and has already “examined it closely”. Fluid sharding refers to a scaling solution of the first layer, while the research department also looks at solutions of the second layer, which IOTA calls “data sharding”. The goal is to develop the most scalable base layer DLT, which will be called IOTA 3.0 and will include both data sharing and 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!
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.
Update to the IOTA Pollen testnet
Besides the new sharding approach, Popov also informed about numerous advances on the IOTA Pollen testnet. In addition to cleaning up GoShimmer’s code base, the focus last month was on implementing basic functionality for mana, “such as mana calculations, metrics collection and a first integration with the new transaction layout and wallet”.
In addition, new APIs were added and “given the importance of mana” some visualization tools were developed, which are embedded into the node’s local dashboard to better demonstrate the functionality, as well as a set of monitoring tools to study the dynamics. Snyk has also been integrated to increase the security of the code, as Popov explained:
From a Continuous Integration/Continuous Deployment (CI/CD) point of view, we have integrated the use of Snyk in 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.
Popov also reported important progress in the area of distributed random number generator (dRNG). Thus, the GoShimmer X team launched last month successfully tested the dRNG. “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”. In the next step, “very soon” a new Pollen testnet version v0.3.0 including the dRNG will be released as standard.
Remaining research work for IOTA 2.0
The research work for IOTA 2.0 is mostly finished, as Popov pointed out again. One of the remaining main topics is the synchronization between nodes and tools that allow the node to detect if it is out of sync. Apart from that, the specifications for bootstrapping are still being developed and the game-theoretical behavior of the Tip Selection is being discussed.
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.
In the area of networking, “a comprehensive attack analysis of the congestion control algorithm” is still underway. The IOTA co-founder wrote about this:
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.