Original title: "Flavors of Standalone Multichain Architecture》

Compilation of the original text: Guo Qianwen, Chain Catcher

Compilation of the original text: Guo Qianwen, Chain Catcher

overview

overview

Scalability has long been a widely discussed topic in the field. Discussions around monolithic vs. modular blockchains, horizontal vs. vertical scaling, have long been the focus of community conversations.

A popular view has thus emerged - to establish a specialized execution environment or even a finality (that is, finality, referring to the state that a transaction on the blockchain has reached a state of transaction status confirmation) tool for a specific application or use case. This idea specifically refers to the separation and optimization of consensus and computing based on the security and speed requirements of each product and each 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 sheer complexity of the infrastructure required to ensure interoperability under such an architecture.

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 been launched. These communication layers can be said to be the most important piece of this "puzzle". Meanwhile, in the past few weeks, more L1/L2 blockchains have announced adjustments to the architecture, providing out-of-the-box infrastructure for application-specific blockchains, once again re-igniting the discussion.

In this post, we examine in detail the various forms of architectures developed in pursuit of this vision, and compare their trade-offs in terms of 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 standalone multi-chain infrastructure, where application-specific blockchains share validator groups or consensus algorithms.

comparison standard

The degree of connectivity of independent multi-chain ecosystems varies from as low as a shared developer toolkit to as high as a shared validator set, finality tools, and state. Objectively speaking, each approach has its own advantages, but all have some degree of optimization for the maintenance and speed/capacity of shared security.

In this article, we compare these ecosystems by five key parameters.

1. Consensus

All ecosystems meet the basic requirements of Sybil attack defense and finality realization time, so there is no optimal consensus mechanism in essence. However, it is worth comparing: 1) the specific type of consensus model, 2) shared or independent consensus mechanisms for each chain, and 3) 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, or 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 choosing independence means greater design flexibility.

2. Finality/Status

In these ecosystems, some chains maintain some form of independence, and some chains are finalized at the overall level. This provides 1) greater security and 2) more comprehensive interoperability. However, this also brings trade-offs in terms of capacity constraints. If the number of modular blockchains exceeds a certain number, the process of reaching finality will be greatly slowed down.

3. Shared validator group/node autonomy

In addition to sharing consensus mechanisms, individual blockchains can also share validator groups. In the example below, validator sharing ranges from a single validator set on all chains, to multiple validator sets where each validator set provides consensus for some but not all of the underlying blockchains, to Mutually exclusive set of validators for each underlying blockchain. A shared validator set provides centralized security due to the reduced marginal risk of each new blockchain, but large-scale compromises on nodes can lead to adverse effects on all chains secured by the validator set. The ideal state for this parameter is a single validator set that is sufficiently distributed to provide shared security 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 "burn burn + mint" or "lock + mint" bridging architecture. These systems differ in: 1) routing, i.e. whether messages and tokens go through a single set of validators with some kind of global state observation state, or whether each route is independent; 2) the set of validators that these acquire links to Whether it is shared by the ecosystem or outsourced to a third-party organization. The closer the ecosystem is to the state of independent routing and outsourcing of third-party verifiers, 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 releases.

5. Speed ​​and capacity

Speed ​​and capacity are largely indicative of the above design choices and can be measured by the time to reach a 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 accommodate a certain number of chains, so the time to finality will be significantly slower, a trade-off for greater security.

I. Polkadot Parachains

overview

overview

Polkadot was earlier in the space, built to support application-specific blockchains that share a single global state. Under the Polkadot architecture, application-specific blockchains (parallel chains) share computing and consensus resources with the underlying blockchain (called the relay chain), and its main function is to maintain a unified global state.

Consensus, Finality, and Validator Groups

Polkadot runs a proposed proof-of-stake consensus on the relay chain layer. In this architecture, there are three types of nodes.

Nominators select trusted validators and stake some of their DOTs to them. They share validator rewards, but validators are also slashed if they engage in malicious activity.

Validator:

Validator:

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.

Proofreader:

