The manychains universe or how to solve unlimited scaling with existing technology
The blockchain scaling issue seems to have a lot of really smart people trying solve a lot of really hard problems. In my life, I have met many very smart people, much smarter than me and I learned that in order to be able to do something useful, I needed to be a bit creative. Instead of trying to solve the same problem as everybody else, I try to solve a much simpler problem that gets the same job done. Also, I work very hard to compensate for my shortcomings.
Over the years I have gained a lot of practical experience and even though I might not be able to make fancy math proofs that somehow prove a problem is mathematically solvable, I have found that getting things actually working to be much more practical. Even with a fancy math proof, you still need to implement it properly.
Anyway, let us think about the blockchain scaling problem for a bit. The main issue is that we want blockchains to be able to handle “real world” level of volumes. Nobody knows exactly how much that is, but it is clearly more than 7 transactions per second. That much is obvious. How can we increase the throughput?
The two most obvious ways are to increase the blocksize and to reduce the blocktime. A more efficient way to encode a transaction would help a bit more. Let us assume we are not bogged down in silly politics that makes us take 4 years to not double the blocksize! With current day internet, blocktimes of about 1 minute and blocksizes of 8MB seem to be about the limits. Certainly the high bandwidth nodes can do more, but 8MB per minute to just keep up is already fully saturating a 128kbps connection, possibly in both directions. What that means is that we cant both have higher throughput and also have a lot of nodes that can keep up if we keep increasing the blocksize and reduce the blocktime.
Assuming 256 bytes per transaction, 8MB gives us about 500 tx/sec. Almost 2 orders of magnitude increase! By maximizing payments per transaction we can likely push things to a few thousand payments/sec. But really, to go beyond that would require some significant new technology, which by its nature wouldnt have much field testing.
Lets take a step back and think of this problem in more common sense terms. Lets imagine we have a single road going through a small town. This road can handle 7 cars per second, but it isnt a constant 7 cars per second. It actually has a stoplight on a 10 minute cycle. Thousands of cars wait for the red light to turn green, only the cars that were in line the moment the light turns green are allowed to continue onward. This is using the BTC chain characteristics of 10 minute blocks.
Now, you can imagine that if we tried to make the light go from red to green to red in one second, it would not be practical to get all the cars to coordinate. Lets assume we can speed up the cycle to once per minute and further we can increase the size of the road 8x. We are now pushing the limits of what is possible, going any faster is just not realistic.
We have various sharding proposals, which replicate the existing system N ways and try to coordinate all the shards to the main chain. Unlike the road example, in the blockchain, things need to be cryptographically precise and there are very tricky issues like double spends that need to be protected against. To handle this very complex mechanisms are being proposed that to me seem nearly impossible to solve reliably without losing security.
Going back to the road example, it would be somewhat like trying to get higher capacity by enclosing the road in a tube, making it a vacuum so there is no air resistance and equip every car with maglev tech so they can go 10x faster. Now we can finally approach the required levels of 10,000+ tx/sec. But wait, remember the bandwidth problem? How can any normal node keep up with such a flood? also how is all this vacuum maglev magic actually work and how do you get cars into and out of this vacuum sealed tube?
Solving the problem without changing it, leads to impractical science fiction like “solutions” that doesnt really solve the issue of how nodes can keep up with the flood of data. Does this mean that this is just a problem ahead of its time? We need to wait for moores law to double and double and double the processing, capacity and bandwidth?
This is why I like to change the problem. I asked myself why not just make a bunch of independent roads that dont need to be directly coordinated with each other? Let each one operate at its own speed and set things up so most of the time all transactions are on the same chain for a specific user, but have a way for transactions to be done with other chains. Each user would only connect to blockchains they care about, only have to sync the data for chains they care about. No single node has to sync all chains, yet all the chains are decentralized, all the chains operate using current tech of the few hundred tx/sec.
The road analogy is that instead of having just a single road that goes through town, make 100 normal roads to get 100x the capacity. It doesnt take a genius to realize that 100 roads has 100x the capacity of one road and in fact this is what cities do, if they need more roads, they build them.
From this simple solution to the blockchain scaling problem, it turned out that by clever usage of merkleroots, the crosschain transactions could be coordinated cryptographically, without having the chains having to be in lockstep with each other. The komodo deamon is able to create a runtime fork based on dozens of -ac parameters and a very large range of blockchain behaviors can be created without any source code changes.
All of these chains are ready to be plugged into the crosschain architecture along with the dPoW security, but that is for another post.
Having all transactions using just a single chain, creates a single point of failure and then to shard it after it was combined is like unscrambling an omelette. The manychains approach doesnt need any unscrambling of eggs, as all the independent chains are already fully separated.
Just another way komodo is ahead of the rest.
