Partnered With:

Jump Crypto: Explain the features, advantages and disadvantages of five chain architectures such as Cosmos and Avalanche

Read this article in 44 Minutes

Compare trade-offs in shared consensus, capacity, and interoperability for multi-chain architectures.

Interactive Multichain Architecture, Flavors of Standalone

Shanav K Mehta, Jump Crypto

Guo Qianwen, chain catcher

An overview of the

Extensibility has long been a topic of widespread discussion in the field. The discussion around monolithic blockchain versus modular blockchain, horizontal versus vertical scaling has long been the focus of community communication.

This has led to a popular idea of creating specialized execution environments or even finality tools for a particular application or use case. The idea is to separate and optimize consensus and computing based on the security and speed requirements of each product and each application, which in theory could reduce the load on a single underlying blockchain and improve its performance. But this approach suffers from the fact that the infrastructure needed 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, several communications layers for standalone multi-chained environments have come online, arguably the most important pieces of the puzzle. At the same time, in the past few weeks, more L1/L2 blockchains have announced changes to their architectures to provide an out-of-the-box infrastructure for application-specific blockchains, reinvigorating the discussion once again.

In this article, we examine in detail the various forms of architecture being developed in pursuit of this vision and compare their trade-offs in terms of shared consensus, capacity, and interoperability. Specifically, we looked at five separate multi-chain architectures: Polkadot, Cosmos, Avalanche, Polygon Supernets, and Binance BAS.

Note: This article focuses on standalone multi-chain infrastructures, where the blockchain for a particular application shares groups of verifiers or consensus algorithms.

Comparison of standard

Independent multi-chain ecosystems can be connected to varying degrees, from shared developer toolkits to shared sets of validators, final tools, and states. Objectively speaking, each approach has its own advantages, but each optimizes the maintenance and speed/capability of shared security to some degree.

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

1. The consensus

所有的生态系统都满足了关于女巫攻击防御、最终性实现时间等基本要求，因此本质上并没有最优共识机制。然而，值得比较的是：1）共识模型的具体类型，2）每个链的共享或独立的共识机制，3）共享或独立的Token激励。链可能采用相同的共识机制（如 Tendermint BFT），但每个链的验证者受自己独立的 Token 激励，反之亦然，这些情况取决于生态系统的参数情况。共享的共识机制和 Token 激励意味着基础层能提供更大安全保障，而选择独立则意味着更大的设计灵活性。

2. Finality/state

In these ecosystems, some chains remain in some form of independent state, while others are final at the level of the whole. This provides 1) greater security and 2) more integrated interoperability. However, there is a trade-off in capacity limits, and if the number of modular blockchains exceeds a certain number, the process of reaching finality will be greatly slowed down.

3. Share verifier group/node autonomy

In addition to sharing consensus mechanisms, individual blockchains can also share groups of verifiers. In the example below, the shared scope of verifiers ranges from a single set of verifiers across all chains, to multiple sets of verifiers (where each set of verifiers provides consensus for some but not all of the underlying blockchain), to mutually exclusive sets of verifiers for each underlying blockchain. A shared set of verifiers provides a centralized security guarantee due to the reduced marginal risk of each new blockchain, but a massive compromise on nodes would adversely affect all chains guaranteed by the set of verifiers. The ideal state for this parameter is a fully distributed set of single verifiers, providing shared security for a large number of chains. On the other hand, its riskiest state is a single group of verifiers with a small number of centralized nodes.

4. Interoperability architecture

这篇文章所涉及的大多数项目都采用了「销毁销毁+铸造」或「锁定+铸造」的桥接架构。这些系统的区别在于：1）路由，即消息和 Token 是否通过具有某种全局状态观察状态的单一验证者组进行，或每条路由是否是独立的；2）这些获取链路的验证者组是否由生态系统分享，还是外包给第三方机构。生态系统越接近独立路由和第三方验证者外包的状态，我们就越不推荐选择这个底层生态系统进行新链发布，不如直接与通用目的第三方桥连接，进行独立发布。

5. Speed and capacity

