hastrup: Anyone wanna comment on this I saw on Reddit?
When NEO or other chains talk about scaling to n TPS, they mean n TPS being processed by that one decentralized chain. Komodo has very little native scalability, it instead adds a lot of different chains together, with a shared state being created every few minutes. E.g, On their scaling presentation, they noted achieving 20k transactions per second with 1024 blockchains. That means each blockchain has a limit of a little under 20 transactions per second. n for Komodo is 20, it’s just 20x*1024. Say NEO hits 100k TPS, then starts 1023 copies. That’s 102,400,000 TPS. Apparently. Would those copies be adequately decentralized? Probably not. So, it’s a neat way around the scalability problem and a good thought experiment, but Komodo’s asset chains don’t scale and lack of decentralization (and in my eyes, that means lacking any value because I can have a faster and less complicated private server using AWS).
Is this a valid point?
jl777: First it is off by an order of magnitude, each chain can do about 200 tx/sec. Second, last time I checked, a decentralized blockchain was decentralized. Third and most importantly, what sense is it to have ALL transactions on a single blockchain? That means all users need to sync all other users data to run a full validation node.
We solve the scalability issue without requiring anybody to have TB of data and GB/sec bandwidth. Surely having a practical solution is much much more important than having everything centralized in a single chain. I flip it back and say that any single chain that tries to handle all transactions will fail due to all the transactions, so clearly things need to be parallelized. I just designed it so it starts parallel, stays parallel and people just need to sync the chain they care about.
Already in the ecosystem there are almost 50 chains. This is an ecosystem capacity of 10,000 tx/sec, yet people only have to run the chain they care about. So the scaling is already happening and it works so well, nobody even realized. Remember the runtime forks are all running the identical executable as KMD itself. It isn’t that big of a stretch to claim the combined tx/sec for all the chains.
Using cross chain proofs allows many chains to have a single total supply if they are in a cluster. Migrations between chains being automatic and without a counterparty. So if you can do N times as many tx/sec, automatically transfer coins between chains without anybody else involved, then aside from the inconvenience of this crosschain transfer we have indeed achieved the combined tx/sec.
The crazy thing is that projects like ETH are combining all the tx into a single chain and then wanting to split it out into smaller portions (sharding) and this is somehow ok? But a solution that starts out as independent chains and stays as independent chains that can do cross chain, that is not? […]
They want to build a single road to handle all traffic. If a city did that, there would be a single highway that is a glorified parking lot. In komodo, we just build more normal roads and yes to combine traffic from multiple roads requires a bit of extra work, but that is much better than trying to shard the main highway.
I like practical solutions, they are much more useful. Just because everybody else is working on the wrong problem to solve, it doesn’t mean that Komodo solution isn’t valid. I just can’t see a non-centralizing way a single chain can scale up in usage. You end up with TB chains needed GB/sec bandwidth, so really other than massive data centers you need to use lite wallets, ie. centralized.
The Komodo solution is the most decentralized possible solution to this problem. The fact that it isn’t some theoretically pure solution isn’t relevant when all the alternatives require unscrambling an omelet into the original eggs or TB+GB/sec centralized monsters that force lite wallets. Don’t compare to some fantasy ideal case when there are ZERO other scalable solutions.