Janis is joining IOTA as Senior Software Engineer of the Engineering team. In this role, he will help with general Rust adoption within the IOTA Foundation and lead the team working on the Bee project jointly with Thibault Martinez. Janis lives in Berlin, Germany, and has been working with Rust since it hit 1.0 in May 2015. He has done research on nonlinear dynamics, worked in computational social science, and co-founded a neurotech startup.
On joining IOTA
I am very happy to join the IOTA Foundation (IF) and I am honored to play a major role in the adoption of the Rust programming language throughout the organization, which includes embracing an open-source governance model. I was following the evolution of cryptocurrencies since September 2010 when I first heard about Bitcoin. IF is the first organization that convinced me to enter this field, with their goal to use distributed ledger technology for creating a framework to distribute and verify data in a decentralized way. The two aspects that really won me over and made me join IF are a), its non-profit nature and pursuit to bring together actors from industry, academia, and government, and b), the academic rigor of IOTA’s research team, which demonstrates their seriousness to put its technology on a solid footing. I will work closely with them to translate their vision into production-grade code. At some point in the future, I will get back to finish my PhD. For now, I couldn’t let the opportunity to join IF at this exciting moment pass by.
We are very happy officially announcing Janis joining the project, his experience as Software Engineer is an asset to the IOTA foundation. Give him a warm welcome!
Welcome Richard Janis Goldschmidt to the IOTA Foundation was originally published in IOTA on Medium, where people are continuing the conversation by highlighting and responding to this story.
The monthly IOTA Research Status Update will contain news and updates about our major projects.
This month’s update is about the status of our major task, Coordicide.
Our team is split into several subgroups, each of which is focused on a specific area of Coordicide. The DRIs (Directly Responsible Individuals) for each group meet regularly to discuss developments and impacts across the groups. We have found this workflow to be very effective.
Our primary goal is to deliver a specification for the Bee node software, which will form our implementation of Coordicide. This will run first on a testnet, and then later on the Mainnet. Our team is currently engaged in three tasks: writing a research specification, whitepaper revisions and researching the Coordicide components.
This specification is similar to a whitepaper, but with sufficient technical detail for it to be transformed into our next deliverable: the engineering specification. The engineering specification will then be handed over to our developers to code, test, and release.
We have received wonderful feedback from the public and our academic collaborators, including members of the IOTA Research Council. We are now writing a revised whitepaper in light of our research. This paper is extremely important to us, forming the base through which experts can verify the core of our solution.
Coordicide component research
Coordicide is made up of several components. While we are actively researching numerous topics, our focus in this post is the major Coordicide components necessary for completing the Research specification. Below we provide status updates on these.
We have two proposals for autopeering: “salt-based” and “arrow.” We have been analyzing the salt-based proposal both analytically and through simulations in GoShimmer. In particular, we have been investigating how long connections between nodes will last, and also studying the strength of the “verifiable randomness” test. We have also started modeling the fluctuations on the number of connections of the nodes’ graph. Soon we will compare the simulation and analytic results and compile them into a number of scientific publications. Once complete, we will be able to finalize autopeering the spec for handover to the engineering team.
Fast Probabilistic Consensus (FPC)
Our simulation study of FPC was recently published on arXiv. Together with the blog posts Simulation study of FPC and The FPC simulator, this completes the first milestone in understanding FPC.
We have made significant progress with Berserk detection, and a blog post is forthcoming. The blog post is based on the IOTA.cafe thread on the topic. We will discuss a safety feature that makes it impossible to be berserk in FPC. By implementing those features we will decrease the efficacy of possible attacks, leading to decreased probabilities of agreement and termination failures. This is confirmed by both the FPC paper and our simulations.
The actual implementation of FPC will depend on parameters defined by the reputation system and mana of the nodes. Given that the precise distribution of the mana post-coordicide is variable and unknown, our approach is to study the impact of various mana distributions on the robustness and efficiency of FPC. This analysis will allow us to determine the final parameters of FPC, and complete the specification. Completing this analysis is the main focus the FPC group.
The autopeering network protocols are designed so that Cellular Automata can achieve fast and robust convergence. However, the existing theory does not cover all practical situations. To integrate CA, we first determined whether the associated analytical tests provided the desired convergence. These initial studies reinforced what we expected from the outset — that it would be difficult to get new theoretical results for CA.
The logical next step was then to perform analysis through simulation. For this purpose, CA has been implemented in GoShimmer: https://github.com/iotaledger/goshimmer/tree/ca. We will use this implementation to run tests and simulations. This will allow us to check if the expected robustness holds.
As a voting protocol, CA distinguishes itself by having extremely fast convergence, and it is thus suitable for IoT applications, where we expect it to shine. FPC provides a more robust convergence. Based on the results from the simulations, we will determine whether to include CA in the first version of Coordicide. We expect both to coexist in future optimizations.
We are currently extending our previous paper on adaptive Proof of Work, which we will submit to the IEEE ICBC Conference as a follow up of last year’s publication. After that, we plan to integrate the adaptive Proof of Work into GoShimmer for testing and parameter tuning.
In parallel, we are investigating the use of a Verifiable Delay Function (VDF) as an anti-spam mechanism. The research focuses on generating a public RSA modulus in a distributed way, which will be used in a Wesolowski-like VDF. In November, we submitted two work in progress papers to the Stanford Blockchain Conference. We are now writing a third one on how to integrate VDFs as a rate control mechanism in IOTA, which we plan to submit to ACM MobiHoc.
Additionally, we are working on the definition of a congestion control mechanism for the Tangle. The main challenge is to guarantee that the nodes share the same vision on incoming transactions (or, equivalently, preventing network splits) by efficiently using the network bandwidth. We have sketched a protocol proposal inspired by the Additive Increase Multiplicative Decrease algorithm commonly used for the Internet, and we are currently building a simulator to evaluate its efficiency. After this validation phase, the next task is to provide full specifications for Coordicide.
Various packages have been integrated on the hive.go repository. Common packages and functionalities between GoShimmer and Hornet are organized together under this single repo. The new salt-based autopeering module (from autopeering-sim) has been integrated into GoShimmer and is currently in testing/debugging phase. The ledger state is near completion, currently in the testing/debugging phase. The gossip layer has also been refactored.
These updates to GoShimmer are essential because they make the overall implementation more robust and reliable. This, in turn, will allow us to focus on integrating the voting layer.
The pieces of Coordicide are coming together! Please stay tuned for further updates, and as always, feel free to reach out in our regular communications channels. You can stay up to date with the IOTA Research team in the #tanglemath channel on our Discord. We have also recently launched our public forum: IOTA.cafe. Please do check out these resources for further details on what we have outlined above.
IOTA Research Status Update December 2019 was originally published in IOTA on Medium, where people are continuing the conversation by highlighting and responding to this story.