Flavors of Standalone Multichain Architecture

Overview

Scalability has long been a widely discussed topic in the space, with conversations around monolithic vs. modular blockchains and horizontal vs. vertical scaling having long dominated community discourse. One popular idea that has grown out of this discourse is that of building dedicated execution environments, and sometimes even finality gadgets, for specific applications or use cases. The idea being that, by optimizing consensus and compute based on the security and speed needs of each application and separating them, one could theoretically alleviate the load on a single underlying blockchain and optimize performance. One historical constraint with this approach has been the complexity of infrastructure required to ensure interoperability under this architecture.

Over the past few years significant progress has been made in alleviating these challenges in a variety of different ways. Importantly, communication layers, arguably the most important piece of the puzzle, for several standalone multichain environments have gone live over the past few months. In tandem, over the past weeks, more L1/L2 blockchains have announced modifications to their architecture to offer out-of-the-box infrastructure for application specific blockchains, reinvigorating this discourse.

In this piece, we take a detailed look into the various forms of architecture that have been developed in pursuit of this vision and compare the tradeoffs they make around shared consensus, capacity and interoperability. Specifically we look at five pieces of standalone multichain architecture: Polkadot, Cosmos, Avalanche, Polygon Supernets and Binance BAS.

Note: This piece focuses largely on standalone multichain infrastructure, where application specific blockchains share either validator sets or consensus algorithm.

Comparison Matrix

The degree of connectedness in a standalone multichain ecosystem can range from sharing as little as developer toolkits to sharing as much as validator sets, finality gadgets and state. No one approach is objectively better than the others, but each optimizes for varying degrees of shared security guarantees and speed/capacity.

In this piece we compare these ecosystems across five key parameters:

1. Consensus

There is no inherently superior consensus mechanism between these ecosystems, given that all meet base requirements around sybil resistance, time to finality etc. What is interesting to compare, however, is: i) the specific types of consensus model, ii) shared vs. independent consensus mechanisms for each chain, iii) shared vs. independent token incentives. Chains may adopt the same consensus mechanism (e.g. Tendermint BFT), but validators for each chain may be incentivized by their own independant token, and vice versa, depending on the parameters of the ecosystem. Shared consensus mechanism and token incentives imply greater security guarantees from the base layer, while optionality for independence offers greater design flexibility.

2. Finality/State

While individual chains maintain some form of independent state in each of these ecosystems, there are some where finality is reached at an aggregate level. This offers i) greater security and ii) more integrated interoperability. However, this comes with the trade off of capacity constraints where, if the number of modular blockchains exceeds a certain number, time to finality will slow down considerably.

3. Shared validator set/node autonomy

In addition to sharing consensus mechanism, individual blockchains can also share validator sets. In the examples below, validator sharing can range from a single validator set across all chains to multiple validator sets where each set provides consensus for some but not all underlying blockchains to mutually exclusive validator sets for each underlying blockchain. Shared validator sets offer concentrated security guarantees, in that the marginal risk for each new blockchain is lower, but the impact of a compromise in a critical mass of nodes could adversely impact all chains secured by that validator set. The ideal outcome for this parameter is a single validator set that is sufficiently distributed and provides shared security guarantees to a large number of chains. On the other hand, the most risky outcome is a single validator set with a small number of concentrated nodes.

4. Interoperability architecture

Most projects covered in this piece employ burn+mint or lock+mint bridging architecture. What differentiates these systems is: i) routing i.e. whether messages and tokens go through a single validator set with some notion of global state observation or whether each route is independent and ii) whether the validator sets that secure these routes are shared with the ecosystem or outsourced to third-parties. The closer an ecosystem gets to independent routes and third-party validator sets, the weaker the argument becomes for a new chain to launch as part of the underlying ecosystem vs. launching independently and connecting to other blockchains via general purpose third-party bridges.

5. Speed and capacity

Speed and capacity are largely symptoms of the aforementioned design choices and can be measured via time to finality and maximum number of chains that an ecosystem can support. For example, a construct with shared finality and a single global state will only be able to accommodate a certain number of chains before time to finality slows down considerably. This is a tradeoff for greater security guarantees.

Below is a high-level overview of how these five ecosystems compare across these parameters. Through the rest of the piece, we will break each of these pieces down for each of these ecosystems and discuss the benefits and shortcomings of each design choice.