Collators collect transactions on a particular parachain and propose a block of candidate transactions and a proof of state transition to relay chain validators. Each collator maintains a node on the relay chain and the parachain it works on. They accumulate transactions on their own parachains, creating unsealed blocks, which they provide to one or more relay chain validators along with state transition proofs. The block is not considered final until the relay chain validators reach consensus.

While parachains share global state, they are free to choose the specific consensus algorithm they run (GRANDPA/Tendermint/traditional pBFT, etc.) to enable parachain-level validation before settlement on the relay chain (Polkadot/Kusama).

A unique feature of Polkadot consensus is that it separates 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

Validators are selected to place orders and produce blocks for 6-second slots based on the value of the stake and Polkadot's random cycle. With this random selection, each slot may end up with one, many, or zero block production candidates. Block production turns into a competition when multiple validators are elected to the same slot. In the event that no validators are 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

In the end, Polkadot adopted the highest security consensus method, while providing some flexibility for parachains. Each parachain can make a design on the chain-level "consensus" to propose blocks to the relay chain, but the finality is only realized on the Polkadot relay chain, which is guaranteed by a group of verifiers who must pledge DOT tokens 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 guarantees for parachain projects. Centralized consensus at the relay chain level can provide higher shared security, but it will also sacrifice some performance: the number of parachains is fixed, and after this number, the time to finality will be greatly slowed down.

Interoperability

Interoperability

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 the Polkadot cross-chain information delivery system will be transmitted through the relay chain, thereby continuing its security. There are two types of messages that can be passed:

• Upwardly passed messages (UMP): messages from a parachain to the relay chain

• Downwardly Delivered Message (DMP): A message from the relay chain to one of the parachains.

Information entering a parachain is called an ingress, while information going out is called an egress.

• The following is the process of passing a message from parachain A to parachain B:

• Parachain A issues a UMP, which is transmitted to all validator nodes on the relay chain as part of an exit batch.

• Collator nodes on parachain B search for new entry messages every time they submit a new block candidate to the relay chain.

• 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 observing the global state (shared with the Polkadot relay chain), and all chains are built on the same standard, this makes the burn+mint model efficient. Polkadot's interoperability layer is one of the most efficient and secure in the space. Therefore, it is recommended to choose to build projects within its ecosystem, because XCM can be used to seamlessly connect with existing parachains and borrow these network effects for startup.

The price of having higher shared security is that after the number of parachains reaches a certain value, the time to finality will be greatly slowed down. In Polkadot, there are estimated to be about 100 parallel chains, which are used for rent, and the purpose is to reduce the impact of this limitation. With the support of the community, projects can bid for the use of parachains through DOT pledge. Once the quota expires, they must re-bid with other participants to retain 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.

II. Cosmos

overview

overview

The Cosmos SDK is a set of tools with out-of-the-box consensus and execution, allowing 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 have limited flexibility, sovereignty, and performance. Therefore, 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 operate flexibly around specific architectures, languages, etc. when building, and achieve interoperability through Cosmos' multi-chain communication layer IBC. Individual blockchains are called zones, while connected modules are called hubs.

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 the state machine (i.e. the application) 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 randomly selects a validator to propose the next block; if more than 2/3 of the validators prove its validity, the block can be considered valid. Validator sets and specific incentive designs can be defined at the state machine/application level.

Tendermint is a shared software layer to which each blockchain/zone must connect via a dedicated interface called ABCI (Application Blockchain Interface). Transactions from each zone are passed to the Tendermint core as transaction bytes through ABCI, and the verifier sorts these bytes for finality, and sends codes back to the state machine through ABCI to prove the validity of these transactions.

In general, Cosmos has chosen a slightly different trade-off from Polkadot, that is, the chains share the consensus mechanism, but each remains independent and does not require the same validator set and incentive mechanism to be guaranteed. Shared consensus provides a level of security, while independently defining incentives and maintaining independent state provides design flexibility for each project. Standardized consensus also leads to more validator overlap, which, combined with the large distribution of validators themselves, also increases shared security, although not to the same degree as Polkadot. Cosmos is starting preparations towards the end of 2021 for the introduction of shared/interchain security. Under this proposed framework, single chains will be able to borrow/share security guarantees from the Cosmos Central. 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 serve as a shared collateral for the integrity consensus of the two places. Malicious activities by either party will cause the two parties to be "slashed" (slash: generally refers to the removal of the pledge), which will increase the availability of new chains. shared security.

