With the rise of the APP Chains, what is its past life, present life and future?

Compilation: Bai Ze Research Institute

While the initial applications of blockchain revolved around money and finance, the past few years have seen a surge in applications in areas such as art, gaming, and music. At the same time, the number of aggregated users in these applications has been growing linearly, stressing the underlying infrastructure and degrading the user experience. Additionally, as these applications scale, they increasingly require more customizability and stronger business models.

An emerging business model to address these issues is to build application -specific blockchains called “AppChains”. Applications building AppChains can customize multiple layers of their stack, such as their security model, transaction fees, and write permissions.

AppChains are not a new concept; Bitcoin can be thought of as an application-specific blockchain for digital gold, while Arweave can be used for permanent storage. That is, AppChain is designed to include not only a monolithic blockchain (e.g., Osmosis), but also a modular execution layer (e.g., rollups, sidechains, plasma) that handles application state transitions, but relies on a separate settlement or consensus layer to achieve finality.

• The ATOM 2.0 white paper is about to be released, can the value capture capability of Cosmos be improved?
• Technical Guide | Teach you how to build a commercial DAO without a bank
• LikeCoin wait 21 days to cancel the delegation? Talk about Cosmos's proof of bound equity BPoS

In fact, “layers” (such as L2, L3, etc.) in most cases are just trust-minimized blockchains with bidirectional trust-minimized cross-chain bridges.

In this article, I will:

• Overview of the history of AppChains
• Explain the advantages and disadvantages of AppChains
• Describe the future AppChain market structure
• An overview of how AppChain is designed
• Compare different AppChain solutions currently available

The past and present of AppChains

It took many years for AppChain to emerge. While Cosmos and Polkadot proposed and popularized the concept back in 2016, they did not fully launch their networks (with IBC and parachain capabilities, respectively) until early 2021. At the same time, in terms of scalability, due to the increasing demand from users on Ethereum , ETH transaction fees have become insanely high by the end of 2020, and application developers are in desperate need of alternative solutions. Meanwhile, Ethereum off-chain scalability research is slowly being implemented in the form of “L2s”, with Polygon, Skale, zkSync (1.0), StarkWare (StarkEx), Optimism and Arbitrum all launching in 2020 and 2021.

Other base layers (“L1”) are also aware of the importance of supporting EVM (Ethereum Virtual Machine) as part of their business development efforts; Avalanche (C-Chain), NEAR (Aurora), Polkadot (Moonbeam) and Cosmos (Evmos) ) have launched EVM-compatible chains in 2020 and 2021.

In terms of application-specific design, Celestia introduced a novel modular design in 2019 (originally as LazyLedger) that separates the execution, settlement, and data availability layers of traditional monolithic blockchains, allowing specific Blockchain for applications without rebuilding the rest of the stack.

Today, there are multiple platforms offering AppChain infrastructure. While some of them currently only offer public block space (e.g. Optimism, zkSync), if there is enough developer demand, they will likely roll out to support a dedicated execution layer.

Furthermore, while the launch and interoperability issues of AppChains have historically been difficult, the adoption of AppChains by both developers and users has accelerated over the past few years. Axie launched their Ethereum sidechain Ronin in early 2021, DeFi Kingdoms announced a move from Harmony to the Avalanche subnet at the end of 2021, ~46% of the members of the Apecoin community still support building ApeChain, dYdX announced that their V4 version of the protocol will be built on On L1 built with Cosmos SDK. Today, there are countless applications built on AppChains.

Why choose AppChains?

There are three main reasons why developers are increasingly turning to building AppChains rather than launching smart contracts on public blockchains.

Performance

• Because dApps compete with each other on the same network, a popular dApp often consumes a disproportionate amount of resources, which increases transaction costs and latency for other dApp users.
• AppChains provides projects with the ability to stabilize transaction costs and low latency, thereby bringing a better user experience to users.

customizability

• As dApps become more popular, developers need to continue optimizing their dApps for users.
• Large dApps need to weigh certain design choices, such as throughput, finality, level of security, permissioning, composability, and ecosystem consistency. For example, a validator might have high-performance hardware requirements (such as running SGX or FPGA to generate zero-knowledge proofs).
• For traditional organizations, AppChains provides a way for them to enter Web3 without authorization; for example, companies can ask KYC verifiers to cull developers who want to build on their network and select them Which chains you want to connect assets to via cross-chain bridges.

value capture

• While common scalability solutions do reduce transaction costs while preserving security and developer experience, they offer developers few monetization opportunities.
• On the other hand, AppChains has a strong business case, as dApps are able to fork and monetize existing protocols within their ecosystem (e.g. transaction fees from AMM or NFT markets).
• Their tokens benefit from additional tokens being used as a security model (i.e. staking tokens or gas tokens).
• Additionally, applications are able to capture MEVs by running their own sequencers or validators, which can create opportunities for new crypto business models; for example, validators (possibly market makers) on dYdX can offer users low or no fees fees, but give them a slightly lower strike price, similar to the pay-to-order model used by Robinhood.
• As another example, many successful games have tons of mods, skins, etc. and actively try to tweak as many as possible. But most of the time, modeling is done by amateur gamers who struggle to make money. If the game is built on AppChain, modders can extend the IP on top of rollup and monetize using the chain.

Problems with AppChains

However, everything is a double-edged sword:

Limited composability and atomicity

• AppChains isolates infrastructure and users in other ecosystems to a certain extent. While this doesn’t break composability (you just need good enough bridges on the same VM), it does break atomicity (an all-or-nothing property where all Either all sub-operations are executed, or none of them are executed).
• That said, while atomicity is a special property for all applications to be in the same settlement layer, it is not important for many applications (for example, P2E games do not rely on flash loans to keep the economy running).

