The IOTA Research Department recently published the Fast Probabilistic Consensus Simulator.
Today, we are excited to share with you the corresponding research paper on arxiv that studies various properties of the FPC. We invite you to take a look at this research paper. We also want to give you a short overview of what kind of results we have obtained.
The abstract tells us:
This paper investigates leaderless binary majority consensus protocols with low computational complexity in noisy Byzantine infrastructures. Using computer simulations, we show that explicit randomization of the consensus protocol can significantly increase the robustness towards faulty and malicious nodes. We identify the optimal amount of randomness for various Byzantine attack strategies on different kinds of network topologies.
Let’s see what all these “fancy” terms mean. In the current IOTA tangle consensus is achieved by the coordinator. One core module of Coordicide is FPC, a distributed consensus protocol. Distributed consensus protocols allow networked systems to agree on a common opinion in situations in which centralized decision making is difficult, impossible or unwanted.
As distributed computing is inherently unreliable, it is necessary to reach consensus in noisy or Byzantine infrastructures. The latter is equivalent to the presence of malicious nodes that try to attack the protocol. The word noisy refers to nodes that may be faulty or to possible message loss.
The FPC is leaderless since it does not require a (elected) leader. An advantage of this is that every node can update its opinion locally without having to wait for the coordination of the leader. In FPC every node queries a random sample of other nodes and adopts the opinion of the majority. In the basic version there are only two possible opinions so we speak of binary majority consensus.
Previous protocols in the class of leaderless binary majority consensus protocols are: the simple majority consensus and the random majority consensus.
These protocols, however, can rarely guarantee the eventual agreement of the nodes in Byzantine infrastructure. For this reason, FPC proposes an additional randomness that serves as “fog of war” for potential malicious attackers, making it at best impossible for the attacker to effectively influence the honest nodes.
The additional randomness is the key element that allows overcoming Byzantine failure. The randomness is parameterized by a parameter β; the larger β the less random the protocol. One main interest was to identify the β’s that allow the maximal proportion of adversary nodes. In the following graph, we plot the agreement rate as a function of β and the proportion of adversary nodes.
An agreement rate of 1 means that in 100% of the simulations all honest nodes eventually shared the same opinion. An agreement rate of 0.9 signifies that in 90% of the simulations all honest nodes had the same opinion and that in 10% of the cases at least two honest nodes terminated the protocol with different opinions. We see that, in the above situation, the protocol with β=0.3 allows the highest proportion of adversary nodes.
Our focus lies in the performances of the FPC in Byzantine infrastructures. For this purpose, we propose explicit adversarial strategies, which either target the integrity of the resulting opinion, the agreement of the nodes on the opinion, or the termination of the protocol altogether. Some of these strategies are also described in Consensus in the iota tangle — FPC. The performances are measured using integrity rate, agreement rate, and termination rate.
Moreover, we investigated the dynamics of the protocol during an attack. The next graph shows the evolution of undecided nodes under several attack scenarios. We see in a) that the FPC is robust against certain malicious attackers even without the additional randomness (β=0.5). To overcome Berserk attackers, however, the additional randomness is crucial, as the comparison of b) and c) shows.
In the FPC paper, it is assumed that every node has a complete view of the network. We weaken this assumption in considering several network topologies and analyze how the lack of complete knowledge about all other nodes affects the ability to reach consensus. You may also take a look at the previous post Fast Probabilistic Consensus Simulator for more details.
One of our main results is, therefore, well summarized in the last sentence of the abstract:
We identify the optimal amount of randomness for various Byzantine attack strategies on different kinds of network topologies.
As always, we welcome your comments and questions either here in the comments, in #tanglemath on our Discord server, or in the IOTA.cafe. You can also engage in more intense scientific collaborations with us and apply for a grant.
The author is not a member of the IOTA foundation. He wrote this blog post in collaboration with the members of the IOTA research group.
Simulation study of FPC was originally published in IOTA on Medium, where people are continuing the conversation by highlighting and responding to this story.
Dev status update — November, 2019
Published by the IOTA dev team every month, this update will provide you with news and updates about our key projects! Please click here if you want to see the previous status update.
Last month, the Bee team met in Berlin to get some work done face-to-face. This meeting was dedicated to finding the right level of abstraction and creating a clear roadmap for Bee v0.1. This effort was to ensure that our implementations are flexible but not over-engineered.
We have decided to pre-approve RFCs if they are sufficiently advanced for the implementation to start, and if the blockers are well-defined. The first such RFC is for representing IRI transactions and bundles. Work on the hashing RFC has also advanced well, and we have the first drafts for storage and proof of work.
We are also investigating what flavor of Async to choose in order for the networking RFC to be prepared soon. For the Bee Tangle implementation, we have come up with an idea for eager solidification, which should give us some performance and efficiency gains compared to the current implementations. You can about this and the other RFCs in the bee-rfcs repository.
Finally, we are putting the final touches to our open source governance idea for Bee to slowly become an open source project run and developed by the IOTA community.
You can always see what the Bee team is up to in the open Discord channels where the day-to-day team communication happens. See the `bee-dev`, `bee-discussion`, and `bee-rfcs` channels. You can find the meeting minutes for both RFC and development meetings in the meeting minutes repository.
Our main software implementation has been making great strides over the past couple of months when it comes to stability and improved node operator experience. We still have some ongoing efforts that should make the lives of node operators significantly easier. For example, improving local snapshots to allow users to define the size of the database in bytes instead of milestones. This has been a very sought-after feature and we’re confident it will be made available in IRI soon.
While IRI has several parallel efforts ongoing at this point, the main focus of the upcoming months is still performance. The team is working on changing the persistence layer in order to support transaction caching, which should in turn significantly increase the number of transactions we can process.
The FPGA team now has a fully working Curl-P implementation running on QLE core. This was achieved with manual configuration. In the future, we also want Qupla and Abra code to be converted into configuration data for QLE cores. This is currently in progress.
To kick off further discussions around the messaging layer, we will be publishing Medium articles on this topic in the near future. And we’re looking for your feedback and discussions in the #Qubic Discord channel afterward!
GoShimmer serves not only as an important testbed for our Coordicide effort, but will also be extensively used for Qubic simulations. We are now in the process of making changes to GoShimmer to support that.
As is now rather well-known, the Trinity team has been working on an exciting new feature: the ability to purchase IOTA directly from the wallet. We have integrated MoonPay into both mobile and desktop clients to enable smooth purchase of tokens. This will be a significant milestone for Trinity and our ecosystem, greatly streamlining new user introductions into IOTA.
The team has also been working on a spent address recovery tool. Both features are for the most part ready and should be just around the corner.
Another new and exciting project is also baking and the team is looking forward to sharing the details soon.
We are now in the process of creating a specification and a validation prototype for a new and improved version of MAM. We believe we will have a prototype reflecting this first specification finished by the end of the year.
Some of the improvements of the upcoming MAM will include:
- The ability to grant new users access to older messages.
- Amending messages to an existing data message.
- Integrated key exchange functionality
- and much more.
We’re excited to share all the details with you once the prototype implementation is closer to being finalized.
Throughout January, we would like to take the time to ask for everyone’s feedback on the functionality of the new MAM. We will use this feedback for the final implementation.
The permanode team has started its initial implementations of porting Chronicle to Rust. One big topic for the team was investigating the Rust runtime environment that will be used. We decided to stick with the Tokio runtime for now, but plan on benchmarking it against a minimal work-requesting runtime.
As always, we welcome everyone to stop by on Discord — every project mentioned here has a channel (or more) for discussion with our teams!
Follow us on Twitter to keep track of all the latest news: https://twitter.com/iotatoken
Dev status update — November, 2019 was originally published in IOTA on Medium, where people are continuing the conversation by highlighting and responding to this story.
Joshua is joining IOTA as Software Developer of the Bee team. In this role, he will focus on developing and maintaining the Bee codebase and associated IOTA infrastructure in Rust. Joshua lives in Bristol, UK and has been writing software for almost a decade. He has also worked as a web developer and embedded software engineer.
On joining IOTA
IOTA is a fascinating project that brings new ideas and concepts to the world of distributed communication and ledger technology. I’m excited to work as a developer on this project and to see what the future holds for the IOTA protocol and the systems that will be built on top of it.
We are very happy officially announcing Joshua joining the project, his experience as a Rust developer is of great value to the IOTA foundation. Give him a warm welcome!
Welcome Joshua Barretto to the IOTA Foundation was originally published in IOTA on Medium, where people are continuing the conversation by highlighting and responding to this story.
Untangled Podcast is back — Episode #15: Smart Wallets & Future of Mobility
The Untangled podcast returns for a brand new season. The second season will continue to focus on the use cases and ecosystem around IOTA’s technology, the Tangle, as well as more general perspectives around Internet of Things (IoT) and the ongoing digitalization and automation of our societies.
Automotive and mobility are among the sectors predicted to undergo the most drastic changes throughout the next decade due to IoT and digitalization with Mobility-as-a-Service growing, vehicles becoming their own autonomous agents, and ever-increasing amounts of data being collected and shared between vehicles and other parts of the infrastructure.
The first episode of the second season shines a light on some of those changes, specifically the Smart Wallet developed by Jaguar Land Rover.
Russell Vickers and Aaron Hetherington from Jaguar Land Rover’s Software Engineering Centre will explain more about what a Smart Car Wallet is and Anne Smith, Head of Automotive & Mobility in the IOTA Foundation, and Martin Koers, Managing Director in the German Automotive Association (VDA) offer their perspectives on the current and upcoming situation for the whole industry with emerging technologies like distributed ledger technologies (DLTs) on the front seat of innovation.
In the second season of Untangled we will also get around some of the topics and sectors that we did not yet cover in the first season.
So stay tuned for a season full of inspiring projects and use cases based on IOTA’s Tangle and get exclusive insights from experts within a wide range of sectors.
Listen to the first episode of the new season here:
Smart Wallets & Future of Mobility | Untangled
Provide your feedback here:
Untangled is available on a wide array of platforms; all listed below:
Untangled Podcast is back — Episode #15: Smart Wallets & Future of Mobility was originally published in IOTA on Medium, where people are continuing the conversation by highlighting and responding to this story.
Jakub Cech joined the IOTA Foundation in May 2018 as Product Owner. With his background in learning algorithms, distributed systems programming, programming for parallel computing platforms, cloud microservices, and product management, Jakub took the lead focusing on IOTA node software implementation (IRI), with stabilization and performance improvements of the software. Jakub was also responsible for the development of the client library software and the release of the account module. The IOTA Foundation now actively develops client libraries in six programming languages. Jakub also led other projects throughout the IOTA Foundation, for example, the new documentation portal.
On joining the IOTA Executive Team
When I first joined the IOTA Foundation, many of the software offerings and products that were being developed by the Foundation were in their early stages. Many of the changes that needed to happen were already laid out, but much of the development process still needed to be defined and set in place.
We are now seeing an increase in the interest from external parties for implementing the IOTA technology. This requires us to mature the offering of our technology stack. It will be my responsibility, as Director of Engineering, to ensure that the development of our technology is aligned with the needs of our users and partners. In addition, we want a level of transparency that allows everyone — an individual or an organization — to contribute to the development.
The IOTA technology is on a course to be the backbone of very exciting IoT solutions, which significantly improve not just our daily lives, but society as a whole. I’m very excited to be part of this journey.
With the development of IOTA technology, we identified an increasing need for working with existing IoT hardware manufacturers and IC fabricators. That’s why the former Director of Engineering, Edward Greve, will continue with the IOTA Foundation as Head of Engineering Asia. His focus will be on building out the local team, working with companies and governments in the region, and setting up R&D centers to showcase our products. Edward is already located in Taiwan, which makes him perfectly positioned for this particular role.
We are delighted to welcome Jakub as Director of Engineering for the IOTA Foundation. His hard work and dedication combined with his in-depth understanding of the IOTA technology and the challenges it solves, make him a great fit for this position.
Welcome Jakub Cech to the IOTA Executive Team was originally published in IOTA on Medium, where people are continuing the conversation by highlighting and responding to this story.