Scalability has long been a topic of extensive discussion in this field. Discussions around monolithic versus modular blockchains, horizontal versus vertical scaling, have long been the focus of community communication.
A popular idea has arisen as a result of this – the establishment of specialized execution environments or even finality (i.e., finality, which refers to the state where transactions on the blockchain reach a confirmed transaction state) tool for a specific application or use case. 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 can theoretically reduce the load on a single underlying blockchain and improve its performance. But this approach has long been hampered by the fact that the infrastructure required to ensure interoperability under this architecture is extremely complex.
Over the past few years, we have made significant progress in addressing these challenges in different ways. More importantly, in the past few months, the communication layers of several independent multi-chain environments have come online, and these communication layers are arguably the most important piece of this “puzzle”. Meanwhile, in the past few weeks, more L1/L2 blockchains announced tweaks to their architectures to provide out-of-the-box infrastructure for application-specific blockchains, once again rekindling the discussion.
In this post, we examine in detail the various forms of architectures developed to pursue this vision and compare their trade-offs for shared consensus, capacity, and interoperability. Specifically, we study five independent multi-chain architectures: Polkadot, Cosmos, Avalanche, Polygon Supernets, and Binance BAS.
Note: This article focuses on independent multi-chain infrastructure, where the blockchains for this particular application share validator groups or consensus algorithms.
Independent multi-chain ecosystems vary in their degree of connectivity, from a shared developer toolkit to a shared set of validators, finality tools, and state. Objectively, each approach has its own advantages, but all are somewhat optimized for the maintenance and speed/capacity of shared security.
In this article, we compare these ecosystems through five key parameters.
All ecosystems meet the basic requirements for sybil attack defense, finality realization time, etc., so there is no optimal consensus mechanism in essence. However, it is worth comparing: 1) the specific type of consensus model, 2) the shared or independent consensus mechanism of each chain, and 3) the shared or independent token incentives. 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. The shared consensus mechanism and token incentives mean that the base layer can provide greater security, while the choice of independence means greater design flexibility.
Within these ecosystems, some chains maintain some form of independence, while others achieve finality at the overall level. This provides 1) greater security and 2) more comprehensive interoperability. However, this also brings trade-offs in capacity constraints, and if the number of modular blockchains exceeds a certain number, the process of reaching finality will be significantly slowed down.
3. Shared validator group/node autonomy
In addition to shared consensus mechanisms, individual blockchains can also share groups of validators. In the example below, validator sharing ranges from a single validator set on all chains, to multiple validator sets (each of which provides consensus for some but not all of the underlying blockchain), to A mutually exclusive set of validators for each underlying blockchain. Shared validator sets provide a centralized security guarantee due to the reduced marginal risk of each new blockchain, but a large-scale trade-off on nodes can cause all chains secured by the validator set to be adversely affected. The ideal state for this parameter is a well-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 group with a small number of centralized nodes.
4. Interoperability Architecture
Most of the projects covered in this article have adopted a “destroy burn + mint” or “lock + mint” bridging architecture. The difference between these systems is: 1) routing, i.e. whether messages and tokens go through a single validator group with some kind of global state observation state, or whether each route is independent; 2) whether these validator groups that acquire the link Shared by the ecosystem, or outsourced to a third party. The closer the ecosystem is to the state of independent routing and third-party verifier outsourcing, the less we recommend choosing this underlying ecosystem for new chain releases. It is better to directly connect with a general-purpose third-party bridge for independent release.
5. Speed and capacity
Speed and capacity are largely characterizations of the above design choices and can be measured by the time to reach the terminal 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 hold a certain number of chains, so the time to finality is significantly slower, a trade-off for greater security.
Below is a macro overview of these five ecosystems on these parameters. In the rest of the article, we’ll break down each of these ecosystems and discuss the pros and cons of each design choice.
I. Polkadot parachains
Polkadot emerged early in the field and was built to support application-specific blockchains that share a single global state. Under the Polkadot architecture, application-specific blockchains (parachains) share computing and consensus resources with the underlying blockchains (called relay chains), and their main function is to maintain a unified global state.
Consensus, Finality, and Validator Groups
Polkadot runs the proposed Proof-of-Stake consensus at the relay chain level. Under this architecture, there are three types of nodes.
Nominators choose trusted validators and stake some of their DOTs to them. They share the validator’s reward, but they also get slashed if the validator engages in malicious activity.
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 chains and individual transactions.
Collators collect transactions on a particular parachain and propose a candidate transaction block and a state transition proof to relay chain validators. Each proofreader maintains a node on the relay chain and the parachain it works on. They accumulate transactions on their parachains, create unsealed blocks, and provide them along with proofs of state transitions to one or more relay chain validators. The block is not considered final until the relay chain validators reach consensus.
Although parachains share global state, they are free to choose the specific consensus algorithm they run (GRANDPA/Tendermint/traditional pBFT, etc.) in order to achieve parachain-level verification before settlement on the relay chain (Polkadot/Kusama).
A unique feature of Polkadot consensus is that it decouples block production and block finality; operating under a hybrid consensus framework.
Block production mechanism: BABE (Blind Assignment for Block Extension) block extension random allocation system
Based on staked value and Polkadot’s random cycle, validators are selected to place orders and produce blocks for 6-second slots. Under this random selection, there may end up with one, many, or zero block production candidates per slot. Block production turns into a competition when multiple validators are elected to the same slot. In the event that no validator is selected, a second round of selection occurs. Once a block is produced, the message is transmitted to other validators.
Finality tool: GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) GOSHT-based recursive ANcestor Deriving Prefix Agreement
Once a relay chain block is transmitted to the rest of the network, it requires at least a 2/3 majority to be added to the chain. However, GRANDPA is unique in that it agrees on the chain rather than the block. This means that when it confirms a chain containing a block, the blocks before that block are immediately finalized together, unlike the traditional block-by-block confirmation process.
Ultimately, Polkadot adopts the highest security consensus approach, while providing some flexibility for parachains. Each parachain can be designed on 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), and each validator has a maximum of 256 nominators. Its shared validator set sacrifices some design flexibility to ensure higher security for parachain projects. Centralized consensus at the relay chain level can provide higher shared security, but it also sacrifices some performance: the number of parachains is fixed, and after this number, the time to finality will slow down significantly.
Under this architecture, these components, especially 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 will be transmitted through the relay chain, thereby continuing its security. There are two types of messages that can be delivered:
Up-Passed Message (UMP): A message from a parachain to a relay chain
Downstream Delivered Message (DMP): A message from the relay chain to one of the parachains.
Information entering a parachain is called ingress, and information going out is called egress.
Here’s how a message goes from parachain A to parachain B:
Parachain A issues UMPs, which are transmitted to all validator nodes on the relay chain as part of the export batch.
Every time a collation node on parachain B submits a new block candidate to the relay chain, it searches for a new entry message.
The entry information is added to the processing queue of parachain B and will be passed to the validator node in the next block proposal.
In the process of asset transfer, the underlying assets are destroyed on the A blockchain and reissued on the B blockchain.
Given that all messages go through a single validator that observes global state (shared with the Polkadot relay chain), and all chains are built on the same standards, this makes the “burn + mint” model efficient. Polkadot’s interoperability layer is one of the most efficient and secure in the space. It is therefore recommended to choose to build projects within its ecosystem, as XCM can be used to seamlessly connect with existing parachains and leverage these network effects to launch.
speed and ability
The price of having a higher shared security guarantee is that after a certain number of parachains, the time to finality is significantly slowed down. In Polkadot, there are estimated to be about 100 parachains, which are used for rent, in order to reduce the impact of this limitation. Projects can, with the support of the community, bid for the use of parachains through DOT staking, and once the quota expires, they must re-bid with other participants to reserve the quota. This is a default governance mechanism for projects with the most activity and community support, partially circumventing capacity constraints, but it also means that the barriers to entry for new projects to join the ecosystem are relatively high.
The Cosmos SDK is a set of tools with out-of-the-box consensus and execution that allow anyone to create their own PoA/PoS blockchain. Unlike other ecosystems covered in this article, Cosmos is built on the premise that smart contract-based virtual machines are limited in their flexibility, sovereignty, and performance. So instead of building a single virtual machine that can run multiple applications, Cosmos encourages and facilitates the creation of separate blockchains for each use case. Under this structure, application developers can flexibly operate around a specific architecture, language, etc. when building, and achieve interoperability through Cosmos’ multi-chain communication layer, IBC. A single blockchain is called a zone, and the connected modules are called a hub.
Consensus, Finality, and Validator Sets
In the Cosmos ecosystem, unlike Polkadot, each application-specific blockchain maintains its own independent state, achieving independent finality on each block. With the Cosmos SDK, developers only need to define state machines (ie, applications) and can rely on Cosmos’ Tendermint core (a shared software layer) to drive consensus and network connectivity. Tendermint runs a BFT-based consensus algorithm that validators in each independent zone can leverage to facilitate state transitions and maintain independent states. In each blockchain/zone, each epoch selects a validator at random to propose the next block; the block can be considered valid if more than 2/3 of the validators prove its validity. The validator set and specific incentive design can be defined at the state machine/application level.
Tendermint is a shareware layer to which each blockchain/zone must be connected via a dedicated interface called ABCI (Application Blockchain Interface). Transactions from various districts are passed to the Tendermint core as transaction bytes through ABCI, and the verifiers sort these bytes finally and pass codes back to the state machine through 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 Center is secured by a validator group of approximately 150 validators, running on the Tendermint consensus. Since each zone maintains its own state and sets the incentive mechanism through its own Token, the central validator does not need to participate in the consensus of each zone. In practice, however, the validator maintains the center and associated districts, running the same consensus algorithm, so the overlap between them makes sense.
In general, Cosmos opts for a slightly different trade-off than Polkadot, where the chains share a consensus mechanism, but remain independent and do not mandate the same set of validators and incentives. Shared consensus provides a degree of security, while independently defining incentives and remaining independent provides each project with design flexibility. Standardized consensus also leads to more validator overlap, which, coupled with the large distribution of validators themselves, also increases shared security, albeit to a lesser degree than Polkadot. Cosmos begins preparations at the end of 2021 to introduce shared/interchain security. Under this proposed framework, single chains will be able to borrow/share security guarantees from the Cosmos hub. Validators will be able to run two nodes, one on the hub and one on the zone, and receive fees and rewards from participating in the consensus of both nodes. The Tokens mortgaged on the center will be used as the shared collateral for the integrity consensus of the two places. The malicious activities of either party will cause the two parties to be “slashed” (slash: generally refers to the removal of the collateral), which will increase the number of new chains available. Shared security.
Given that each district is sovereign and maintains an independent status, communication between districts has become increasingly important. Cosmost observes the state of the zones connected to the hub through the hub (which acts as a route to connect the zones). The Cosmos Hub is the first hub in the Cosmos ecosystem to which most of the early high-value zones are connected. Through the Cosmos Hub, connected districts 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 light client that keeps track of the consensus state of each chain and the necessary proofs to properly verify the proofs against the client’s consensus state.
Under the IBC architecture, from the beginning of Token transmission, each chain will receive header information from the other party to track the other party’s validator set. Then, the sending address on the source chain sends a coin packet, which is recorded by the center. The central validator must reach a consensus on the validity of the transaction and lock these tokens in the contract on the source chain. Afterwards, the center issues a proof at the destination, proposing to mint the packaging tokens of these locked assets on the destination chain. The validator on the destination chain then matches the proof against the source chain header, and then approves the function in the next block to mint the wrapped asset on the destination chain. If the above actions do not occur, the locked assets on the source chain will be returned to the sender address. The wrapped asset representatives are then destroyed on the destination chain through the center, so that the underlying assets on the source chain can be unlocked.
In Cosmos, routing is managed by a single and well-distributed set of validators that observe the state of all blockchains, and most of these validators are shared with the blockchain, so it can revolve around Zone messaging provides adequate security. It also makes a good case for building within the Cosmos ecosystem, as points of failure are centralized and fully decentralized.
speed and capacity
Since finality is not centralized on a single chain, Cosmos can theoretically have an infinite number of zones and centers. Therefore, unlike Polkadot, it has no difficulty building new chains with new projects. The trade-off here is to offload some security to the zone (letting the zone design its own incentives and attract validators) in exchange for greater design flexibility and higher capacity to accommodate more individual blockchains.
III. Avalanche subnets
Avalanche is a blockchain ecosystem validated by groups of nodes called subnets. Subnets are free to choose their own consensus mechanism, including Avalanche’s novel consensus variant based on repeated random subsampling. Each blockchain within a subnet shares computing and consensus resources, but ultimately maintains its own state, and there is no global shared state.
Consensus, Finality, and Validator Sets
To better understand its architecture, we must understand 3 key parts:
Refers to repeated random subsampling. Avalanche consensus is built on the snowball algorithm, which utilizes repeated random subsampling to achieve consensus. Under this system, each node randomly asks k number of neighboring nodes to determine whether a transaction is correct. This process is repeated until a certain preset quorum x is reached, and the nodes are within a high confidence range (at least the hash collision probability of Bitcoin), and finally the network agrees on the validity of the transaction.
Avalanche consensus and Snowman consensus
Snowman and Avalanche are the two main PoS-based consensus models in the Avalanche ecosystem, using repeated random subsampling. The difference between the two is that Avalanche uses a DAG (Directed Acyclic Graph) architecture, while Snowman is built for linear blockchains. The key difference between a DAG-based system and a linear blockchain is that the finality of a linear blockchain is ordered, while in a DAG-based system, its state is closer to a transaction network with disordered finality. Blockchains within the Avalanche ecosystem can choose to use one of the two consensus models, or adopt their own.
A subnet is a collection of validators that can provide consensus on some blockchains within the Avalanche framework. Each blockchain has a subnet, but each subnet can verify multiple blockchains. Because each blockchain is independently verified and the global state is non-linear across blockchains, there is no shared security between blockchains.
Virtual Machine (VM)
The virtual machine determines the application-level logic of the blockchain. Instead of just providing a set of opcodes, Avalanche wants to give each blockchain a set of opcodes to choose from, to process and transition states, etc. Current options include Subnet EVM (EthereumVM built for Subnets), AvalancheVM (DAG chain), SpacesVM (one key:value store virtual machine), and BlobVM (binary data store virtual machine). Beyond that, projects are free to implement their own custom virtual machines.
The Avalanche architecture is enabled by the premise 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 secured by all participating Avalanche validators, with three blockchains under it.
P-chain: A linear blockchain based on snowman consensus, used for tasks such as creating validators, adding delegators, and creating subnets.
X Chain: A DAG-type blockchain based on Avalanche consensus for exchanging assets.
C chain: Linear blockchain based on snowman consensus, running EVM for general smart contracts.
Various permutations and combinations of these validators can then form subnetworks that validate incrementally participating blockchains.
In general, each blockchain in the Avalanche ecosystem maintains its own state and can independently choose its own 1) consensus mechanism, 2) validator set, and 3) incentive design. Blockchains within the same subnet benefit from the higher shared security guarantees brought about by full distribution.
The above holds true for the default subnet with ~1450 validators today, although the transition to the new subnet remains to be seen. In short, the trade-off that Avalanche makes is to put a greater degree of security on each subnet in exchange for more flexibility.
Given the modularity of the architecture, and the fact that different chains within the ecosystem have multiple concurrent states (as opposed to a single global state), cross-chain and cross-subnet communication becomes a concern.
Cross-chain transfers within a single subnet: Since each subnet has a set of validators for all blockchains within that subnet, this problem is easier to solve. We can give an example like transferring assets between X, C and P chains of the main/default subnet. Since there are at least 3 concurrent states in this architecture, any asset Z must not exist in any account in the current state of the sending chain before it can be part of a transition in the receiving chain. Therefore, when a user requests a transfer of Z from X chain to C chain, for example, the subnet validator must first agree to burn Z on X chain and then mint Z on C chain. This process is made relatively easy since the same set of validators is responsible for consensus on all chains within the subnet.
Cross-chain transfers between different subnets: Cross-chain transfers between different subnets are challenging because the validator set is no longer the same. In this case, external bridging with third-party repeaters becomes important. There is a module in the current Avalanche architecture that deploys bridging between multiple subnets. Each instance can be customized to 1) burn and mint or 2) lock and mint. Unlike single-subnet transfers, this relies on third-party relayers to observe burns or locks on the sending chain and forward this message to the recipient chain to initiate minting. Below is an overview of an example implementation of bridging WAGMI and Fuji subnets:
With the current setup, an independent bridge is required for each pair of subnets, the threshold for repeaters can be as low as one, and the execution of repeaters is outsourced to Chainsafe. This is an acceptable short-term solution, but a single bridge with a distributed network of repeaters may improve security in the long run.
Avalanche’s intra-subnet messaging is similar to the likes of Cosmos and Polkadot, with a single group of validators observing the state on each chain and facilitating transfers. As long as this validator set is sufficiently distributed, it can provide reasonable shared security guarantees, so this architecture is also recommended. However, the information transfer between subnets still needs to be perfected and currently relies on third-party repeaters, so as long as third-party bridges have their own security guarantees, the results will be relatively reasonable. Therefore, deploying within an existing subnet is more appropriate than deploying a new subnet directly.
speed and capacity
Similar to Cosmos, Avalanche adopts a distributed state to support multiple independent blockchains. Due to the flexibility of the consensus mechanism and validator set, some blockchains in the Avalanche ecosystem can also have shorter block times based on the number of participants in each subnet; for example, the C chain takes 2 to reach finality seconds, all other chains currently have sub-second finality times.
IV. Polygon Supernets
Polygon is the latest announced out-of-the-box application-specific blockchain in a series of ecosystems called Supernet. Similar to the Cosmos SDK, Polygon has a modular framework called Edge that facilitates the creation of independent networks. Users can leverage the framework to deploy shared security or sovereign blockchains. Both chain types remain separate, but shared security chains utilize a shared set of validators, while sovereign blockchains deploy their own validators.
Consensus, Finality, and Validator Groups
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. is a fixed set of validators, validators can add and/or remove validators by majority (51%) vote. Consensus is reached by a supermajority (2/3) vote. Validators take turns proposing new blocks. It is more suitable for the sovereign blockchain under the supernet framework.
PoS : Following the traditional PoS architecture, any network participant can pledge Token to become a validator. Validators receive token rewards in the network, or are “slashed” for malicious behavior. Unlike other frameworks we’ve seen so far, all shared security supernets have the same validators, and each validator must stake MATIC on Ethereum in order to participate in the supernet’s consensus and pay for non-malicious activity in MATIC participate. While not having its concept of global sharing like Polkadot, shared security is also achieved since each Polygon supernet shares the same set of validators.
The supernet architecture is motivated by MATIC Token, and about 200 validators participate in the shared security PoS module, which provides a strong shared security guarantee. In exchange, projects must sacrifice the flexibility of designing their own incentives and use native tokens to connect to consensus. For projects focused on building high-performance applications, they need to choose between building their own applications and building their own compute layers that can be used by other applications.
The Polygon Edge framework utilizes a bridging solution called ChainBridge to facilitate communication between supernets, including but not limited to token transfers. Similar to the solutions we saw earlier in this article, here is the token transfer process:
1. Tokens are locked or destroyed on the source chain
2. The repeater observes this action on the source chain and communicates the information to the destination chain
3. The token of the source chain is minted on the destination chain
4. If the source chain Token is locked (or destroyed), the user can return the packaged Token on the destination chain to unlock the underlying assets on the source chain.
In the case of Edge and ChainBridge, unlike some of the solutions earlier in this article, the validators for the supernet and bridge are not necessarily the same.
This is contrary to the strong argument in independent multi-chain architectures that a shared set of validators for chain-level and communication-level consensus leads to fewer points of failure. That said, given the other shared security features provided by Polygon, this may not be a critical factor if the bridge validator set is sufficiently distributed and incentivized.
speed and capacity
Polygon has come up with an interesting design related to speed and safety. By sharing validator sets and consensus mechanisms, Polygon provides sufficient shared security guarantees. At the same time, by letting each supernet maintain its own state, it avoids the overhead faced by Polkadot and others, allowing theoretically an unlimited number of supernets to be built.
V. Binance BAS
Binance Application Sidechains (BAS) is BSC’s modular framework for application-specific blockchains. The initial version of BAS is estimated to be a series of PoS sidechains with 3-7 validators, depending on the level of security required by each chain. The BAS chain is the only application-specific blockchain covered in this post and should share neither consensus nor state, and each BAS has its own independent set of validators. To associate with BSC, it may only be possible through a shared toolkit for developers to build side chains and an external bridge connecting the BAS chain and BSC.
In addition to BAS, Binance is also building a common execution environment, similar to Ethereum L2, called the BNB Chain Partition Chain (BPC), which will be used to host some computations on the BNB Beacon chain. This is interesting, but we will focus on application-specific sidechain discussions in this post.
Consensus, Finality, and Validator Sets
Each BAS chain will have its own 3-7 validators and is expected to run a PoS based supermajority (2/3) consensus. Unlike the Polygon Supernet, each BAS chain will operate with its own staking and utility tokens. Additionally, the state and state transitions of each sidechain will be completely independent of other sidechains.
The architecture provided by Binance is perhaps one of the weakest in the space. Since each chain has a small set of independent validators and maintains its own state, which means that shared security guarantees are extremely limited, the only tool Binance offers developers is a toolkit for building their own blockchains. Building a project with Binance is worth considering if the validator set can be larger, or shared with high trust across all sidechains. However, BAS is more suitable for project construction that only requires low consensus sharing.
Like any set of sovereign blockchains, BAS chains will require third-party bridges to communicate with each other. In this case, BSC will use Celer’s third-party bridge to connect to each BAS in the form of “lock + minting”, and each BAS is also connected through this mechanism.
Binance employs third-party bridges with independent validators, and building projects in its ecosystem may not be as attractive as building an independent blockchain, as any independent blockchain could theoretically be connected through these bridges. The point to be pointed out is that objectively this is not a bad design, but for developers, they have no strong reason to choose to build projects in this ecosystem, it is better to choose to build an independent architecture directly.
speed and capacity
Sidechains under the BAS architecture do not share validators, consensus or state, and the validator set of each chain is small, resulting in a short time to finality and a large number of chains that can be accommodated.
Application-specific blockchains have been an important part of the scalability discussion for some time, although its implementation has been hampered by an interoperability infrastructure that has yet to mature. Over the past few months, this infrastructure has continued to come online in various independent multi-chain ecosystems, so we would also like to see more activity in this area – including but not limited to creating and developing more use-case specific The sub-application layer (eg Acala on Polkadot) and the execution environment of the specific application.
In general, each project in this space makes a different trade-off of speed/capability versus shared security. The projects that successfully attract the most developers are likely to be those that strike a balance between the two.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/jump-crypto-explain-the-characteristics-advantages-and-disadvantages-of-five-multi-chain-architectures-such-as-cosmos-and-avalanche-in-detail/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.