Rebuild the Walled Garden

• As a thought experiment, if all AppChains had read/write permissions, the resulting market structure would limit developers’ permissionless and combinatorial innovation, as well as users’ ability to freely transact, which would bring Crypto back to what it was designed to solve. problem.

Liquidity dispersion

• Liquid assets from other layers or chains will require cross-chain bridges to connect to AppChains, and while this is possible through bridge infrastructure, it adds additional “friction” for users.

Reflexive Security Model

• If an application token is used as a security model, there is an edge case where if the price of the token drops to 0, the application will no longer be economically secure.

waste of resources

• AppChains can waste resources (physical or economic) if the application is not used enough. If AppChain has dedicated validators, those validators can more efficiently deploy their resources elsewhere.

extra complexity

• Because it is not as simple as deploying a smart contract, it adds additional complexity when managing additional infrastructure such as sequencers or validators.

Limited ecosystem tools

• There may be no “out of the box” resources such as block explorers, RPC providers, indexers, oracles and ecosystem funding.

Emerging AppChain Market Structure

Due to the many disadvantages of building in a more isolated ecosystem, AppChains are best suited for applications with the following characteristics:

• Achieved scale (e.g. number of users, protocol revenue, TVL) and product-market fit
• Performance can bring significant advantages to the product
• Fewer requirements for security and atomicity (e.g. P2E games, NFTs, encrypted social)

Therefore, it is reasonable to assume that most applications will continue to be launched on public L1 and L2. Also, as the L2 landscape is still fairly fragmented, we will see DeFi protocols continue to roll out on L1 due to their security, liquidity and atomic properties. Furthermore, if non-DeFi applications have a sufficiently large ecosystem and network effects, they may launch on a general-purpose L2 and move to an application-specific L3 or an application-specific L1. We can roughly imagine this sequence of operations as follows:

There is also a reason that most applications launching AppChains will choose modular execution layers (particularly rollups) over monolithic chains, as they do not have the capital needed to attract large validator swarms . Also, high-quality validators are less likely to choose to spend their resources on AppChain where token prices are low and unstable.

Nonetheless, as the crypto industry matures and becomes popular, more applications will continue to launch their own AppChains, and the future AppChain market structure will take many forms:

• AppChains connected via various cross-chain bridges
• Application-specific sidechains connected to L1
• Application-specific rollups that don’t use a billing layer

How AppChains are designed

There are several design tradeoffs to consider when deciding to build AppChain’s infrastructure:

Types of Security: How hard is it to change state through an attack?

• Shared: State secured by multiple heterogeneous validators, possibly run by different parties (e.g. Polkadot parachains, Skale)
• Isolation: Security provided by the application itself; may use application-owned validators or orderers, and use the application’s tokens for economic gain (e.g. Cosmos chain, Axie Ronin)
• Inheritance: Security provided by the underlying settlement/consensus layer (eg zkSync, Optimism)

Source of security: Where does security come from, and where does settlement come from?

• Ethereum: Use Ethereum as a settlement layer for fraud proofs, validity proofs, and general double-spending protection (e.g. Arbitrum, zkSync)
• Non-Ethereum L1: uses non-Ethereum security and may have a completely different consensus model (e.g. NEAR Aurora, Tezos rollups)
• Application Tokens: Use the application’s tokens as cryptoeconomic security (e.g. Avalanche Subnet, Cosmos Chain)

Permissions: How are nodes selected, and who can read/write state?

• Permissionless: Anyone can read/write contracts and verify state transitions (eg Optimism, StarkNet)
• Optional licensing: only whitelisted validators/developers can read/write/validate chains (e.g. Polygon Supernets, Avalanche subnets)

Composability: Is it easy and safe to move liquidity and state between other applications in the same ecosystem?

• All: move to any application with minimum latency and maximum security (e.g. Polkadot XCMP, Cosmos IBC)
• Limited: Limitations in connectivity, latency, or security (e.g. Avalanche subnets, Polygon Supernets)

Finality: When is a transaction considered final?

• Immediate: usually use BFT consensus mechanism (eg NEAR Aurora, Evmos)
• Final: Usually using rollups, once the block is published to L1 (and assuming the data is available), the transaction can be considered final (e.g. Arbitrum, zkSync)

Gas Tokens: Which Tokens do users use to pay transaction fees?

• Non-App Tokens: Typically, L1 or L2 underlying assets on which applications are built (e.g. Ethereum , Evmos)
• Application Tokens: Usually the application’s token itself runs on an application specific L1 or L2 (e.g. Avalanche subnet, Osmosis)
• No tokens: L1 or L2 validators or applications subsidize costs for users. (eg AltLayer, Skale)

There are several other more immediate factors:

• Stake Required: The amount of stake an application requires validators to secure its chain
• Transactions Per Second (TPS): A subjective measure of throughput, as transactions can vary in size (ie, larger transactions will result in lower TPS and vice versa)
• EVM Support: The ability to support both Solidity and EVM opcodes without requiring developers to modify their codebase

We can map existing AppChain solutions based on these factors:

in conclusion

Despite their problems with AppChains, their continued growth is indicative of developer demand. As Apple has proven, vertical integration often results in a better user experience; similarly, blockchain developers will be looking to provide fully optimized Web3 applications powered by AppChains. That said, AppChains are not for everyone, and developers should deeply consider/weigh the needs of their applications before committing resources to launch them.

AppChains has many implications for security model economics, monetization strategies, platform defensibility, overall value accumulation across the stack, and on crypto market structure that we will observe over the next few years.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!