My take on IOTA Economic Clustering
As there has been a lot of discussions and confusion about EC, I want to share my thoughts on it. This is an idea about how parts of Economic Clustering could turn out.
The difference between my version of EC and everything else about EC that has been mentioned yet is that I am blatantly assuming, that Tangles from different clusters can be merged and split. Otherwise, I’m only trying to explain, visualize and explore the different concepts and functions of EC that CfB talked about in his article.
Whenever you see a block quote like this without any context, I’m quoting the article. Otherwise, the source will be declared above or below the quote.
The longest chain wins
What is a cluster?
In my understanding, a single cluster is a set of Iota nodes that send and receive transactions from within their cluster and their neighboring clusters.
Snapshots and Milestones
In order to understand this explanation of Economic Clustering, one has to first grasp the concept of Snapshots, Milestones and maybe Subtangles. I’ll be using those a lot so I am going to assume, that you have a little knowledge about those and other Iota Basics. If you don’t, you should check out this IOTA Stack Exchange question and related ones.
A milestone is a bundle that consists of two transactions. The signature message fragment of these transactions contains a signature by the COO. Like every other transaction, a milestone too references other transactions. Milestones can be seen as a transactions that have infinite weight.
For the sake of simplicity, in all illustrations and text, I will refer to milestones as single transactions that reference one branch and one trunk transaction.
Snapshots begin the Genesis transaction (all 9s transaction) and end with a milestone with a certain index number.
Here is a picture of an imaginary Tangle with way less transaction then the actual Tangle, a very neat structure, only the first three Trytes of the transaction hash visible and transactions that have hashes which conveniently match their purpose. MSA is the first milestone, MSB is the second one and so on. T9A is a transaction, T9B is a transaction and so on.
Note, that these Tangles are not of two clusters, they are in one cluster which had a snapshot after milestone MSD.
This is like the current Tangle and the fitting Fullnode map looks like this (square = full node, grey square = coordinator):
A Subtangle is a Tangle that splits off from another one like this:
The nodes that produce the Subtangles start off by being connected to the rest of the network, then disconnect and keep producing transactions with slightly modified tip selection rules (i.e. start the random walk at first yellow transaction instead of cluster0 milestones).
If the Subtangle doesn’t get too long, i.e. if the yellow nodes only stay disconnected for a short time, the Tangles can be merged again (even with the current full node implementation). If the Subtangle is too old, all transactions in it will be considered “lazy” and will never be confirmed under normal circumstances. This is exactly where CfB’s hypothesis comes in.
[…] whenever math rules and economic laws conflict to each other the latter always win.
EC hypothesis states that the ledger state of a cryptocurrency is determined by the participants of the economic cluster who try to maximize their wealth even if breaking “Longest chain wins” rule is required.
Although there is no way, programmatically according to the IOTA Protocol, that the lazy Subtangle merges with the main Tangle, they will merge if this makes sense in the eyes of the economic participants in IOTA. In short, people will change the mathematical rules, if it benefits them economically.
EC hypothesis in the past in IOTA
EC is not even implemented yet, so what do I mean by “in the past”? Well, we haven’t seen real EC yet, but there is one example, that behaved very similar to EC. Remember SIDETANGLE9ROCKS? There was a very big, old and apparently lazy Subtangle. One day, people tried to “stitch” the Subtangle to the main Tangle which resulted in several IRI nodes suspending. This led to a “bug fix” in the IRI code which is technically (or at least comparable to) changing the mathematical rules of the IOTA Protocol in favor of the participants.
Subtangle surviving Snapshot
Under normal circumstances, the scenario depicted above would never happen. But it could happen if we keep EC hypothesis in mind:
It’s 2020*. Some crazy person decides to go to Mars and bring Iota-powered EVs, Iota-powered rockets, Iota-powered solar panels and Iota-powered tunneling machines with them. Since Mars and Earth are not very close to each other, Mars nodes cannot communicate with Earth nodes, therefore Mars nodes create a Subtangle. Now the worst thing happens: During their stay on Mars, the Earth nodes make a snapshot and as if it weren’t bad enough, due to a software bug in the digital twin system, a Mars solar panel spends 2 MIOTA from the same address as another solar panel on Earth. Since everyone owns a part of the person’s companies, the economic participants decide unanimously to allow the 2 MIOTA to be minted and the pre-snapshot Subtangle to be merged with the main Tangle. Otherwise, the whole Subtangle would be invalid.
*Not yet based on a true story
These two clusters, clusterM and cluster0, are not connected, i.e. not neighbored, to each other. They start off by being in the same cluster, then split completely, then merge completely. Another viable solution for this problem would be for the two clusters to not merge again but to just be neighbored and to slowly transfer the Iotas from clusterM to cluster0. To see how this could be done, see section Clusterhopping and Savely disconnecting Tangles.
Iotas can be created out of thin air. A cluster may emerge and offer some services, the nodes of this cluster can “print” iotas and implicitly/explicitly promise to accept them later in exchange for their services. The “counterfeit” iotas will likely not be accepted by the other clusters unless the new cluster is very significant from economic point of view. Anyway, in this case it could just create its own cryptocurrency.
Stable USD Iother
This is an example of a company Iother that prints their own tokens. The users pay exactly $0.001 in exchange for exactly 1 token on the new clusterT, a T-token. The company Iother promises, they store the USD and every user who wants to get rid of their clusterT tokens can exchange them at any point of time for $0.001 on their website thus creating a stable currency.
This clusterT will never merge or be neighbored to cluster0 because the T-tokens and 0-tokens (=Iotas) have a different value for a different reason. Cluster0 sees T-tokens, if it does see them, as “counterfeit” tokens. ClusterT sees 0-tokens as “counterfeit” tokens or it doesn’t see them at all.
We are very likely going to see something very similar to this idea of “Iother” in the future. It’s a centralized but very simple concept of a Stablecoin. Iother could have their own Coordinator which would probably be centralized since one has to trust the company anyway to use the currency.
Anyway, in this case it could just create its own cryptocurrency.
Iother would just be its own Cryptocurrency that happens to use the same technology as Iota.
The “counterfeit” iotas will likely not be accepted by the other clusters unless the new cluster is very significant from economic point of view.
This idea may be a little more far-fetched than the previous one, but it portrays one of those economically very significant clusters.
Imagine two big companies, let’s call them “Coyote” and “Vanward Group”, control the mobility economy. Both have their own token system to ensure entities can pay for fuel, parking space and mobility as a service. Vanward has always been using Iota tokens from the beginning and has already established a sound infrastructure throughout Europe. Coyote, on the other hand, built their own system which was blockchain-based at first. They switched to the tangle-based solution later, when it was needed and they distributed the new “tangle” tokens to the previous “blockchain” token holders according to their stake. Coyote also built up a strong infrastructure, but in Asia. The Coyote tokens became so strong in Asia that they were also used for other sectors in IoT than mobility just like Iota in Europe.
With this setup, it was difficult for Coyote vehicle owners to operate in Europe and for Vanward vehicle owners to operate in Asia. To solve this problem and because both companies and their customers strove to achieve better interoperability as they expanded to America, they declared each others cluster “significant from economic point of view.” Since both tokens had almost the exact same value, the logical conclusion was: From now on, the clusters are neighbored (or neighbors of neighbors of neighbors…) and both tokens can be spent on both networks. This increased the total supply of Iota tokens though it also increased the market capitalization.
The relation between the red and white cluster is the same as the relation between the green and white cluster from the Iother example. The two Tangles were completely disconnected as if they were different currencies. The participants of the red and white economy acknowledged that each other’s tokens have the same value. Therefore they can now be interspent. The transition theoretically doesn’t have to be done with a Snapshot however, it would be a convenient time to make one.
Further down, I’ll refer to a cluster of clusters where tokens can be interspent (e.g. the orange and white clusters) as a universe. The red tokens were in a different universe, thus you couldn’t spend them in the Iota universe at all. Once the universes merged (without the individual clusters or Tangles merging), this was possible. It is still difficult, if the token is far away from the place (symbolic not necessarily geographic) you want to spend it. For more information on this, take a look at section Clusterhopping.
The main thing we want to achieve with Economic Clustering is scalability i.e., not every node has to know about and process every transaction. To achieve this, we have to make special gossiping rules i.e. which transactions are sent by which nodes to which neighbors?
This is our universe:
Every color represents a cluster. Thin lines represent cluster neighborhood. Thick lines represent node neighborhood.
When a cluster0 transaction gets published, obviously all nodes in cluster0 receive it. But also all nodes* in neighboring clusters (cluster1, cluster2, and cluster4 in this case) store and broadcast the transaction.
* There will likely be different kinds of nodes, ones that store transactions of neighboring clusters and ones that don’t.
All nodes with a blue line around them store relevant information about white Tangle. Relevant information means value transactions and their inclusion states. Zero value transactions are only important to neighboring clusters in the sense of the weight (inclusion) they add to a value transaction.
TLDR: Neighboring clusters need to know about each other’s address balances, not necessarily anything else.
You have Iotas in the purple cluster (cluster1) and want to spend them in the red one (cluster3). To do that, you would first spend them in cluster1 to your own address. Now, cluster0 and cluster2 also know about the Iotas (if they didn’t already know about it before). Next, you would spend them in cluster2. Now the red cluster also knows about the Iotas. To be on the safe side, you should send them to yourself in the red cluster as well. This will make sure your Iotas are indeed now in cluster3.
Safely disconnecting Tangles
If we just disconnect and split a Tangle into several clusters, double spend transactions are possible. This is why Iotas should only ever exist in one cluster and all of its neighbors should know about it. Once funds get moved in a neighboring cluster, the current cluster has to notify all of its neighboring clusters to forget them. Even then we would still have a problem with double spend attempts simultaneously on neighboring clusters. There are several possible solutions to those problems. I don’t dare to come up with the ideal one.
One idea would be to use a currently unused field in the bundle data, e.g. the so called legacy tag, to identify the cluster in which you want the transfer to be executed but I’ve also heard about other intended use cases for this field.
Iotas can disappear. If you haven’t been touching your wallet for a long time then there may be very few nodes remembering your balance left. This is not a serious problem if inflow rate of new nodes is low or if you refresh the balance often (by spending the iotas back to yourself).
Imagine, you have 10 MIOTAs on address ADR and all of the nodes in the network know about those.
Because all nodes in the network know about the balance, it is guaranteed, that their tip selection algorithm will evaluate transactions spending from ADR as valid ones.
The next thing that happens is, that one node dies and two new ones join the cluster.
The two new nodes don’t know about any balance on ADR. Their tip selection algorithm will evaluate transactions spending from ADR as invalid. But since we still have four nodes which would select your tip, the weight on your transaction would still increase. At some point, even the new nodes acknowledge that the transaction is valid because they realize that the majority of the network deems it as such.
If you don’t regularly refresh your balance and a lot of new nodes join the cluster, your Iotas could be forgotten by the network.
There is only one node that remembers your balance. Its tip selection will still evaluate a transaction spending from ADR as valid, but the weight will be too little for it to be accepted by the new nodes which are now the majority.
The picture drawn by CfB in my head may actually be different than the picture drawn by CfB in his head. Keep this in mind.