Speed and capacity are largely a characterization of the design choices described above 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 accommodate a certain number of chains, so the time to finality is greatly slowed down, a trade-off for greater security.

Below is a macro overview of these parameters for each of the five ecosystems. In the rest of the article, we break down each part of these ecosystems and discuss the pros and cons of each design choice.

I. Polkadot parachains

An overview of the

Polkadot was early in the field and was built to support application-specific blockchains that shared a single global state. Under the Polkadot architecture, application-specific blockchains (parallel chains) share computing and consensus resources with the underlying blockchains (called relay chains), whose primary function is to maintain a unified global state.

Consensus, finality, and verifier groups

Polkadot runs the proposed proof-of-interest consensus at the relay chain level. In this architecture, there are three types of nodes.

Nominees:

Nominees choose trusted verifiers and pledge some of their DOT to them. They share the validator's rewards, but they can also be slashed if the validator engages in malicious activity.

Validation:

Verifiers on the relay chain participate in block production and consensus. Unlike stand-alone blockchains, relaychain verifiers must agree on the status of multiple chains and individual transactions.

Reviewer:

The proofreader collects the transactions on a particular parallel chain and presents a block of candidate transactions and a state transition proof to the relay chain verifier. Each proofreader maintains a node on both the relay chain and the parallel chain on which he works. They accumulate transactions on their parallel chains, creating unsealed blocks that they provide to one or more relay chain verifiers along with state transition proofs. The block is not final until a consensus is reached by the verifier of the relay chain.

Although parallel chains share global state, they are free to choose the specific consensus algorithm they run (GRANDPA /Tendermint/ Traditional pBFT, etc.) to implement parallel chain level verification before settling on the relay chain (Polkadot/Kusama).

The Polkadot consensus is unique in that it separates block production from block finality; Operating under a hybrid consensus framework.

Block production mechanism:BABE (Blind Assignment for Block Extension) Block Extension random allocation

Based on the value of the pledge and a random cycle of Polkadot, verifiers are selected to place and produce blocks for 6-second slots. Under this random selection, each slot may eventually have one, multiple, or zero block production candidates. Block production becomes a race when more than one verifier is selected for the same slot. In the case that no verifier is selected, a secondary loop selection is made. Once a block is produced, the message is transmitted to other verifiers.

Final tool:GRANDPA (Ghost-based Recursive ANcestor Deriving Prefix Agreement) Recursive ANcestor derived Prefix protocol based on GOSHT

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. GRANDPA, however, is unique in that it makes agreements on chains rather than blocks. This means that when it validates a chain containing a block, all the blocks before that block are immediately finalised together, unlike the traditional block-by-block validation process.

最终，Polkadot 采取了最高安全性的共识方式，同时为平行链提供了一定的灵活性。每个平行链可以在链级「共识」上做出设计，向中继链提出区块，但是最终性只在 Polkadot 中继链上实现，由一组验证者保证，他们必须质押 DOT Token 进行参与。Polkadot 有大约 100 个活跃的验证者（最多 1000 个），每个验证者最多有 256 个提名者。它的共享验证者集牺牲了一些设计灵活性，以确保平行链项目有更高的安全保障。中继链层面上的集中共识能提供更高共享安全保障，但也会牺牲一部分性能：平行链数量是固定的，在这个数量之后，到最终性的时间会大幅度减缓。

interoperability

Under this architecture, these components, especially the relay chain, communicate with each other through Polkadot's unique communication standard XCM.

At a macro level, all messages in the Polkadot cross-chain messaging system are transmitted through the relay chain, continuing its security. There are two types of messages that can be delivered:

Upward-passing messages (UMP) : Messages from a parallel chain to a relay chain

Downward-delivered message (DMP) : a message from a secondary chain to one of the parallel chains.

Information that enters a parallel chain is called the ingress, and information that exits is called the egress.

Here is how A message passes from parallel chain A to parallel chain B:

Parallel chain A publishes the UMP, which is transmitted to all verifier nodes on the relay chain as part of the export batch.

