So Sharding vs manychains – scrambling/unscrambling vs crosschain merkleroot magic – unless your transactions have high chain affinity, how are you better off? What makes extreme chain affinity any different to payment relationships vis-à-vis payment channels – is it just a matter of granularity of sharding?
The more parallel chains you use the more you will have to maintain locally, and if your affinity does not match the chains native affinity you will be little better off than with a single chain and a larger block size. Sharding requires coordination protocols for cross-shard transactions, you use merkleroot magic. How are they fundamentally different?
(The comment re “you will be little better off than with a single chain” only applies when you have transaction counts that compare with how many shards/chains you interact with – obviously 1 trade a week is going to be much tighter). The main point is whether your proposal is just a specific sharding implementation where you have more control over chain affinity? And how does it compare with Cosmos, Polkadot, Kadena, Harmony…
In the extreme cases, I am sure you can specify a scenario where sharding vs many chains devolve to being approx the same. However, let us deal with reality: a single cryptokitties dapp basically saturated the Ethereum chain. This cannot be denied. Let us now assume there is a second dapp cryptodoggies from a different vendor. I claim that the overlap between cryptokitties and cryptodoggies will be VERY small. How likely is it that they have to share state? They are different dapps from different vendors.
Now, what if there are hundreds of dapps from hundreds of vendors? Just how much overlap is there between all these dapps? Doing payments is about the only thing where it is shared globally for all things and your logic could apply, even then it is very likely to be ways to automatically have locality of payments.
However, anybody can see without any formal maths that forcing all cryptokitties, cryptodoggies, cryptobirdies… into a single chain and then sharding it cannot be anywhere as efficient as simply having independent chains for each one.
The big difference of Komodo versus all the other many chains solutions is that Komodo doesn’t require vendor lock-in. Maximum independence and each chain is literally its own independent chain that has the option to add dPoW, but not the obligation. There is no per tx fee to pay to a master chain, no deposit needed to be able to make a chain, etc. I argue that the Komodo approach is the most decentralized. What happens in all the other systems if the mainchain goes down?
Also, this is not just theoretical: https://www.dexstats.info/explorers.php
54 independent chains, the total capacity is well in excess of 10,000 tx/sec. and there is not much crosstalk between chains, in fact, atomic swaps can be done for the times where that is needed. Now imagine a single chain that is the combination of all 54 chains. If any chain comes close to saturating the single chain, 53 other chains suffer. Not to mention that the tx fee for everyone goes up.
Sharding is basically that. Combine all things into a single chain, then somehow split it apart and make it all work. I have no idea how they will achieve this, seems very difficult problem to me. So maybe with a magical sharding solution you can have a single virtual chain that is composed of many shards, but what have you achieved? A way for all to pay higher tx fees. Sharding is an attempt to extend the mainchain taxation onto all transactions. Komodo is a tax free zone and we don’t do contortions to be able to enforce a tax on all usage in the ecosystem.
What you are describing is affinity – and it exists in general computing as well – a typical CPU has L1, L2, L3 cache and maintaining the majority of access to a single cache segment within a layer is the answer to orders of magnitude in performance. By implementing multiple chains you have manually specified domains where affinity is strong. This is good, where you can manage it. It works really well when you have a defined community of interaction and hence well defined strong domains but is not so easy with a general payment system such as Bitcoin where the domains are not so easy to define […]
Let’s look into the one global shared case of simple payments, let’s say a national currency to handle all transactions by everyone. I can see creating chains based on geography, regions, cities, towns, where there is a lot of cache effects. Also to create currencies by type of usage, i.e. around product types. In such a case, we can envision thousands of chains for the entire economy, but a single user would only care about a handful. In the event he will be traveling, he would convert to the blockchains in the region he is going. This is similar to converting your fiat into different fiat when you travel. By allowing users to migrate their coins to the chains they use, it automatically creates the caching effect.
I highly doubt you can design an allocation of chains ahead of time (as nobody can predict things as complex as economies), so just spawn more chains if there are not enough in certain areas. Independent chains are like building more roads if the traffic congestion is too bad, sharding is making some magical road that all cars can use, with near infinite capacity. Our approach is proven and requires no magical tech, the sharding requires tech from the future, just we don’t know how far in the future yet.