Jump Crypto: A Detailed Analysis of the Characteristics and Advantages/Disadvantages of Five Major Multi-Chain Architectures, Including Cosmos and Avalanche
Original Title: 《Flavors of Standalone Multichain Architecture》
Original Author: Shanav K Mehta, Jump Crypto
Compiled by: Guo Qianwen, Chain Catcher
Overview
For a long time, scalability has been a widely discussed topic in the field. Discussions surrounding monolithic blockchains versus modular blockchains, as well as horizontal versus vertical scaling, have long been a focal point of community exchanges.
A popular viewpoint has thus emerged—establishing dedicated execution environments or even finality tools for specific applications or use cases. This idea specifically refers to the separation and optimization of consensus and computation based on the security and speed requirements of each product and application, which theoretically can alleviate the load on a single underlying blockchain and enhance its performance. However, this approach has long been constrained by one point: the infrastructure required to ensure interoperability under this architecture is extremely complex.
In recent years, we have made significant progress in addressing these challenges in various ways. More importantly, in the past few months, several communication layers for independent multichain environments have gone live, which can be said to be the most critical piece of this "puzzle." Meanwhile, in the past few weeks, more L1/L2 blockchains have announced architectural adjustments to provide out-of-the-box infrastructure for blockchains tailored to specific applications, once again reigniting relevant discussions.
In this article, we will examine in detail the various forms of architecture developed in pursuit of this vision and compare their trade-offs in terms of shared consensus, capacity, and interoperability. Specifically, we will study five independent multichain architectures: Polkadot, Cosmos, Avalanche, Polygon Supernets, and Binance BAS.
Note: This article primarily focuses on independent multichain infrastructure, where blockchains for specific applications share a validator set or consensus algorithm.
Comparison Criteria
The degree of connectivity in independent multichain ecosystems varies, ranging from sharing developer toolkits to sharing validator sets, finality tools, and states. Objectively, each approach has its advantages, but all optimize to some extent for the maintenance of shared security and speed/capacity.
In this article, we compare these ecosystems through five key parameters.
1. Consensus
All ecosystems meet basic requirements regarding witch attack defenses, finality achievement times, etc., so there is essentially no optimal consensus mechanism. However, it is worth comparing: 1) the specific types of consensus models, 2) whether each chain has a shared or independent consensus mechanism, and 3) whether token incentives are shared or independent. Chains may use the same consensus mechanism (such as Tendermint BFT), but the validators of each chain are incentivized by their own independent tokens, and vice versa, depending on the parameters of the ecosystem. A shared consensus mechanism and token incentives mean that the underlying layer can provide greater security guarantees, while choosing independence means greater design flexibility.
2. Finality/State
In these ecosystems, some chains maintain some form of independent state, while others achieve finality at an overall level. This provides 1) greater security and 2) more comprehensive interoperability. However, this also brings trade-offs in capacity limitations; if the number of modular blockchains exceeds a certain threshold, the process of achieving finality will slow significantly.
3. Shared Validator Set/Node Autonomy
In addition to shared consensus mechanisms, individual blockchains can also share validator sets. In the examples below, the range of shared validators involves a single validator set across all chains, to multiple validator sets (each of which provides consensus for part rather than all underlying blockchains), to mutually exclusive validator sets for each underlying blockchain. Because the marginal risk of each new blockchain is reduced, shared validator sets provide centralized security guarantees, but large-scale trade-offs on nodes can adversely affect all chains secured by the validated set. The ideal state for this parameter is a sufficiently distributed single validator set that provides shared security guarantees for a large number of chains. On the other hand, its most risky state is a single validator set with a small number of centralized nodes.
4. Interoperability Architecture
Most projects discussed in this article adopt a "burn and mint" or "lock and mint" bridging architecture. The distinctions among these systems are: 1) routing, i.e., whether messages and tokens are routed through a single validator set that observes some global state, or whether each route is independent; 2) whether the validator sets for these acquisition links are shared by the ecosystem or outsourced to third-party entities. The closer the ecosystem is to a state of independent routing and third-party validator outsourcing, the less we recommend using this underlying ecosystem for new chain launches; it is better to connect directly with a general-purpose third-party bridge for independent launches.
5. Speed and Capacity
Speed and capacity are largely characterized by the design choices mentioned above, which can be measured by the time taken to reach the final state and the maximum number of chains an ecosystem can support. For example, a structure with shared finality and a single global state can only accommodate a certain number of chains, thus significantly slowing the time to finality, which is a trade-off made for greater security guarantees.
Below is a macro overview of these five ecosystems based on these parameters. In the remainder of the article, we will break down each of these ecosystems and discuss the pros and cons of each design choice.
I. Polkadot Parachains
Overview
Polkadot emerged early in the field, with the aim of supporting specific application blockchains that share a single global state. Under the Polkadot architecture, specific application blockchains (parachains) share computational and consensus resources with the underlying blockchain (known as the relay chain), whose main function is to maintain a unified global state.
Consensus, Finality, and Validator Set
Polkadot operates a proposed proof-of-stake consensus at the relay chain level. In this architecture, there are three types of nodes.
Nominators:
Nominators select trustworthy validators and stake some of their DOT with them. They share in the rewards of the validators, but they can also be penalized (slashed) if the validators engage in malicious activities.
Validators:
Validators on the relay chain participate in block production and consensus. Unlike independent monolithic blockchains, relay chain validators must reach consensus on the state of multiple individual chains with separate transactions.
Collators:
Collators collect transactions on specific parachains and propose a candidate block and a state transition proof to the relay chain validators. Each collator maintains a node on both the relay chain and its working parachain. They accumulate transactions on their parachain, create unsealed blocks, and provide them along with state transition proofs to one or more relay chain validators. The block does not achieve finality until consensus is reached among the relay chain validators.
Although parachains share a global state, they are free to choose the specific consensus algorithm (GRANDPA / Tendermint / traditional pBFT, etc.) they operate under to achieve parachain-level validation before settling on the relay chain (Polkadot / Kusama).
A unique aspect of Polkadot's consensus is that it separates block production from block finality, operating under a hybrid consensus framework.
Block Production Mechanism: BABE (Blind Assignment for Block Extension)
Based on the size of the staked value and Polkadot's random rotation, validators are selected to order and produce blocks for 6-second slots. Under this random selection, each slot may ultimately have one, multiple, or zero block production candidates. When multiple validators are selected for the same slot, block production becomes competitive. In the absence of selected validators, a secondary rotation selection occurs. Once a block is produced, the message is transmitted to other validators.
Finality Tool: GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement)
Once a relay chain block is transmitted to other parts of the network, it requires at least 2/3 majority consent to be added to the chain. However, the uniqueness of GRANDPA lies in its agreement on the chain rather than on blocks. This means that when it confirms a chain containing a particular block, all prior blocks of that block are immediately achieved finality, which differs from the traditional process of confirming one block at a time.
Ultimately, Polkadot adopts the highest security consensus method while providing a certain degree of flexibility for parachains. Each parachain can make design decisions at the chain level "consensus" and propose blocks to the relay chain, but finality is only achieved on the Polkadot relay chain, guaranteed by a group of validators who must stake DOT tokens to participate. Polkadot has about 100 active validators (up to 1000), with each validator having a maximum of 256 nominators. Its shared validator set sacrifices some design flexibility to ensure higher security guarantees for parachain projects. The centralized consensus at the relay chain level can provide higher shared security guarantees but also sacrifices some performance: the number of parachains is fixed, and beyond that number, the time to finality will significantly slow down.
Interoperability
Under this architecture, these components, particularly the relay chain, communicate with each other through Polkadot's unique communication standard XCM.
On a macro level, all messages in Polkadot's cross-chain messaging system are transmitted through the relay chain, thus extending its security. There are two types of messages that can be transmitted:
- Upward messages (UMP): Messages from a parachain to the relay chain
- Downward messages (DMP): Messages from the relay chain to one of the parachains.
- Incoming messages to the parachain are referred to as ingress, while outgoing messages are referred to as egress.
Here is the process of a message being sent from parachain A to parachain B:
- Parachain A publishes UMP, which is transmitted to all validator nodes on the relay chain as part of an egress batch.
- Each time a collator node on parachain B submits a new block candidate to the relay chain, it searches for new ingress messages.
- The ingress message is added to the processing queue of parachain B and will be transmitted to the validator nodes in the next block proposal.
- During the asset transfer process, the underlying asset is burned on blockchain A and reissued on blockchain B.
Given that all messages must pass through a single validator observing the global state (shared with the Polkadot relay chain), and all chains are built on the same standard, this makes the "burn and mint" model efficient. Polkadot's interoperability layer is one of the most effective and secure layers in the field. Therefore, it is recommended to build projects within its ecosystem, as XCM can be used to seamlessly connect with existing parachains and leverage these network effects for launch.
Speed and Capacity
The cost of having higher shared security guarantees is that the time to finality will be significantly slowed once the number of parachains reaches a certain value. In Polkadot, the estimated number of parachains is around 100, which is rented for use, aimed at reducing the impact of this limitation. Projects can bid for the use of parachain slots through DOT staking with community support; once the slot expires, they must re-bid with other participants to retain the slot. This serves as a default management mechanism for projects with the most activity and community support, partially circumventing capacity limitation issues, but it also means that the threshold for new projects to join this ecosystem is relatively high.
II. Cosmos
Overview
Cosmos SDK is a set of out-of-the-box tools for consensus and execution that allows anyone to create their own PoA/PoS blockchain. Unlike other ecosystems discussed in this article, Cosmos is built on a significant premise: the flexibility, sovereignty, and performance of smart contract-based virtual machines are limited. Therefore, Cosmos does not aim to create a single virtual machine capable of running multiple applications but rather encourages and facilitates the creation of separate blockchains for each use case. In this structure, application developers can operate flexibly around specific architectures, languages, etc., and achieve interoperability through Cosmos's multichain communication layer, IBC. A single blockchain is referred to as a zone, while the connecting modules are referred to as hubs.
Consensus, Finality, and Validator Set
In the Cosmos ecosystem, unlike Polkadot, each specific application blockchain maintains its independent state and achieves independent finality on each block. Through Cosmos SDK, developers only need to define a state machine (i.e., application) and can rely on Cosmos's Tendermint core (a shared software layer) to drive consensus and network connectivity. Tendermint operates a BFT-based consensus algorithm, and each independent zone's validators can use this algorithm to facilitate state transitions and maintain independent states. In each blockchain/zone, a validator is randomly selected in each epoch to propose the next block; if more than 2/3 of the validators prove its validity, the block can be considered valid. The validator set and specific incentive designs can be defined at the state machine/application level.
Tendermint is a shared software layer, and each blockchain/zone must connect to it through a dedicated interface called ABCI (Application Blockchain Interface). Transactions from various zones are transmitted to the Tendermint core as transaction bytes via ABCI, and validators finalize these bytes and return code to the state machine via ABCI to prove the validity of these transactions.
Each zone in the Cosmos ecosystem is connected to a hub, which is considered a router connecting multiple zones. Currently, the Cosmos Hub is the first hub in the Cosmos ecosystem, and most early high-value zones are connected to it. Through the Cosmos Hub, connected zones can communicate with each other. The specific architecture for information exchange is called Inter-Blockchain Communication, or IBC for short. The IBC client is a lightweight client that tracks the consensus state of each chain and necessary proofs to correctly verify proofs based on the client's consensus state.
Under the IBC architecture, when token transfers begin, each chain receives header information from the other to track the other’s validator set. Then, the sending address on the source chain sends a coin data packet, which is recorded by the hub. The hub validators must reach consensus on the validity of the transaction and lock these tokens in a contract on the source chain. The hub then publishes proof at the destination, proposing to mint wrapped tokens of these locked assets on the destination chain. Validators on the destination chain then match the proof with the source chain's header and subsequently approve this function in the next block to mint the wrapped assets on the destination chain. If the above actions do not occur, the locked assets on the source chain will be returned to the sender's address. The wrapped assets are then destroyed on the destination chain, allowing the underlying assets on the source chain to be unlocked.
In Cosmos, routing is managed by a single, sufficiently distributed validator set that observes the state of all blockchains, and most of these validators are shared with the blockchains, thus providing adequate security guarantees around cross-zone messaging. This also provides ample reason to build within the Cosmos ecosystem, as the failure points are centralized and sufficiently decentralized.
Speed and Capacity
Since finality is not centralized to a single chain, Cosmos theoretically can have an unlimited number of zones and hubs. Therefore, unlike Polkadot, it is effortless to establish new chains for new projects. The trade-off here is offloading some security guarantees to the zones (allowing zones to design their incentive mechanisms and attract validators) in exchange for greater design flexibility and higher capacity to accommodate more individual blockchains.
III. Avalanche Subnets
Overview
Avalanche is a blockchain ecosystem validated by multiple groups of nodes (called subnets). Subnets can freely choose their consensus mechanisms, including Avalanche's novel consensus variant based on repeated random subsampling. Each blockchain within a subnet shares computational and consensus resources but ultimately maintains its own state, with no global shared state.
Consensus, Finality, and Validator Set
To better understand its architecture, we must consider three key components:
Avalanche Consensus
This refers to repeated random subsampling. Avalanche consensus is built on the Snowball algorithm, which uses repeated random subsampling to achieve consensus. In this system, each node randomly queries k neighboring nodes to determine whether a transaction is correct. This process is repeated until a certain preset quorum x is reached, and nodes achieve consensus on the validity of the transaction with a high degree of confidence (at least as low as the probability of hash collisions in Bitcoin).
Avalanche Consensus vs. Snowman Consensus
Snowman and Avalanche are the two main PoS-based consensus models in the Avalanche ecosystem, utilizing repeated random subsampling. The distinction between the two is that Avalanche employs a DAG (Directed Acyclic Graph) architecture, while Snowman is designed for linear blockchains. The key difference between DAG-based systems and linear blockchains is that finality in linear blockchains is ordered, whereas in DAG-based systems, its state is closer to a transaction network with unordered finality. Blockchains within the Avalanche ecosystem can choose to use either of the two consensus models or adopt their own models.
Subnets
Subnets are collections of validators that can provide consensus on some blockchains within the Avalanche framework. Each blockchain has a subnet, but each subnet can validate multiple blockchains. Because each blockchain is independently validated, the global state is non-linear between blockchains, so there is no shared security between them.
Virtual Machine (VM)
The virtual machine determines the application-level logic of the blockchain. Avalanche aims to provide each blockchain with a range of operation codes to choose from for handling and transforming states, rather than just providing a single set of operation codes. Current options include subnet EVM (Ethereum VM built for subnets), AvalancheVM (DAG chain), SpacesVM (a key-value storage virtual machine), and BlobVM (binary data storage virtual machine). Additionally, projects can freely implement their custom virtual machines.
The premise of the Avalanche architecture is that these three components fit into a modular framework that can scale super-linearly as subnets/validators grow.
In its current form, Avalanche has a main network guaranteed by all participating Avalanche validators, under which there are three blockchains.
- P-Chain: A linear blockchain based on Snowman consensus, used for creating validators, adding delegators, creating subnets, etc.
- X-Chain: A DAG-based blockchain using Avalanche consensus for asset exchanges.
- C-Chain: A linear blockchain based on Snowman consensus running EVM for general smart contracts.
These various combinations of validators can then form subnets to validate incrementally participating blockchains.
Overall, each blockchain in the Avalanche ecosystem maintains its own state and can independently choose its 1) consensus mechanism, 2) validator set, and 3) incentive design. Blockchains within the same subnet benefit from higher shared security guarantees brought about by sufficient distribution.
This situation holds for the default subnet, which currently has about 1450 validators, although the transition to new subnets remains to be seen. In short, Avalanche's trade-off is to load security guarantees more significantly onto each subnet in exchange for greater flexibility.
Interoperability
Considering the modularity of this architecture and the multiple concurrent states of different chains within the ecosystem (as opposed to a single global state), cross-chain and cross-subnet communication becomes a topic of focus.
Cross-chain Transfers within a Single Subnet: Since each subnet has a set of validators for all blockchains within that subnet, this issue is relatively easy to resolve. For example, transferring assets between the X, C, and P chains of the main/default subnet. Given that there are at least three concurrent states in this architecture, any asset Z must not exist in any account of the sending chain's current state before it can become part of the transfer on the receiving chain. Therefore, when a user requests to transfer Z from the X chain to the C chain, for instance, the subnet validators must first agree to burn Z on the X chain and then mint Z on the C chain. Since the same group of validators is responsible for consensus across all chains within the subnet, this process becomes relatively straightforward.
Cross-chain Transfers between Different Subnets: Cross-chain transfers between different subnets are more challenging because the validator sets are no longer the same. In this case, external bridging with third-party relayers becomes crucial. The current Avalanche architecture has a module that can deploy bridges between multiple subnets. Each instance can be customized as 1) burn and mint or 2) lock and mint. Unlike single subnet transfers, this relies on third-party relayers to observe the burn or lock on the sending chain and relay this information to the receiving chain to initiate minting. Below is an overview of the implementation example of bridging WAGMI and Fuji subnets:
In the current setup, each pair of subnets requires a separate bridge, with the threshold for relayers as low as one, and the execution of relayers is outsourced to Chainsafe. This is an acceptable short-term solution, but in the long run, a single bridge with a distributed relayer network may enhance security.
Information transmission within Avalanche subnets is similar to that in Cosmos and Polkadot, with a single validator set observing the state of each chain and facilitating transmission. As long as this validator set is sufficiently distributed, it can provide reasonable shared security guarantees, so this architecture is also worth recommending. However, information transmission between subnets still needs improvement, currently relying on third-party relayers, so as long as the third-party bridge has its own security guarantees, the results will be relatively reasonable. Therefore, deploying within existing subnets is more appropriate than directly deploying new subnets.
Speed and Capacity
Similar to Cosmos, Avalanche adopts a distributed state to support multiple independent blockchains. Due to the flexibility of consensus mechanisms and validator sets, some blockchains in the Avalanche ecosystem can also have shorter block times based on the number of participants in each subnet; for example, the time to finality for the C chain is 2 seconds, while all other chains currently have sub-second finality times.
IV. Polygon Supernets
Overview
Polygon is the latest announced out-of-the-box specific application blockchain in this series of ecosystems, called Supernets. Similar to Cosmos SDK, Polygon has a modular framework called Edge, which facilitates the creation of independent networks. Users can use this framework to deploy shared security or sovereign blockchains. Both types of chains maintain independent states, but shared security chains utilize a shared set of validators, while sovereign blockchains deploy their own validators.
Consensus, Finality, and Validator Set
There are two types of consensus that can be used in Supernets:
IBFT PoA (Istanbul BFT Proof of Authority): The default consensus of Polygon Edge. It is a fixed validator set, and validators can add and/or remove validators through a majority (51%) vote. Consensus is achieved through a supermajority (2/3) vote. Validators take turns proposing new blocks. This is more suitable for sovereign blockchains under the Supernet framework.
PoS: Following the traditional PoS architecture, any network participant can stake tokens to become a validator. Validators receive token rewards in the network or are slashed for malicious behavior. Unlike other frameworks we have seen so far, all shared security Supernets have the same validators, and each validator must stake MATIC on Ethereum to participate in the Supernet's consensus and pay for non-malicious activity participation with MATIC. Although it does not have the global shared concept like Polkadot, since each Polygon Supernet shares the same validator set, it can also achieve shared security.
The Supernet architecture incentivizes with MATIC tokens, with about 200 validators participating in the shared security PoS module, providing strong shared security guarantees. In exchange, projects must sacrifice the flexibility of designing their own incentive mechanisms and use native tokens to connect with consensus. For projects focused on building high-performance applications, they need to make trade-offs between building applications themselves and building a computing layer that can be used by other applications.
Interoperability
The Polygon Edge framework utilizes a bridging solution called ChainBridge to facilitate communication between Supernets, including but not limited to token transfers. Similar to some solutions we saw earlier in this article, the following is the token transfer process:
- Tokens are locked or burned on the source chain
- The relayer observes this action on the source chain and communicates the information to the destination chain
- The source chain token representative is minted on the destination chain
- If the source chain token is locked (or burned), users can return wrapped tokens on the destination chain to unlock the underlying assets on the source chain.
In the cases of Edge and ChainBridge, unlike some earlier solutions in this article, the validators of the Supernet and the bridge do not necessarily have to be the same.
This contrasts with the strong viewpoint in independent multichain architectures that a shared validator set for chain-level and communication-level consensus leads to fewer failure points. That said, considering the other shared security features provided by Polygon, if the bridge validator set is sufficiently distributed and has appropriate incentives, this may not be a critical factor.
Speed and Capacity
Polygon has made an interesting design related to speed and security. By sharing a validator set and consensus mechanism, Polygon provides sufficient shared security guarantees. At the same time, by allowing each Supernet to maintain its own state, it avoids the overhead faced by Polkadot and others, theoretically allowing for an unlimited number of Supernets.
V. Binance BAS
Overview
Binance Application Sidechains (BAS) is a modular framework for specific application blockchains used by BSC. The initial version of BAS is estimated to be a series of PoS sidechains, with 3-7 validators, depending on the security level required for each chain. BAS chains are the only specific application blockchains discussed in this article that neither share consensus nor state; each BAS has its independent validator set. To associate with BSC, it may only be possible through a shared toolkit for developers to build sidechains and external bridges connecting BAS chains with BSC.
In addition to BAS, Binance is also establishing a general execution environment similar to Ethereum L2, called BNB Chain Partition Chain (BPC), which will be used to carry some computations of the BNB Beacon chain. This is interesting, but we will focus on the discussion of specific application sidechains in this article.
Consensus, Finality, and Validator Set
Each BAS chain will have its own 3-7 validators, expected to operate on a PoS supermajority (2/3) consensus. Unlike Polygon Supernets, each BAS chain will operate using its own staking and utility tokens. Furthermore, the state and state transitions of each sidechain will be completely independent of other sidechains.
The architecture provided by Binance may be one of the weakest cases in the field. Since each chain has a small independent validator set and maintains its own state, this means that shared security guarantees are extremely limited; the only tool Binance provides for developers is a toolkit for building blockchains themselves. If the validator set could be larger or if high-trust sharing could occur across all sidechains, then building projects with Binance would be worth considering. However, BAS is more suitable for projects that only require low consensus sharing.
Interoperability
Like any set of sovereign blockchains, BAS chains will require third-party bridges to communicate with each other. In this case, BSC will utilize Celer's third-party bridge, connecting to each BAS through a "lock and mint" mechanism, while each BAS also connects through this mechanism.
Binance employs third-party bridges with independent validators, making it less attractive to build projects in its ecosystem than to establish an independent blockchain, as any independent blockchain can theoretically connect through these bridges. It is worth noting that objectively this is not a bad design; it just means that for developers, there is no strong reason to choose to build projects within this ecosystem rather than directly building independent architectures.
Speed and Capacity
Under the BAS architecture, sidechains do not share validators, consensus, or state, and the small scale of each chain's validator set may lead to short times to finality, allowing for a large number of chains.
Conclusion
For some time, specific application blockchains have been an important component of scalability discussions, although their implementation has been constrained by immature interoperability infrastructure. In recent months, this infrastructure has been continuously launched in various independent multichain ecosystems, so we also hope to see more activity in this field—including but not limited to the creation and development of more use-case-specific sub-application layers (such as Acala on Polkadot) and execution environments for specific applications.
Overall, each project in this field has made different trade-offs between speed/capacity and shared security. Projects that can successfully attract the most developers are likely those that strike a balance between the two.