I. Polkadot parachains

Overview

Polkadot is one of the earlier efforts in this space and was built to support application specific blockchains that share a single global state. Under Polkadot architecture, application specific blockchains (parachains) share compute and consensus resources with an underlying blockchain, called the relay chain, whose primary function is to maintain a unified global state.

Consensus, Finality & Validator Set

Polkadot runs Nominated Proof of Stake Consensus at the relay chain level. Under this architecture, there are three types of nodes:

• Nominators: Nominators select trustworthy validators and stake some of their DOT behind them. They share in validator rewards and are simultaneously slashed if validators engage in malicious activity.
• Validators: Validators on the relay chain participate in block production and consensus. The difference vs. standalone monolithic blockchains is that relay chain validators must reach consensus on the state of multiple individual chains vs. individual transactions.
• Collators: Collators aggregate transactions on a particular parachain and proposes a candidate block of transactions, along with a state transition proof, to relay chain validators. Each collator maintains one node on the relay chain and one node on the specific parachain it is working on. They accumulate transactions on their parachain and create an unsealed block to provide, together with a proof of state transition, to one or more relay chain validator. The block is not considered final until relay chain validators reach consensus.

While parachains share a single global state machine they are free to choose the specific consensus algorithm that they run (GRANDPA vs Tendermint vs traditional pBFT etc) to achieve parachain-level validation prior to settlement on the relay chain (Polkadot / Kusama).

One 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): Validators are chosen to order and produce blocks for 6 second slots based on value staked and Polkadot’s randomness cycle. As a result of this random selection, each slot could have one, multiple or no block producer candidates. In the event that there are multiple validators selected for one slot, block production becomes a race. In the case that no validators are selected for a slot, a secondary round-robin style selection occurs. Once a block is produced, it is gossiped to the rest of the validators.
• Finality gadget: GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement): Once a relay chain block is gossiped to the rest of the network, it requires a 2/3rd majority to be added to the chain. What is unique about GRANDPA, however, is that it reaches agreements on chains rather than blocks. This means that when it attests to a chain containing a certain block, all blocks leading up to that one are finalized at once i.e. “constant time” block advancement, as contrasted with traditional block-by-block finality.

Ultimately Polkadot takes the highest security approach to consensus, while providing some level of flexibility to parachains. Each parachain can make design choices on chain level “consensus” to propose blocks to the relay chain, however finality is only achieved on the Polkadot relay chain, secured by a single set of validators that must stake the DOT token to participate. With ~100 active validators (with a maximum of 1,000) and a maximum of 256 nominators per validator, Polkadot’s shared validator set provides a high degree of security guarantees to parachain projects by sacrificing some design flexibility. Another tradeoff of the high shared security guarantees offered by aggregate consensus at the relay chain level is that there is a fixed number of parachains after which time to finality would slow down substantially.

Interoperability

Within this architecture these components, particularly parachains, communicate with one another via a Polkadot-specific communication standard called XCM, which stands for cross-consensus messaging.

At a high level, all messages in Polkadot’s cross-chain messaging system pass through the relay chain, thereby inheriting its security. There are two types of messages that can be passed:

• Upward Message Passing UMP: Messages traveling from a parachain to the relay chain
• Downward Message Passing DMP: Messages traveling from the relay chain to one of the parachains
• Messages coming into a parachain are called ingress while those going out are called egress

Here is how the process of a message passing from parachain A to parachain B would work:

• Parachain A issues UMP as part of an egress  batch that is gossiped to all validator nodes on the relay chain
• Collator nodes on parachain B will search for new ingress messages every time they submit a new block candidate to the relay chain
• ingress messages are added to the processing queue for parachain B and will be passed to the validator nodes in the next block proposal
• In the case of asset transfers, the underlying asset is burned on parachain A and re-issued on parachain B as part of this process

Given that all messages pass through a single single set of validators (shared with the Polkadot relay chain) that observe global state, and that all chains are built on the same standard, making burn+mint efficient, Polkadot’s interoperability layer is one of the most efficient and secure in the space. This makes the case for new projects to build within the ecosystem stronger, given that they can use XCM to seamlessly connect with existing parachains and borrow those network effects to bootstrap.

