Economic Clustering and need for (Dezentralized) Coordinators?

Question

In CfB's recent blog post on Economic Clustering and IOTA, he looks at a possible future of IOTA and envisions two different types of IOTA clusters:

• Cluster 0: A a set of Full Nodes that are interchanging all transactions (just as today in the main net). Transaction are secured by means of a "decentralized coordinator".
• Further clusters: A set of Full Nodes in a spatially limited area, e.g. a town, with each Full Node processing all transactions from the town and from neighboring clusters (spatially seen), i.e. neighborhood towns. A few of these clusters, but definitely not all, may have a link to Cluster 0. Given this structure, IOTAs can be interchanged within spatially limited areas (= economic clusters), however, they cannot be interchanged between clusters that are separated by having multiple clusters in-between.

Based on this, I have three questions regarding the implementation of CfB's vision on Economic Clustering:

1. Functionality of distributed coordinator in Cluster 0: Would the "distributed coordinator" in Cluster 0 exist of multiple instances of basically the same Coo we are having today (in terms of its task when looking at the Coo as black box) which are run by different companies that are mutually trusting each other (as they can track what the other Coos are doing)?
2. Need of coordinator(s) in other clusters: In Cluster 0, IOTA transactions will be secured as of today in the main net (just by using the "distributed coordinator" instead of the central one we are having today). In the other clusters, IOTAs could be generated out of thin air, e.g. in exchange for real money, as long as people trust the issuing company. For example, a electric vehicle charging station operator could provide the service of charging electric vehicles in a certain cluster (i.e. a certain spatially limited area), and therefore issue its own IOTAs (which could be seen as a form of colored tokens) in exchange for EUR. Outside of this cluster, these IOTAs will not be worth anything as the issuing party is only guaranteeing a counter value within the cluster. Given the nature of the Tangle, we still would need a coordinator for this cluster, is this true?
3. Benefit of the Tangle when relying on coordinators: In both cases, we still need one or multiple coordinators (which we may call a "decentralized coordinator"). However, also when using a decentralized coordinator, we rely on some centralized instances. Given this fact, what are the benefit of using a DAG/the Tangle? Why not having a database table for managing all transactions and hence providing a balance per address? This database table could also be operated by different companies and each company could still say "yes, I approve that the transaction is valid" resulting in the same result: a balance per address, accepted by multiple companies. As we are not getting rid of the coordinators that are operated by some (few) central instances, what exactly are the major pros and cons of relying on the DAG structure?

Answer 1

Since I am not CfB, I cannot guarantee that my answer aligns 100% with his vision but this is my understanding of it:

1. Functionality of distributed coordinator in Cluster 0

Yes, exactly. The entities don't have to be companies, but it's very likely, that they will be.

2. Need of coordinator(s) in other clusters

I don't know if Cluster 0 will need a Coordinator forever. If the honest transaction rate reaches a certain point, I think we could get rid of it entirely, but with current PoW (Proof of Work) and difficulty that point is just too high. Maybe Network bound PoW will change something about this but we know hardly anything about it.

For other clusters with "colored tokens", as you called them, we definitely need a Coordinator because/if the transaction rate is significantly lower.

3. Benefit of the Tangle structure when relying on coordinators

1. Permissionless
   We don't need an API key or similar to send and receive Iotas. The only cost is the PoW. This can of course also be seen as a disadvantage since we have to do PoW.

2. Ease of switching
   It's easy to build an automated check into every full node similar to:

   If Coordinator A tries something malicious or stops working, don't trust it anymore. Trust Fallback Coordinator B instead. If Coordinator B tries something malicious or stops working, don't trust it anymore. Rely on weight only instead.

   Since the Coordinator is not a central instance, even if it fails to do what it is supposed to, the network can continue working.

3. We need a HAPPENED BEFORE relation anyway
   The Tangle has a very clear structure when it comes to which transaction happened before which transaction. If TXA is directly or indirectly referenced by TXB, we know that TXA→TXB. Therefore we also know that a Milestone MS9 confirms all transactions that happened before it.
4. Missing transactions
   We know exactly, if we are missing a transaction or if our Tangle is solid because of the references. If one of our transactions points to TXC and we don't have a TXC in our database, we know that we have to request it from our neighbors.

Answer 2

Functionality of distributed coordinator in Cluster 0

A distributed coordinator won't be the same as the centralized we know today. It is explain in the article :

This software (i.e. distributed coo) does only one thing — it signals that a particular actor has seen certain transactions and will accept them as legitimate ones with some probability.

Need of coordinator(s) in other clusters

I don't see any reason to not have a distributed coordinator in other cluster (maybe we will see different clusters with different rules : centralized coo, distributed coo, permissioned cluster,... ?)

Benefit of the Tangle when relying on coordinators

Distributed CoordinatorS . The S is important, it implies multiple entities, hopefully, in a permissionless tangle: anyone can run it. So it achieve full decentralization of the network. And it don't relies on centralized instances. The term distributed coordinator shouldn't be assimilate to centralized entity ... it's instead a decentralized component.