Need of Multi-chain blockchain network for future advancement in blockchain
The Blockchain Industry is facing scalability problems due to drastic increase in ‘Market Cap’ as well as ‘Number of Users’ which in turn challenged the ‘TPS (Transaction per second)’ and scalability limit of all the existing blockchains.
The fact that scalability is such a massive problem right now across the board doesn’t necessarily mean that there aren’t any viable solution to it, there are numerous Layer-2 solution being developed all utilizing different technologies and ideas to create more efficient networks.
The major problem is implementing these solutions to a network as big as Ethereum which requires a huge team of participants. And even if all these solutions get implemented in Ethereum 2.0 doesn’t necessarily mean that it will give the market a truly decentralized and efficient network.
This major problem and lack of faith in new incoming solutions to existing blockchains leads to creation of multi-chain blockchain networks, all of which set out to solve Ethereum lack of scalability.
In past few years few of the multichain networks like Cosmos, PolkaDot and Avalanche managed to get a lot of traction and recognitions.
Each of these three blockchain took on a different approach to solve same problems i.e., Ethereum lack of scalability and low latency.
In this article we will dig a little deeper to analyze the basic principles behind each one of them.
COSMOS:
Cosmos is a heterogeneous network of many independent parallel blockchains, each powered by classical BFT consensus algorithm like Tendermint.
Cosmos is elegant and clean: We have the main cosmos chain(called the hub), which is where all the cosmos validators are, and we can also add other chains (called “zones”) using the Cosmos SDK, but the validators are independent.
Different zones can interact with each other through IBC which is launched on 18th February 2021, but ultimately the risk is on the users. This kind of approach enables Cosmos to be a low latency network. The hub is unaffected by this but users shouldn’t transact with an insecure zone. Also, the cosmos SDK is very clean which is where cosmos get its edge over other blockchain networks.
There are also some downsides with cosmos, like the hub doesn’t scale to many nodes (its based on TendermintBFT, which is underpowered consensus protocol) and thus becoming a validator is expensive. Its not truly an “Open System”.
Finally, Cosmos hub is bit “primitive” because of its limited functionality. It doesn’t support smart contracts. Furthermore, there’s no $ATOM lock-in, which dilutes Cosmos security. We also don’t need $ATOM to launch Cosmos Zone.
AVALANCHE:
Avalanche is a network of many networks. All of them are called “subnets”, short for “subnetworks” which forms a heterogeneous interoperable network of many blockchains, that takes advantage of the revolutionary Avalanche Consensus protocols to provide a secure, globally distributed, interoperable and trustless framework offering unprecedented decentralization whilst being able to comply with regulatory requirements.
There’s a main network, called the primary subnet. This is a proper, bonafide chain that basically looks like Ethereum: it has smart contracts, transfers, everything. It’s also the most secure subnet, and has almost 700 validators. This is where everything happens.
If user wanted super-fast (1 second latency), incredibly open, permissionless, and high throughput chain that supports Ethereum smart contracts, then this can be done with just using the primary subnet.
However, if the primary subnet doesn’t fit user needs, then Avalanche takes a Cosmos-like approach of letting users to launch another subnet. That subnet can have its own validators (just like Cosmos), but with a critical difference: user need to be a validator of the primary subnet.
Why this requirement? It forces security to maximally pool into the primary subnet as well. We can’t just launch an arbitrary subnet; we also need to “borrow” validators from the primary subnet as well.
I see this as the proper design for a system that wants to optimize for decentralization and *permissionless* security while also enabling other permissioned blockchains to interoperate. To be clear: cross-subnet communication is NOT live on Avalanche yet, just like Cosmos.
So, with Avalanche one will get the Ethereum security experience, with 1 second finality, low complexity, high throughput, and full-spectrum of utilities you’d expect.
POLKADOT:
Polkadot went about trying to solve scaling in blockchains by adopting a “sharding” model. Since Polkadot’s consensus protocol cannot scale to many nodes on a single chain, it tries to get around the limitation by having multiple chains.
These multiple chains are called parachains. However, in a sharded system, where there’s multiple chains, one need a “coordinator” to … well … help coordinate the transactions.
So, Polkadot “scales” by having multiple chains (i.e. parachains each with a few validators). The relay chain is live, but it supports nothing related to actually coordinating parachains! All it supports is $DOT transfers.
Polkadot, in spirit, tries to follow a “shared security model”. This effectively boils down to the following: one bid to be a validator and get assigned to a parachain.
There are the nodes which can become validators of the relay chain, but one have to bid to become a validator. one can’t just make it open (like with Avalanche) because it simply can’t accept that many validators.
But ‘eventually’ when parachains work, then after bidding high enough to become a validator of the relay chain, one will be placed randomly to become a validator of parachains. This is what “shares” security. This is not too dissimilar from ETH2 model.
“Eventually, when parachains work, what happens if a parachain becomes corrupted because there’s not enough nodes?” Same thing that would happen to any other similarly sharded chain, like on ETH2: one can just slash the validators and move on.
However, the funds are lost! The state is irrevocably damaged and the double-spend happened. Entire system rolls back. Q: “How would it be solved?” It won’t! Only way is to ensure that the fraud proofs are caught faster than it takes for Bob to double-spend on exchanges.
The astute reader will immediately realize that all this means is that the time to finality is as long as the minimum time for running a successful arbitrage, which could be very substantial. So in summary, we gets neither security, nor low latency, nor high throughput.
To write this article i have taken help from following blogs listed below:
THANK YOU!