Speed & Capacity

A tradeoff of having higher shared security guarantees is that there is a number of parachains after which time to finality would be meaningfully impacted. In the case of Polkadot that is estimated to be around 100. Polkadot manages this constraint by making parachain usage a rent-based activity. Projects can bid for parachain slots via DOT staking with community support for fixed-term hold periods. Once the slot expires, they must re-bid against other participants to retain the slot. This acts as a default curation mechanism for projects with the most activity and community support, partially circumventing these capacity constraints. This also means that the barriers for new projects to bootstrap and join this ecosystem are relatively high.

II. Cosmos

Overview

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 the other ecosystems covered in this piece, Cosmos is built on the premise that smart contract based virtual machines have limited flexibility, sovereignty and performance. Therefore, rather than build a single virtual machine on which multiple applications can run, Cosmos encourages and facilitates the creation of individual blockchains for each use case. Under this construct, application developers have flexibility around specific architecture, language etc. when building, and interoperability is achieved via Cosmos’ multi-chain communication layer, IBC (more on this later). Individual blockchains are called Zones while the connectivity modules are called Hubs.

Consensus, Finality & Validator Set

Within the Cosmos ecosystem, unlike in Polkadot, each application specific blockchain maintains its own independent state, reaching standalone finality on each block. With the Cosmos SDK, developers need only define the state machine (i.e. the application) and can rely on Cosmos’ Tendermint Core, a shared software layer, to facilitate consensus and networking. Tendermint runs a BFT-based consensus algorithm that validators on each individual Zone can leverage to facilitate state transitions and maintenance of an independent state (more on BFT consensus here). On each blockchain / zone, at every epoch a validator is randomly selected to propose the next block; the block is considered valid if >2/3rd validators attest to its validity. The validator set and specific incentive design can be defined at the state machine/application level.

Given that Tendermint is a shared software layer, each blockchain/Zone must connect to it through a dedicated interface called ABCI (Application Blockchain Interface). Transactions from individual Zones are passed to the Tendermint core as transaction bytes via ABCI, validators order these bytes deterministically and pass back code via ABCI to the state machine attesting to the validity of these transactions.

Each Zone in the Cosmos ecosystem is connected to a Hub that is expected to act as a router between the multiple Zones connected to it (more on this later). The Cosmos Hub is currently secured by a ~150 validator set and also operates on Tendermint consensus. Given that each Zone maintains its own state and and defines its own incentive mechanism via its own token, Hub validators are not required to participate in the consensus of each Zone. However, in practice, the overlap in validators securing the Hub and associated Zones is meaningful, given that they all run the same consensus algorithm.

Overall, Cosmos chooses a slightly different trade off vs. Polkadot where chains share a consensus mechanism but maintain independant state and are not mandatorily secured by the same validator set and incentive mechanism. Shared consensus provides a degree of security, while independence on defining incentive mechanisms and maintaining independant state provide design flexibility to each project. Standardized consensus also leads to higher validator overlap which, with a large distributed validator base, adds to shared security, though not to the same degree as on Polkadot. One initiative that Cosmos began laying the groundwork for in late 2021 is that of introducing shared / interchain security. Under this proposed framework, individual chains will be able to borrow from / share security guarantees with 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 consensus on both. Tokens staked on the Hub will act as shared collateral for honest consensus in both places, where malicious activity on either front would result in slashing. This would increase the available shared security guarantees available to new chains spinning up.

Interoperability

Given that each Zone is sovereign and maintains an independent state, communication between Zones becomes increasingly important. Cosmos facilitates this via Hubs that observe the state of every Zone that is connected to them and act as routers between these Zones. The Cosmos Hub  is the first Hub in the Cosmos ecosystem and one which a majority of early, high value Zones are connected with. Via the Cosmos Hub, the connected Zones can communicate messages to one another. The specific architecture through which this happens is called Inter-Blockchain Communication, or IBC for short. IBC Clients are light clients that track the consensus states of individual chains, along with the proof spec necessary to properly verify proofs against the client's consensus state.