The proofreader node on parallel chain B searches for a new entry message each time it submits a new block candidate to the relay chain.

The entry information is added to the processing queue of parallel chain B and will be passed to the verifier node in the next block proposal.

In the process of asset transfer, the underlying asset is destroyed on the A blockchain and reissued on the B blockchain.

Since all messages are passed through a single validator (shared with the Polkadot relay chain) observing global state, and all chains are based on the same standard, this makes the destroy + cast model efficient. Polkadot's interop layer is one of the most efficient and secure in the field. It is therefore recommended to build projects within its ecosystem, as XCM can be used to seamlessly connect to existing parallel chains and leverage these network effects to get started.

Speed and ability

The cost of having higher shared security is that the time to finality slows down dramatically after the number of parallel chains reaches a certain value. In Polkadot, parallel chains, estimated at about 100, are rent-paid to reduce the impact of this restriction. Projects can bid for slots on the parallel chain through DOT pledges with community support, and once slots expire, they must rebid with other participants to retain slots. This is the default management mechanism for projects with the most activity and community support, partly circumventing capacity constraints, but it also means that there is a relatively high barrier for new projects to join the ecosystem.

II. Cosmos

An overview of the

The Cosmos SDK is a suite of tools with out-of-the-box consensus and execution that allows anyone to create their own PoA/PoS blockchain. Unlike the other ecosystems covered in this article, Cosmos is built on the premise that smart contract-based virtual machines have limited flexibility, sovereignty, and performance. Thus, rather than creating 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 have the flexibility to build around a particular architecture, language, and so on, with interoperability through Cosmos' multi-chain communication layer IBC. A single blockchain is called a zone, and connected modules are called hubs.

Consensus, finality, and verifier 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 need only define state machines (i.e., applications) and can rely on Cosmos's Tendermint core (a shared software layer) to drive consensus and network connectivity. Tendermint runs a BFT-based consensus algorithm that validators in each separate zone can use to facilitate state transitions and maintain separate states. Within each blockchain/zone, a verifier is randomly selected for each era to propose the next block; A block is considered valid if more than two-thirds of verifiers prove it valid. The validator set and the specific incentive design can be defined at the state machine/application level.

Tendermint is a shareware layer, and each blockchain/zone must be connected to it through a dedicated interface called ABCI (Application Block Link Interface). Transactions from each district are passed to the Tendermint core via ABCI as transaction bytes. The verifier finally sorts these bytes and sends back code to the state machine via ABCI to certify the validity of these transactions.

Cosmos 生态系统中的每个区都与一个中心相连，该中心被认为是连接多个区的路由器。目前，Cosmos 中心由一个大约含有 150 个验证者的验证者组保障，在 Tendermint 共识上运行。鉴于每个区都保持着自己的状态，并通过自己的 Token 进行激励机制的设定，中心验证者不需要参与到每个区的共识中。然而在实际操作中，验证者维护中心以及相关的区，运行同样的共识算法，因此它们之间的重叠是有意义的。

总的来说，Cosmos 选择了一个与 Polkadot 稍有不同的权衡方式，即链共享共识机制，但各自保持独立状态，不强制要求由相同的验证者集和激励机制来进行保障。共享共识提供了一定程度的安全性，而独立定义激励机制和保持独立状态为每个项目提供了设计的灵活性。标准化的共识也导致了更多的验证者重叠，加上验证者本身的庞大分布，这也增加了共享的安全性，尽管程度不如 Polkadot。Cosmos 在 2021 年底开始进行准备工作，为的是引入共享/链间安全。在这个拟议的框架下，单链将能够从 Cosmos 中心借用/共享安全保障。验证者将能够运行两个节点，一个在中心上，一个在区上，并从参与两个节点的共识中获得费用和奖励。在中心上抵押的 Token 将作为两地诚信共识的共享抵押品，其中任何一方的恶意活动都会导致两方被「砍」(slash: 一般指质押品被移走)，这将增加新链可用的共享安全保障。

interoperability

