Everscale, Cosmos, and Avalanche provide horizontal scaling via multichain network architecture, meaning that they all give developers the tools needed to create their own blockchains. On each network, the secondary chains have different names: they are called Workchains on Everscale, Zones on Cosmos, and Subnets on Avalanche.
Newly created blockchains can have different virtual machines, configuration parameters and, if necessary, native currencies. In turn, they can interact with other blockchains on the network via cross-chain communication. Coupled together, this kind of architectural construct can accommodate not hundreds of thousands (as it is today), but millions of active users and fully realize the vision of Web3, an internet completely owned and controlled by its users.
TIP
Application-specific blockchains are blockchains that are customized to host a single application. Instead of building a dApp on top of an underlying blockchain, developers build their own blockchain to accommodate their application. This entails building a full-node client, a light-client, and all the necessary interfaces to interact with the nodes.
Setting in motion a decentralized service as a separate chain instead of a set of smart contracts has several fundamental advantages:
- Performance isolation: Isolating the blockchain from the main network ensures that users of the service are not affected by unrelated network activity. This way, the blockchain provides higher performance while it can also connect to other chains in the network in case needed.
- Predictable fees: Fees on main networks are not under the user control. Heightened activity of some applications on the network may increase fees for all. However, with a separate chain fees become predictable and native tokens are no longer needed. You don’t need EVER, ATOM, or AVAX to use application-specific chains.
- Sovereignty: With one-chain blockchains, if there is a bug or if a new feature is needed, the application developers have few possibilities for upgrading the code. That is to say, if the community of the underlying blockchain refuses any changes to the code, changes cannot be made. In contrast, on multi-blockchain platforms such as Everscale, devs are the sole designers of their application-specific blockchains and can make changes when they are needed.
- Security: Developers are not limited by the cryptographic functions made available by underlying Virtual Machines. They can use their own custom cryptography and rely on well-audited crypto libraries.
- Even more security: Developers do not have to worry about potential bugs or exploitable mechanisms in the underlying Virtual Machine. In turn, it makes it easier for them to calibrate and bolster the security of their own application.
Although Everscale, Cosmos and Avalanche are all horizontally scalable, they have significant differences at the protocol level. These include:
- Consensum mechanisms
- Cross-chain communication
- Scalability approaches
The comparison below is intended to help developers, entrepreneurs, researchers and anyone who is considering creating next-gen Web3 solutions. It elucidates the differences between the three architectures and the compromises the developers had to make to deliver these highly competitive platforms.
Consensus mechanisms
Everscale’s Catchain
Everscale’s consensus mechanism is quite similar to PBFT (Practical Byzantine Fault Tolerance) and Cosmos’ Tendermint. They all share the same three-step process (Block approval, Voting, Pre-committing). However, they each have slight variations. Let us briefly examine what differentiates these other protocols from Catchain:
PBFT
The Slot leader is re-elected only if it does not perform well. In comparison, Catchain changes leaders each round in a deterministic fashion.
One round of block voting requires O(n²) messages (where n = number of nodes). Each node sends a message to all others. Catchain uses a special protocol which greatly reduces the number of messages: outgoing messages are sent to a small number of neighbors (5 is the default number) and then those neighbors resend them further.
Cosmos’ Tendermint
Tendermint is the closest algorithm to Catchain. Its main advantage revolves around its very fast block completion. As in Catchain, the proposer node is selected in a round-robin fashion each turn. Tendermint needs only local clocks to compute timeouts. This is in contrast to Catchain, which requires globally synchronous clocks. This may make Catchain vulnerable to “eclipse” attacks. That is, by manipulating NTP messages one may make a node completely out of sync. The blockchain will remain correct but this particular node will not be able to vote and propose its blocks. To tackle this issue, Cosmos implemented a gossip message-propagation algorithm. This algorithm reduces the number of messages to O(n log n) for each vote. Catchain, in turn, has its overlay protocol for broadcasting messages, which does a similar thing.
However, there is a drawback with Tendernint’s fast completion. Namely, since all nodes have to communicate with each other, it has quadratic message passing complexity and can complete only one block at a time.
Avalanche’s Consensus
Avalanche uses its own consensus mechanism. It does not have any similarities with Catchain or Tendermint. Instead of a linear chain, it combines repeated sub-sampling of votes among confirming nodes (Snowball) and transitive voting in a Directed Acyclic Graph (DAG). Since Avalanche consensus has a constant complexity of message transmission, it provides low latency and has a large number of participants in the network. It has probabilistic finality, like the Nakamoto consensus, but it can be customized and has an astronomically low bounce rate.
However, despite its strong points, there is a solid drawback to Avalanche’s consensus. There is no penalty mechanism for validators. That is, malicious or careless validators are not penalized for misconduct. This is in stark contrast to Everscale, where validators have their stakes slashed if they do not conduct themselves in accordance with their duties.
Cross-chain communication
Everscale allows developers to create their own application-specific blockchains called workchains. These workchains can interact with each other via cross-chain communication. All workchain block proofs are posted to the masterchain. The blocks of the masterchain contain the latest block hashes of all other chains in the network. Everscale’s architecture can potentially accommodate up to 232 workchains.
Each workchain, for its part, is split into execution shards called “threads.” Threads contain a chunk of the network’s total number of smart contracts. Validators rotate through the assigned threads and only process the transactions in their threads. The number of threads varies from 1 to 256, depending on network activity. This kind of multithreading approach allows for parallel execution of smart contracts by subgroups of validators that share the same data.
Cosmos allows you to create a distributed network of blockchains called ‘’zones’’ with their own sets of validators. Interaction between these chains is achieved using the Inter-Blockchain Communication (IBC) bridge protocol. Each chain must implement an IBC in order to establish a bridge with other chains. Currently, there are 56 chains supporting IBC, with specializations in areas like DeFi, EVM smart contracts, social networks, privacy and games. Bridges to Ethereum, Bitcoin and others are under development.
Notwithstanding its pros, there is a drawback to this approach. That is, a bridge between blockchains with separate security levels without any security separation mechanism, as in the current Cosmos architecture, is not much different from a basic bridge between any two chains. Thus, without general guarantees of finality, inter-chain interaction has a different level of risk.
Avalanche allows you to create an overlapping network of Confirmers organized in the form of subnets. There are several chains that simultaneously check the main network. Different networks in the same subnet can transfer assets to each other almost instantly. The communication between subnets is currently carried out through bridges, primarily via ChainBridge-Solidity contracts for EVM chains. In fact, the more overlapping confirmations that subnets have with other subnets, the higher security guarantees they can have when communicating with each other. Currently, there are 3 chains in the main network: X-Chain for transfers, P-Chain for staking and C-Chain for smart contracts. Other chains and subnets are in the process of being created. In addition, there is the Avalanche-Ethereum bridge, which operates through a trusted federation.
However, here we end up with the same drawback as in the Cosmos case. There is no security separation mechanism. The communication between subnets is also accomplished via bridges.
Scalability approaches
The total amount of computing work per second that a network can handle depends on the complexity of its virtual machine and the runtime functions used in the network. Everscale, Cosmos, and Avalanche are specialized multi-blockchain networks. They each have the ability to scale horizontally, which means they have no throughput limitations. However, what really matters is how a separate chain can handle periods of peak activity. Everscale, for its part, is the only of the three platforms among the three that has developed a unique and extremely efficient multithreading approach. It allows for parallel execution of smart contracts by subgroups of validators that share the same data. To see how it works, we will once again supply you with the animation that we started this article with. It depicts three cases:
1. The workchain in the middle, under severe pressure, divides into threads to be able to process the increasing number of incoming messages (transactions). The whole process can continue up to 256 threads.
2. The worckchain on the left divides when the pressure increases and comes back to its initial state when the activity slows.
3. The workchain on the right, in turn, works under normal conditions, processing an almost constant number of messages.
With Everscale, any application-specific workchain will be able to process almost any number of transactions in a timely and secure manner.