Token transfers, under IBC architecture, start with each chain receiving headers from the other, such that they can track each other’s validator set. The sending address on the source chain then sends a coin packet that is recorded by the Hub. The Hub validators, must reach consensus on the validity of the transaction and lock those tokens in a contract on the source chain. The Hub then posts a proof on the destination, proposing the minting of a wrapped representation of these locked assets on the destination chain. Validators on the destination chain then match the proof against the header of the source chain and subsequently approve this function in the next block for the wrapped asset to be minted on the destination chain. If this does not happen, the locked assets on the source chain are returned to the sender address. Wrapped representations can subsequently be burned on the destination chain, via the Hub, to facilitate an unlock of the underlying asset on the source chain.

Given that routing is governed by a single, sufficiently distributed validator set that observes state across all Zones, as well as the fact that most of these validator are shared with individual blockchains, Cosmos offers a sufficient level of security guarantees around cross-Zone message passing. This also makes the case for building within the Cosmos ecosystem stronger, given that points of failure are concentrated and sufficiently decentralized.

Speed & Capacity

As a result of not centralizing finality onto a single chain, Cosmos is able to have a theoretically infinite number of Zones, as well as Hubs. Therefore, unlike with Polkadot, there are also no barriers for new projects to spin up a new chain. The tradeoff here is offloading some of the security guarantees to the Zones (by leaving it up to them to design their incentive mechanism and attract validators) in exchange for greater design flexibility and higher capacity to accommodate more individual blockchains.

III. Avalanche subnets

Overview

Avalanche is as an ecosystem of blockchains validated by multiple groups of nodes (called subnets). Subnets are free to choose their own consensus mechanism, including variations of Avalanche’s novel repeated random subsampling based consensus. Each blockchain within a subnet shares computational and consensus resources, but ultimately maintains its own state without any notion of a shared global state.

Consensus, Finality & Validator Set

To better understand Avalanche architecture it is important to understand 3 key components.

• Avalanche Consensus

Repeated random subsampling: Avalanche consensus is built on the Snowball algorithm which leverages repeated random subsampling to achieve consensus. Under this system, each node randomly queries some k number of neighboring nodes on whether a transaction is correct. This process is repeated until a certain pre-defined quorum x is achieved and nodes are certain within a high tolerance of confidence (at least the probability of a hash collision on Bitcoin), that the network agrees on the validity of a transaction.

Avalanche vs Snowman Consensus: Snowman and Avalanche are the two primary PoS-based consensus models in the Avalanche ecosystem that use repeated random subsampling. The difference between the two is that Avalanche adopts DAG (directed acyclic graph) architecture, while Snowman is built for linear blockchains. The key differentiator between linear blockchains DAG-based systems is that finality in linear blockchains is sequential, while in DAG-based systems it is closer to a mesh of transactions with non-sequential finality. A deep dive into DAG-based architecture demands a separate report, but those interested can find a high level description here. Blockchains within the Avalanche ecosystem may choose to use either consensus model, or even adopt their own.

• Subnets

Subnets are sets of validators that can provide consensus on a number of blockchains within the Avalanche framework. Each blockchain will have exactly one subnet, but each subnet can validate multiple blockchains. Because each blockchain is independently verified and global state is non- linear across blockchains, blockchains do not have shared security.

• Virtual Machines

Virtual machines dictate the application-level logic of the blockchain. Rather than have a single set of opcodes to process state, state transitions etc., Avalanche expects to have a suite of options for each individual blockchain to choose from. Current options include subnet EVM (EthereumVM built for subnets), AvalancheVM (DAG chain), SpacesVM (a key:value storage VM) and BlobVM (binary data storage VM). Beyond this, projects are free to implement their own custom VM.

The promise of Avalanche’s architecture is premised on the fact that these three components lend themselves to a modular framework that can scale super-linearly with subnet/validator growth.

Under Avalanche’s current form, there is one primary network secured by all participating Avalanche validators, with three blockchains under it:

• P Chain: linear blockchain based on Snowman consensus, meant for tasks such as creating validators, adding delegators, creating subnets etc.
• X Chain: DAG-based blockchain based on Avalanche consensus, meant for exchange of assets
• C Chain: linear blockchain with Snowman consensus, runs EVM and is meant for general purpose smart contracts

Various permutations of these validators can subsequently form subnets that validate incremental participating blockchains.

Overall, each blockchain in the Avalanche ecosystem maintains its own state and has the independence to select its own i) consensus mechanism, ii) validator set, and iii) incentive design. Blockchains within the same subnet benefit from greater shared security guarantees that come with a shared validator set provided that it is sufficiently distributed.