As each zone is sovereign and remains independent, communication between zones becomes increasingly important. Cosmost observes the state of the regions connected to the center through the center, which acts as a route connecting the regions. The Cosmos Hub was the first Hub in the Cosmos ecosystem, with most of the early high-value zones connected. The connected regions can communicate with each other through the Cosmos Hub. The specific architecture for information exchange is called Inter-blockchain Communication, or IBC. The IBC client is a lightweight client that tracks the consensus state of each chain and the necessary proofs in order to correctly verify the proofs against the consensus state of the client.

在 IBC 架构下，从 Token 传输开始时，每个链就会收到来自对方的头部信息，以此追踪对方的验证者集。然后，源链上的发送地址发送一个硬币数据包，由中心记录。中心验证者必须对交易的有效性达成共识，并将这些 Token 锁定在源链上的合约中。之后中心在目的地发布证明，提议在目的地链上铸造这些锁定资产的包装 Token 。目的地链上的验证者之后将证明与源链头部进行匹配，随后在下一区块中批准这一功能，以便在目的地链上铸造被包装的资产。如果上述动作没有发生，源链上的锁定资产就会被退回到发送者地址。被包裹的资产代表随后通过中心在目的链上被销毁销毁，使源链上的基础资产能被解锁。

In Cosmos, routing is managed by a single, sufficiently distributed set of validators that observe the state of all the blockchains, most of which are shared with the blockchain, so that it provides sufficient security around cross-region messaging. This also provides a good reason to build within the Cosmos ecosystem because the points of failure are concentrated and sufficiently decentralized.

Speed and capacity

Because finality is not concentrated on a single chain, Cosmos can theoretically have an infinite number of regions and centers. Therefore, unlike Polkadot, it has no difficulty establishing new chains with new projects. The trade-off here is to offload some of the security to districts (letting districts design their own incentives and attract verifiers) in exchange for greater design flexibility and greater capacity to accommodate more individual blockchains.

III. Avalanche subnets

An overview of the

Avalanche is a blockchain ecosystem validated by multiple sets 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 the subnet shares computing and consensus resources, but ultimately maintains its own state, with no global shared state.

Consensus, finality, and verifier sets

To better understand its architecture, we must understand three key parts:

You just type consensus

It refers to repeated random subsampling. The Avalanche consensus is based on the Snowball algorithm, which uses repeated random subsampling to achieve consensus. Under this system, each node randomly questions k number of neighboring nodes to determine if 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 two major PoS based consensus models in the Avalanche ecosystem that use repeated random subsampling. The difference between the two is that Avalanche uses a DAG (Directed acyclic graph) architecture, while Snowman is built for a linear blockchain. 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 that of a transaction network with unordered finality. Blockchains within the Avalanche ecosystem can choose to use one of the two consensus models or adopt their own.

Subnets

Subnets are collections of validators that can provide consensus on some of the blockchains within Avalanche. Each blockchain has a subnet, but each subnet can validate multiple blockchains. Because each blockchain is independently verified, the global state is non-linear between blockchains, so there is no shared security between blockchains.

Virtual Machine (VM)

The virtual machine determines the application-level logic of the blockchain. Avalanche wants to give each blockchain a list of action codes to choose from to handle and transition states, rather than just one set of opcodes. Current options include Subnet EVM (EthereumVM built for subnets), AvalancheVM (DAG chain), SpacesVM (a key: Value Store Virtual Machine), and BlobVM (binary data store Virtual Machine). In addition, projects are free to implement their own custom virtual machines.

The Avalanche architecture only works if these three components fit into a modular framework that can scale superlinearly as subnets/verifiers grow.

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

P-chain: A linear blockchain based on snowman consensus, used for tasks such as creating verifiers, adding proxies, and creating subnets.

X Chain: A DAG type blockchain based on avalanche consensus for exchanging assets.

C-chain: A linear blockchain based on snowman Consensus that runs EVM for general-purpose smart contracts.

Various permutations of these verifiers can then form subnets to 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) set of validators, and 3) incentive design. Blockchains within the same subnet benefit from the higher shared security guaranteed by full distribution.

