Removing The Coordinator – Untangling IOTA – IOTA Series Part 6

, ,
Removing The Coordinator

Welcome back to our series covering the essential elements of IOTA, a crypto network designed specifically for use with IoT (Internet of Things) devices.  We’ve learned a lot so far in our Untangling IOTA series, including what the IOTA Tangle is, how specific transactions are chosen for approvals (i.e., tip selection methodologies), and how approval, consensus, and confirmation operate in a network without a traditional blockchain implementation. (Remember that the tangle used by IOTA doesn’t take the “standard” form of a blockchain used by other cryptocurrencies, like Bitcoin and Ethereum; instead, the tangle is a ‘directed acyclic graph’ or DAG.)

IOTA Coordicide

            In the last post, we began discussing the most recent, and perhaps the most consequential, development in IOTA – the Coordicide.  To briefly recap the last post, the Coordicide is the work in progress by the IOTA Foundation to remove the Coordinator that is used as a protection against malicious actors on the network.  The current implementation of the Coordinator slightly denigrates the vision of a network that is fully decentralized (where IOTA can already be proven to be both scalable and secure).  The removal of the Coordinator is the plan for future development that will allow for solving the “scalability trilemma” discussed previously.  Only with the Coordinator removed can the network be fully decentralized.

Bitcoin and Ethereum both rely upon a Nakamoto consensus for transaction approval.  This consensus mechanism is the reliance upon over half of the network’s hashing power to be considered “honest” by definition.  You may have heard of the 51% attack – this is the ultimate outcome of a failed Nakamoto consensus.  In this attack scenario, a malicious actor or group of actors is able to achieve greater than 50% of the hashing power on the network.  With this power, they are able to double-spend tokens and halt any / all transactions leading to a compromised system.  Can they steal coins that have been previously used or falsify past transactions?  No.  But needless to say, this kind of power could have some serious consequences.           

Removing The Coordinator

It may go without saying, but this problem is not a simple one to solve.  This is the entire thrust behind the Coordicide effort by the IOTA Foundation.  The Coordinator currently plays the stop gap eliminating the possibility for a 51% attack.  But, as stated previously, this leaves some with a bitter taste in their mouths since decentralization cannot be truly achieved as there is a “man-in-the-middle” that could potentially alter or modify operations. 

That leaves us with attempting to understand the “how” behind this effort.  And as much as we would love to give definitive answers to these problems, not even the folks at IOTA know exactly how to solve these problems, yet.  We briefly mentioned the following building blocks in the previous post, but now we aim to explore their potential solutions and ramifications in this and future posts.  Let’s see how they interconnect (see Figure 1 below).

Figure 1:  The building blocks underlying the IOTA Coordicide.  Image from the Coordicide white paper.

As can be seen in the figure, there are layers to this approach – the logical layer that comprises efforts in the analytic, order of operations sense and the network layer that governs how nodes and transactions operate safely from a system perspective.  These five boxes depict the major steps in fully completing the Coordicide; we will take a closer look at each of them in turn.

Probabilistic Consensus

What is the overall thrust or catalyst behind the effort to remove the Coordinator?  The team tackling this effort states a desire to achieve a mode of probabilistic consensus wherein all network nodes would agree on the validity of transactions (with probability very close to 1).  While it may sound strange (why wouldn’t you want a probability of exactly 1?), this is a consequence of how discretized processes work in the computer world.  For example, brute forcing any private key space, regardless of the size, is always possible – but how likely are you to find a secret number as the key space grows to near infinity?  An 8-bit key space consists of 256 values to guess from; this is no big deal and can be achieved almost instantly.  A 512-bit key space consists of 1.34*10154 values; you can always find a value if you look at every single possibility, but it may take until the heat death of the sun to stumble upon the correct answer…

In addition to probabilistic consensus, the team is also looking for a means to achieve total consensus given a high enough probability from an approximate consensus.  Why would this matter?  Because every single detail on the network doesn’t need to be approved by every single honest node.  Also, some details are minor and shouldn’t be broadcast to everyone for approval since they are either trivial or not vitally important.  So while the network needs total consensus on approving the validity of transactions, certain “minor” details occurring on the network allow for the “bumps” to be smoothed out and the core functionality to continue as designed.


Let’s start discussing the five building blocks from above.  Each of these will eventually be inserted into a prototype network known as GoShimmer.  While the name may be questionable, the prototype will allow for the team to build up and tear down as necessary until eventually fitting in all of the design’s puzzle pieces in the just the right fashion.

Node accountability is the first of the building blocks we’ll tackle.  The basic premise of this block is the willingness of nodes participating on the network to accept responsibility for or “own up” to their actions.  Two major scenarios play into the need for node accountability:

  • Rate control – this is important to keep a node or group of nodes from dominating bandwidth or processing power on the network.
  • Voting-based consensus mechanisms – this is important to ensure that, in scenarios requiring voting by nodes, no one is able to vote more than once and any weighting measures that are incorporated into the voting process can be properly executed.

In the upcoming versions of IOTA, the developers hope to introduce global node identities in order to establish accountability for actors on the network.  More than likely, public key cryptography (similar to the idea in Bitcoin) will be used by all nodes to 1) sign certain parts of transactions and 2) identify themselves on every signed message.  This prevents the need for a global database of all participants and allows for future updates of the cryptography – only the user’s public key (and not the signing scheme) is stored in the transaction on the tangle.  It is possible in the future to update the crypto algorithms if needed.

Combating Cyber Attacks

Alongside the need for global identities comes requisite cybersecurity; in this case, the need to combat Sybil attacks is of utmost importance.  Our good friend, Wikipedia, defines a Sybil attack as “an attack wherein a reputation system is subverted by creating multiple identities”.  How does this relate to IOTA?  If global node identities become a requirement for using the network, and if these identities garner trust in the nodes themselves and the network they utilize, a bad actor could simply create a huge number of identities and use them to corrupt the network.  It’s not enough to simply have accounting of who is doing what – we also need some way to ensure authorization of IOTA.  Authorization, by definition, seeks to enable honest users to use the network and block or frustrate the plans of those malicious users.

A key component of the above definition is the need for a reputation system.  While it may sound simple to build a reputation system (just a username and a password, right?), it’s much more difficult to build a decentralized, secure, and scalable system without a centralization scheme.  How can you verify who’s who unless someone is able to check? 


Enter mana.  No, this isn’t the food from Heaven provided to the Israelites in the Old Testament; this is a reputation scheme that allows nodes to earn more mana (i.e., a higher rank) as they contribute to the network.  Rather than a Proof-of-Work (PoW) system like the one accompanying miners in Bitcoin, mana is more similar to a Proof-of-Reputation (PoR) in that a node’s reputation on the network grows as it contributes to the network and holds tokens.  This is a little simplified, but spoiler alert:  we’re going to dive into mana in the next post.  So hold tight, more information is coming!  Until then, check out a few of these links for a bit more information about what we’ve discussed so far:

  • GoShimmer is the testbed that the IOTA Foundation plans to use to implement the Coordicide.
  • Go read the Coordicide white paper for more details on the information we’ve been discussing here.
  • GoShimmer is going live soon and very soon.
  • Mana – falling from the sky?

Thanks so much for reading this post on removing the coordinator; we hope to see you in the next post!