This is certainly the case for the default subnet that has ~1,450 validators today, though it remains to be seen how this translates to newer subnets. Simply put, the tradeoff Avalanche makes is offloading a greater degree of security guarantees to each subnet, in exchange for greater flexibility.

Interoperability

Given the level of modularity in this architecture and the fact that there are multiple concurrent states for different chains within the ecosystem (vs a single global state), cross-chain and cross-subnet communication become important questions to answer.

• Cross-chain transfers within a single subnet: This problem is somewhat easier to solve, given that each subnet has a single set of validators for all blockchains within that subnet. An example we can take to understand this is the transfer of assets between X, C and P chains in the primary/default subnet. Given that 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 a part of the next state transition of the receiving chain. Therefore, when there is a user request to transfer Z from X chain to C chain for example, subnet validators must first agree to burn Z on X chain and subsequently mint Z on C chain. This process is made easier by the fact that it is the same set of validators contributing to consensus on all chains within the subnet.
• Cross-chain transfers across different subnets: Cross-chain transfers become more challenging across different subnets since the validator set is no longer the same. In this case, external bridges with third-party relayers become important. Current Avalanche architecture has a module to deploy bridges between multiple subnets. Each instance can be customizable as either i) burn and mint OR ii) lock and mint. Unlike, single subnet transfers, this relies on a third-party relayer to observe the burn or lock on the sender chain and relay this message to the receiver chain to initiate the mint. Here’s an overview of an instance of an implementation to bridge the WAGMI and Fuji subnets:

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

Avalanche’s in-subnet messaging is at par with the likes of Cosmos and Polkadot, where there is a single set of validators that observes the state on each chain and facilitates transfers. As long as this validator set is sufficiently distributed, it comes with reasonable shared security guarantees, which is a strong case for new chains to be built within that subnet. However, messaging between subnets is still a work is progress and currently relies on a third-party relayer. So long as this third-party bridge comes with its own security guarantees, this is a reasonable outcome. Though it does make the case for deploying within existing subnets stronger than that for deploying new subnets.

Speed & Capacity

Similar to Cosmos, the decision to have distributed state comes with the ability to support multiple standalone blockchains. With flexibility around consensus mechanism and validator set, some blockchains within the Avalanche ecosystem could also have shorter block times depending on the number of participants in each subnet; e.g. outside of C-chain, where time to finality is 2 seconds, all other chains currently have sub-second finality.

IV. Polygon Supernets

Overview

Polygon has been the latest in a series of ecosystems to announce out-of-the-box application specific blockchains, called supernets. Similar to the Cosmos SDK, Polygon has a modular framework called Edge that facilitates the creation of standalone networks. Users can leverage the framework to deploy either shared security or sovereign blockchains. Both chain types maintain independent state, however shared security chains leverage a shared set of validators, while sovereign blockchains deploy their own.

Consensus, Finality & Validator Set

There are two types of consensus that can be employed on a supernet:

• IBFT PoA (Istanbul BFT Proof of Authority): Default consensus for Polygon Edge. Fixed validator set, where validators can be added and/or removed by majority (51%) vote. Consensus is achieved by supermajority (2/3rd) vote. Validators take turns proposing new blocks in a round-robin fashion. More appropriate for sovereign blockchains under the supernet framework.
• PoS: This follows traditional PoS architecture, where any network participant may stake tokens to become a validator. Validators are reward in network tokens and slashed for malicious behavior. Unlike other frameworks we have seen thus far, all shared security supernets have the same set of validators, where each validator must stake MATIC on Ethereum in order to participate in consensus on the supernets, and are paid in MATIC for non-malicious participation. While there is no concept of a shared global state, as in Polkadot, shared security is derived from the fact that each Polygon supernet shares the same validator set.

With ~200 validators participating in the shared security PoS module, incentivized by the MATIC token, supernets architecture offers robust shared security guarantees. In exchange projects must be willing to sacrifice flexibility around designing their own incentive mechanism and having their native tokens associated with consensus. A very viable tradeoff for projects focused on building performant applications vs. their own computation layer for other applications.

Interoperability