This is true for the current default subnet with about 1450 verifiers, although the conversion to the new subnet remains to be seen. In short, the trade-off Avalanche has made is to load more security into each subnet in exchange for greater flexibility.

interoperability

Given the modularity of the architecture and the fact that there are multiple concurrent states (as opposed to a single global state) for different chains within the ecosystem, cross-chain and cross-subnet communication becomes an issue of concern.

Cross-chain transport 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. An example would be transferring assets between the X, C, and P chains of the primary/default subnet. Since there are at least three concurrent states in this architecture, any asset Z must not exist in any account of the current state of the sending chain before it can become part of the transformation in the receiving chain. Therefore, when a user requests to transfer Z from the X chain to the C chain, for example, the subnet verifier must first agree to burn Z on the X chain and then cast Z on the C chain. This process is made relatively easy by the fact that the same set of validators are responsible for all on-chain consensus within the subnet.

Cross-chain transfers between subnets: Cross-chain transfers between subnets can be challenging because the set of verifiers is no longer the same. In this case, an external bridge to a third-party repeater becomes important. The current Avalanche architecture has a module for deploying Bridges between multiple subnets. Each instance can be customized to 1) destroy and coin or 2) lock and coin. Unlike monad network transmission, this relies on a third-party repeater to observe destruction or lockout on the sending chain and forward this message to the receiver chain to initiate minting. The following is an overview of the implementation examples for bridging WAGMI and Fujifilm:

Under the current setup, each pair of subnets requires a separate bridge, the repeater threshold can be as low as one, and the repeater execution is outsourced to Chainsafe. This is an acceptable short-term solution, but in the long run, a single bridge with a distributed repeater network may improve security.

Avalanche's in-subnet messaging is similar to Cosmos and Polkadot, with a single validator group observing the state on each chain and facilitating the transmission. As long as the set of validators is sufficiently distributed, it provides reasonable shared security, so this architecture is also recommended. However, the information transmission between subnets is still to be improved and currently relies on the third-party repeater, so as long as the third-party bridge has its own security guarantee, the result will be relatively reasonable. Therefore, it is better to deploy within an existing subnet than to deploy a new subnet directly.

Speed and capacity

Like Cosmos, Avalanche adopts a distributed state to support multiple independent blockchains. Due to consensus mechanisms and the flexibility of the verifier set, some blockchains in the Avalanche ecosystem can also have shorter block times based on the number of participants per subnet; For example, the C chain has a finality time of 2 seconds, and all other chains currently have subsecond finality times.

IV. Polygon Supernets

An overview of the

Polygon is the latest in a series of ecosystems to announce blockchains for specific applications out of the box, called hypernets. Similar to the Cosmos SDK, Polygon has a modular framework called Edge for easy creation of standalone networks. Users can use the framework to deploy shared security or sovereign blockchains. Both chain types remain independent, but shared security chains utilize a shared set of validators, while sovereign blockchains deploy their own validators.

Consensus, finality, and verifier groups

There are two types of consensus that can be used in a hypernet:

Istanbul BFT Proof of Authority: Polygon Edge's default consensus. Is a set of fixed verifiers, verifiers can add and/or remove verifiers by majority (51%) votes. Consensus is reached by a supermajority (2/3) vote. Verifiers take turns to propose new blocks. It is more suitable for sovereign blockchain under the framework of supernet.

PoS：遵循传统的 PoS 架构，任何网络参与者都可以质押 Token ，成为验证者。验证者在网络中接受 Token 奖励，或因恶意行为而被「砍」（slash）。与我们迄今为止看到的其他框架不同，所有共享安全超级网都有相同的验证者，每个验证者必须在以太坊上质押 MATIC，以便参与超级网的共识，并以 MATIC 支付非恶意的活动参与。虽然没有它像 Polkadot 一样的全局共享概念，但由于每个 Polygon 超级网共享相同的验证者集合，也可以获得共享安全性。

