Fully decentralized IOTA 2.0 explained in under 3 minutes

While IOTA 2.0 is a complex protocol with various modules, its core idea is actually quite simple. This post summarizes how IOTA 2.0 achieves consensus and maintains the ledger.

Data and transactions are contained in objects called messages. Every message must reference two to eight other messages. Thus the collection of all messages, called the Tangle, is an ever growing DAG, or a directed acyclic graph.

Currently, the Chrysalis network is governed by the coordinator, a centralized node run by the IOTA Foundation. The coordinator states which transactions and data are included into the ledger, i.e. the list of token balances of all users. To be fully decentralized, we will remove the coordinator in version 2.0 of the IOTA protocol. In the Coordicide project, we designed the new protocol which will kill the coordinator.

Without the coordinator deciding which transactions to include, a valid message must have a consistent history without any conflicts. So when conflicts arrive, the Tangle forks into different branches. The upcoming IOTA 2.0 protocol must do two things:

1. Decide which branches will survive.
2. Record this decision for new nodes joining the network later.

This allows the IOTA protocol to maintain a consistent ledger where everyone’s balance is always available.

Consider the following example: Dom has 5 MIOTA. First, via transaction A, he sends these 5 MIOTA to Navin. Then, Dom accidentally (or intentionally) sends these same 5 MIOTA to Serguei in transaction B. Now we have two conflicting transactions, A and B, and the Tangle forks into three branches: Branch 1 which includes transaction A to Navin, Branch 2 which includes transaction B to Serguei, and Branch 3 which rejects both transactions to Navin and Serguei.

The protocol must decide between the following:

• Branch 1, including transaction A to Navin, will be rejected, giving Serguei the 5 MIOTA
• Branch 2, including transaction B to Serguei, will be rejected, giving Navin the 5 MIOTA
• Both branches 1 and 2 will be rejected along with both transactions to Navin and Serguei, leaving Dom with his 5 MIOTA

Suppose the protocol rejects Branch 1. Then Branches 2 and 3 will survive, and eventually Branch 2 will “swallow” Branch 3, since Branch 3 does not conflict with Branch 2. However, an attacker can maintain Branch 1. The protocol must tell new nodes joining the network that Branch 1 is rejected.

An attacker can make lots of conflicts with complicated dependencies, creating an elaborate web of branches. Using Hans Moog’s (Senior Research Scientist at IOTA) “multiverse theory”, the branch manager module efficiently tracks all the branches in the tangle. Regardless of the complexity of the branches, the IOTA protocol always chooses a single branch, and then a single valid ledger state.

To make these decisions, the IOTA 2.0 protocol works in a cycle:

Before explaining each module, we summarise how they interact. Messages enter the network via the congestion control algorithm which manages access. Nodes vote on new conflicts through our voting protocol, Fast Probabilistic Consensus (FPC), which determines which branches should be rejected. FPC voting is protected from attackers by mana, a reputation system which fairly limits who can vote. After FPC rejects bad branches, tips are selected from the correct branches for new messages to reference. As these correct branches gain more messages, we say that their approval weight grows. Once a branch gets enough approval weight, its transactions are finalized and booked to the ledger, and mana is updated determining the next FPC voters.

Mana: In each transaction, token holders pledge consensus mana to nodes. Since these pledges require tokens, attackers can only have so much mana. See our blog posts Explaining Mana in IOTA Part 1 and Part 2 for more explanation.

FPC Voting: When new messages enter the network, conflicts trigger the voting protocol Fast Probabilistic Consensus, or FPC for short. First, nodes decide which conflicting transactions they like based roughly on what arrived first. Then each node votes by directly asking a few other nodes which transactions they like. If enough of these nodes like a transaction (where “enough” is a random threshold), the node likes it too. Then each node again asks a few different nodes their opinion, repeating the process several rounds until all the opinions stabilize.

Mana protects FPC voting: the more consensus mana a node has, the more often other nodes ask its opinion. Mathematical analysis and simulations show that FPC almost always terminates correctly with all honest nodes in agreement when the attacker has a significant amount of active consensus mana.

Tip Selection: After FPC terminates, the protocol has effectively chosen which branches to reject: any branch containing a transaction disliked by FPC is rejected. When creating a new message, nodes randomly select tips (unreferenced messages) from the surviving branches.

Approval Weight: The approval weight of a branch is essentially the amount of consensus mana held by nodes which issued a message on that branch. Since all honest nodes attach their new messages to non-rejected branches, the approval weight of these branches quickly becomes large, while the approval weight of a rejected branch remains small.

New nodes joining the network can infer the results of previous FPC votes they missed by observing which branches are heavy enough and which are not.

Finalization: Finality measures the probability that a message will not be orphaned. In IOTA 2.0, when the message is indirectly referenced by enough messages (weighted by the consensus mana of their issuers), the message becomes final, guaranteeing that the message is deep in the tangle and will not be orphaned.  In the Nectar prototype, this happens within seconds.

Thanks for reading. We hope you have a clearer understanding about the inner workings of IOTA 2.0 after reading this post. More information about the individual modules can be found on the IOTA 2.0 DevNet website here.

If you have any questions or would like to chat about IOTA 2.0, you can find our Research team members as well as many wonderful community members in the #tanglemath channel on our Discord. You are also welcome to follow and participate in our technical discussions on our public forum: IOTA.cafe.