The Polygon Edge framework leverages a bridging solution called ChainBridge to facilitate communication, including but not limited to token transfers, between supernets. Similar to solutions we have seen earlier in this piece, this is how the process works in the case of token transfers:

• Tokens are either locked or burned on the source chain
• Relayer observes this action on the source chain and conveys the message to the destination chain
• A representation of the source chain token is minted on the destination chain
• In the event that source chain tokens were locked (vs. burned), the user may return the wrapped representation on the destination chain to unlock the underlying asset on the source chain

In the case of Edge and ChainBridge, unlike with some of the solutions from earlier in this piece, validators for supernets and the bridge are not necessarily the same.

This departs from one of the strong cases for standalone multichain architecture, which is that a shared validator set for chain-level and communication-level consensus leads to fewer points of failure. That said, given the other shared security features that Polygon offers, this is likely not a critical factor if the bridge validator set is also sufficiently distributed and appropriately incentivized.

Speed & Capacity

Polygon makes an interesting design decision as it relates to speed and security. With a shared validator set and consensus mechanism, Polygon offers a sufficient shared security guarantees. Simultaneously, by having each supernet maintain its own state, it avoids the overhead that Polkadot and others face, enabling a theoretically unlimited number of supernets to build.

V. Binance BAS

Overview

Binance Application Sidechains (BAS) is BSC’s modular framework for application specific blockchains. The initial version of BAS is expected to be a series of PoS side chains with between 3-7 validators, depending on the level of security required by each chain. BAS chains are the only application specific blockchains covered in this piece that are expected to share neither consensus nor state, with each BAS having its own independent validator set. Association with BSC will be limited to the shared toolkit available for developers to build their own side chain, as well as the external bridges expected to connect BAS chains to BSC.

In addition to BAS, Binance is also building a general purpose execution environments, similar to Ethereum L2s called BNB Chain Partition Chains (BPC), which will be used to offload some of the compute from the BNB Beacon chain. While this is interesting, we will focus on application specific side chains in this piece.

Consensus, Finality & Validator Set

Each BAS chain will have its own set of 3-7 validators that are expected to run PoS based supermajority (2/3rd) consensus. Unlike Polygon supernets, each BAS chain will operate using its own staking and utility token. Additionally, state and state transition for each side chain will be entirely independent from the others.

Binance perhaps has one of the weakest propositions in the space. With each chain having a small, independant validator set and maintaining its own state, implying limited shared security guarantees, the only thing that Binance offers developers is a toolkit to build their own blockchain. If the validator set were expected to be larger, or were a shared high trust group across all sidechains, there may be a stronger reason for new projects to build as part of this ecosystem. However, as it stands, BAS is likely best suited for projects that require relatively low shared security guarantees.

Interoperability

Like any set of sovereign blockchains, BAS chains will require third-party bridges to communicate with one another. In this case, BSC will leverage Celer’s third-party bridge to connect to each BAS, as well as for each BAS to connect with one another, via lock+mint mechanics (as described in detail earlier in this piece).

By employing a third-party bridge with an independant set of validators, Binance’s case for projects to build as part of their ecosystem vs. build a standalone blockchain becomes weaker, given that any standalone blockchain could theoretically be connected by these bridges. To be clear, this is not an objectively bad design decision, just not a strong case for developers to build within this ecosystem vs. build standalone.

Speed & Capacity

Given that side chains under the BAS architecture don’t share validators, consensus or state, and the fact that the validator set for each chain is small, time to finality is likely short and the number of accommodatable chains large.

Conclusion

Application specific blockchains have been an important part of scalability discourse for some time, though their implementation has been limited due to less mature interoperability infrastructure. With this infrastructure going live over the past few months across various standalone multichain ecosystems, we expect to see increasing activity in this space - including but not limited to the creation and growth of more use case specific sub application layers (e.g. Acala on Polkadot) as well as application specific execution environments.

Overall, each project in this space makes different tradeoffs on speed/capacity vs. shared security. The ones that will attract the highest level of developer activity are likely to be the ones that offer a balanced tradeoff between the two.

Special thanks to Nihar Shah (@theshah39), Anirudh Suresh (@anihamde), Hendrik Hofstadt (@hendrikhofstadt), Maher Latif (@maherlatif_) and Saurabh Sharma (@zsparta) for providing valuable feedback.