超级网架构用 MATIC Token 激励，有大约 200 个验证者参与共享安全 PoS 模块，提供了强大的共享安全保障。作为交换，项目必须牺牲自行设计激励机制的灵活性，并使用原生 Token 与共识相连。对于专注于建立高性能应用程序的项目来说，他们需要在自行搭建应用和自行搭建计算层之间做出取舍，后者的计算层可被其他应用使用。

interoperability

Polygon Edge 框架利用一个名为 ChainBridge 的桥接解决方案来促进超级网之间的通信，包括但不限于 Token 转移。与我们在本篇文章前面看到的解决方案类似，以下是 Token 转移过程：

1. Token 在源链上被锁定或销毁

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

3. 源链 Token 代表在目的链上被铸成

4. 如果源链 Token 被锁定（或销毁），用户可以在目的链上返回包装好的 Token ，以解锁源链上的基础资产。

In the case of Edge and ChainBridge, unlike some of the previous solutions in this article, the verifiers for the supernet and bridge are not necessarily the same.

This is in contrast to the strong argument in standalone multi-chain architectures that a shared set of validators for both chain-level and communication-level consensus leads to fewer points of failure. That said, given the other shared security features provided by Polygon, this might not be a critical factor if the set of bridge verifiers is sufficiently distributed with the right incentives.

Speed and capacity

Polygon came up with an interesting design related to speed and safety. Polygon provides sufficient sharing security through shared verifier sets and consensus mechanisms. At the same time, by letting each supernet maintain its own state, it avoids the overhead faced by Polkadot and others, and could theoretically build an unlimited number of supernets.

V. Binance BAS

An overview of the

Binance Application Sidechains (BAS) is BSC's modular framework for application-specific blockchains. The initial release of BAS is estimated to be a series of PoS side chains with 3-7 verifiers, depending on the level of security required for each chain. The BAS chain, the only application-specific blockchain covered in this article, should share neither consensus nor state, with each BAS having its own set of independent validators. The only way to associate with the BSC is probably through shared toolkits for developers to build side chains and external Bridges to connect the BAS chain to the BSC.

In addition to BAS, Binance is also building a generic execution environment, similar to Ethereum L2, called the BNB Chain Partition Chain (BPC), which will be used to host some calculations for the BNB Beacon chain. That's interesting, but we'll focus on application-specific side chains in this article.

Consensus, finality, and verifier sets

每个 BAS 链都会有自己的 3-7 个验证人，预计会运行基于 PoS 的超级多数（2/3）共识。与 Polygon 超级网不同的是，每个 BAS 链将使用自己的质押和实用 Token 来进行运作。此外，每个侧链的状态和状态转换将完全独立于其他侧链。

Binance offers perhaps one of the weakest architectures in the space. Since each chain has a small set of independent validators and maintains its own state, which means that shared security is extremely limited, Binance's only tool for developers is to build their own toolkit for blockchain use. If the set of verifiers can be larger, or if there is high trust sharing across all side chains, then Binance is worth considering. However, BAS is more suitable for the construction of projects that only require low consensus sharing.

interoperability

Like any set of sovereign blockchains, the BAS chain will need third-party Bridges to communicate with each other. In this case, BSC will use Celer's third party bridge to connect to each BAS via a "lock + cast" form, while each BAS is also connected via this mechanism.

Binance uses third-party Bridges with independent verifiers, and building projects in its ecosystem may not be as appealing as building a separate blockchain, since any separate blockchain could theoretically be connected through these Bridges. One point to make is that this is not objectively a bad design, it's just that there is no compelling reason for developers to build projects within the ecosystem, rather than directly building standalone architectures.

Speed and capacity

Side chains in BAS architecture do not share verifiers, consensus or states, and the set of verifiers of each chain is very small, resulting in a very short time to finality and a large number of chains.

conclusion

Application-specific blockchains have been an important part of the scalability discussion for some time, although its implementation is constrained by an immature interoperability infrastructure. In the past few months, this infrastructure has been coming online in various independent multi-chain ecosystems, so we expect to see more activity in this area as well -- 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.

In general, each project in this area makes a different trade-off between speed/capability versus shared security. The projects that succeed in attracting the most adoption are likely to be those that strike a balance between the two.