Interoperability

Interoperability

Given that each district is sovereign and maintains an independent status, communication between districts becomes increasingly important. Cosmost observes the state of the zones connected to the hub through the hub (which acts as a route connecting the zones). The Cosmos Hub is the first hub in the Cosmos ecosystem, to which most early high-value districts 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 lightweight client that keeps track of the consensus state of each chain and the necessary proofs to correctly verify the proofs against the client's consensus state.

Under the IBC architecture, from the beginning of the token transfer, each chain will receive header information from the other to track the validator set of the other. Then, the sending address on the source chain sends a coin packet, which is recorded by the center. A central validator must agree on the validity of the transaction and lock those tokens in a contract on the source chain. The center then issues a proof at the destination proposing to mint wrapped tokens of these locked assets on the destination chain. Validators on the destination chain will then match the attestation to the source chain header and subsequently approve this function in the next block to mint the wrapped asset on the destination chain. If the above actions do not take place, 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 basic assets on the source chain can be unlocked.

In Cosmos, routing is managed by a single and sufficiently distributed set of validators that observe the state of all blockchains, and most of these validators are shared with blockchains so that it can Zone messaging provides adequate security guarantees. This also provides a good reason to build within the Cosmos ecosystem, as the point of failure is centralized and sufficiently decentralized.

Since finality is not centralized on a single chain, Cosmos can theoretically have an infinite number of zones and hubs. So, unlike Polkadot, it has no trouble building new chains with new projects. The trade-off here is to offload some of the 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

overview

overview

Avalanche is a blockchain ecosystem validated by groups of nodes called subnetworks. Subnetworks 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:

