In the following chapters, we explain in rather general terms how the new, decentralized IOTA protocol functions. Our aim here is not to provide the level of detail found in our research specifications, but to provide a reasonably detailed explanation that should give users a good idea about the general “under the hood” processes at work in IOTA. Achieving full decentralization and being feeless is a bit more complicated than simply relying on incentivizing third parties to safeguard a network by offering monetary incentives as in PoW or PoS based protocols.
In anticipation of the upcoming Nectar release, we wanted to give a brief explanation of how the IOTA 2.0 protocol (Coordicide) works. 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 IOTA 2.0 protocol must do two things:
- Decide which branches will survive.
- 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 A, Branch 2 which includes B, and Branch 3 which rejects both A and B.
The protocol must decide between the following:
- Branch 1, including transaction A, will be rejected, giving Serguei the 5 IOTA.
- Branch 2, including transaction B, will be rejected, giving Navin the 5 IOTA.
- Both branches 1 and 2 will be rejected along with both transactions A and B, leaving Dom with his 5 IOTA.
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, 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.
We hope this overview is helpful in understanding the basic functioning of the protocol. Please read on to learn more!