Avalanche-style consensus

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 degree of confidence (at least Bitcoin's hash collision probability), and eventually the network agrees on the validity of the transaction.

Snowman and Avalanche, the two main PoS-based consensus models in the Avalanche ecosystem, use 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, whereas 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 model.

Subnet (Subnet)

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 validate multiple blockchains. Because each blockchain is independently verifiable, the global state is non-linear across blockchains, so there is no shared security between blockchains.

virtual machine (VM)

The virtual machine determines the application-level logic of the blockchain. Avalanche hopes to provide each blockchain with a series of operation codes for it to choose from, to process and convert state, etc., instead of providing only one set of operation codes. Current options include Subnet EVM (EthereumVM built for subnets), AvalancheVM (DAG chain), SpacesVM (one key:value storage virtual machine), and BlobVM (binary data storage virtual machine). Beyond that, projects are free to implement their own custom virtual machines.

The premise of the Avalanche architecture is that these three components fit into a modular framework that scales super-linearly with subnet/validator growth.

• In Avalanche's current form, there is a main network vouched by all participating Avalanche validators, with three blockchains under it.

• P chain: A linear blockchain based on Yeti consensus, used to create validators, add delegators, create subnets and other tasks.

• X-Chain: DAG-type blockchain based on Avalanche consensus for exchanging assets.

C chain: A linear blockchain based on Yeti consensus, running EVM, for general smart contracts.

Various permutations of these validators can then form subnetworks, validating incrementally participating blockchains.

The above is true for the default subnet with ~1450 validators today, the transition to the new subnet remains to be seen. In short, the trade-off Avalanche makes is to load a greater degree of security onto each subnet in exchange for greater flexibility.

Interoperability

Interoperability

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 an issue of 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 relatively easy to solve. We can give an example like transferring assets between the 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 to transfer Z from chain X to chain C, for example, subnetwork validators must first agree to burn Z on chain X and subsequently mint Z on chain C. This process is made relatively easy by the fact that the same set of validators is responsible for the consensus on all chains within the subnet.

Cross-chain transfers between different subnets: Comparing cross-chain transfers between different subnets is challenging because the set of validators is no longer the same. In this case, external bridging with third-party repeaters becomes important. The current Avalanche architecture has a module to deploy bridges 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 receiver chain to initiate minting. Here is an overview of an implementation example bridging the WAGMI and Fuji subnets:

With the current setup, each pair of subnets requires an independent bridge, 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 be more secure in the long run.

Avalanche's intra-subnet messaging is similar to Cosmos and Polkadot, etc., with a single set of validators observing the state on each chain and facilitating transfers. As long as the validator set is sufficiently distributed, it can provide reasonable shared security guarantees, so this architecture is also recommended. However, the transmission of information between subnets still needs to be improved, and currently relies on third-party repeaters, so as long as the third-party bridges have their own security guarantees, the results will be relatively reasonable. Therefore, deploying within an existing subnet is more appropriate than directly deploying a new subnet.

Similar to Cosmos, Avalanche adopts 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 time to finality for the C chain is 2 seconds, and all other chains besides that currently have sub-second finality times.

IV. Polygon Supernets

overview

overview

Polygon is the latest announced out-of-the-box application-specific blockchain in this 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 maintain separate states, 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 a supernet:

• IBFT PoA (Istanbul BFT Proof of Authority): Polygon Edge's default consensus. is a fixed set of validators, and validators can add and/or remove validators by majority (51%) voting. Consensus is reached by supermajority (2/3) voting. Validators take turns proposing new blocks. It is more suitable for the sovereign blockchain under the supernet framework.

The super network architecture is motivated by MATIC tokens, and about 200 verifiers participate in the shared security PoS module, providing a strong shared security guarantee. In exchange, projects must sacrifice the flexibility to design their own incentives and use native tokens tied to consensus. For projects focused on building high-performance applications, they need to make a trade-off between building their own applications and building their own computing layer, which can be used by other applications.

Interoperability

Interoperability

• The Polygon Edge framework leverages a bridging solution called ChainBridge to facilitate communication between supernets, including but not limited to token transfers. Similar to the solution we saw earlier in this post, here is the token transfer process:

• Tokens are locked or burned on the source chain

• The repeater observes this action on the source chain and communicates the information to the destination chain

• The source chain token represents the minted on the destination chain

If the source chain token is locked (or destroyed), the user can return the wrapped token on the destination chain to unlock the underlying asset on the source chain.

In the case of Edge and ChainBridge, unlike some solutions earlier in this paper, the validators of the supernet and the bridge are not necessarily the same.

This is in contrast to the strong argument in independent multi-chain architectures that a shared validator set for chain-level and communication-level consensus results in 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 properly incentivized.

Polygon has made an interesting design related to speed and security. By sharing the validator set and consensus mechanism, Polygon provides sufficient shared security. At the same time, by letting each supernet maintain its own state, it avoids the overhead faced by Polkadot and others, allowing a theoretically unlimited number of supernets to be built.

V. Binance BAS

overview

overview

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 for each chain. The BAS chain is the only application-specific blockchain covered in this article, and should share neither consensus nor state, and each BAS has its own independent set of validators. If you want to associate with BSC, you may only use the shared toolkit for developers to build side chains and the external bridge connecting 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 carry some calculations of the BNB Beacon chain. This is interesting, but we will focus on the discussion of application-specific sidechains in this article.

Consensus, Finality, and Validator Sets

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, this means that shared security guarantees are extremely limited, and the only tools Binance provides developers are toolkits for building their own blockchains. If the validator set can be made larger, or have high trust sharing across all sidechains, then building a project with Binance is worth considering. However, BAS is more suitable for project construction that only requires low consensus sharing.

Interoperability

Interoperability

Like any set of sovereign blockchains, the 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 through "locking + casting", 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 appealing as building a standalone blockchain, since any standalone blockchain could theoretically be connected via these bridges. One point to note is that objectively this is not a bad design, but for developers, they have no strong reason to choose to build projects within this ecosystem, it is better to choose to directly build an independent architecture.

The side chains under the BAS architecture do not share verifiers, consensus or state, and the verifier set of each chain is small, resulting in a short time to finality and a large number of chains that can be accommodated.

in conclusion

in conclusion

Application-specific blockchains have been an important part of the scalability discussion for some time, although its implementation has been hampered by a fledgling interoperability infrastructure. 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 the creation and development of more use-case-specific sub-application layers (such as Acala on Polkadot) and application-specific execution environments.