What is the past, present, and future of the application chain?

Author: Dmitriy Berenzon, 1kx Analyst

Compiler: Bai Ze Research Institute

While the initial applications of blockchain revolved around currency and finance, there has been a surge in applications in areas such as art, gaming, and music over the past few years. At the same time, the number of aggregated users in these applications has been growing linearly, putting pressure on the underlying infrastructure and degrading user experience. Furthermore, as these applications scale, they increasingly require more customizability and robust business models.

An emerging business model to address these issues is the construction of application-specific blockchains, referred to as "AppChains." Applications that build 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 considered a specific application blockchain for digital gold, while Arweave can be used for permanent storage. That said, the design of AppChains includes not only monolithic blockchains (e.g., Osmosis) but also modular execution layers that handle application state transitions (e.g., rollups, sidechains, plasma), while relying on separate settlement or consensus layers to achieve finality.

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

In this article, I will:

• Outline the history of AppChains
• Explain the pros and cons of AppChains
• Describe the future market structure of AppChains
• Outline how AppChains are designed
• Compare the different existing AppChain solutions

The Past and Present of AppChains

It took many years for AppChains to emerge. Although Cosmos and Polkadot proposed and promoted this concept as early as 2016, they did not fully launch their networks until early 2021 (with IBC and parachain capabilities, respectively). Meanwhile, in terms of scalability, due to the increasing demand from users on Ethereum, ETH transaction fees became extraordinarily high by the end of 2020, creating an urgent need for alternative solutions among application developers. Concurrently, research on off-chain scalability for Ethereum was being slowly 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") also recognized 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) all launched EVM-compatible chains in 2020 and 2021.

In terms of application-specific design, Celestia launched a novel modular design in 2019 (initially as LazyLedger) that separates the execution, settlement, and data availability layers of traditional monolithic blockchains, allowing for application-specific blockchains without the need to rebuild other parts of the stack.

Today, there are multiple platforms providing AppChain infrastructure. While some of these currently only offer public block space (e.g., Optimism, zkSync), they are likely to launch dedicated execution layers if there is sufficient developer demand.

Moreover, while the launch and interoperability issues of AppChains have historically been challenging, both developers and users have accelerated their acceptance of AppChains in recent years. Axie launched their Ethereum sidechain Ronin in early 2021, DeFi Kingdoms announced their migration from Harmony to Avalanche subnet at the end of 2021, approximately 46% of the Apecoin community members still support building ApeChain, and dYdX announced that their V4 version protocol will be built on an L1 developed using the Cosmos SDK. Today, countless applications are built on AppChains.

Why Choose AppChains?

There are three main reasons why developers are increasingly turning to build AppChains instead of launching smart contracts on public blockchains.

Performance

• Because dApps compete with each other on the same network, a popular dApp often consumes disproportionate resources, increasing transaction costs and delays for users of other dApps.
• AppChains provide projects with stable transaction costs and low latency, resulting in a better user experience.

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, security levels, permissions, composability, and ecosystem consistency. For example, validators may have high-performance hardware requirements (e.g., running SGX or FPGA to generate zero-knowledge proofs).
• For traditional organizations, AppChains offer a way to enter Web3 without permission; for example, companies can require KYC validators to screen developers they want to build on their network and choose which chains they want to connect their assets to via cross-chain bridges.

Value Capture

• While general scalability solutions do reduce transaction costs while maintaining security and developer experience, they offer few monetization opportunities for developers.
• On the other hand, AppChains have a strong business case because dApps can fork existing protocols within their ecosystem and monetize them (e.g., transaction fees from AMM or NFT markets).
• Their tokens benefit from being used as security models (i.e., staking tokens or Gas tokens).
• Additionally, applications can capture MEV by running their own sorters or validators, creating opportunities for new crypto business models; for example, dYdX's validators (possibly market makers) can offer users low or no fees but give them slightly lower execution prices, similar to the order flow payment model used by Robinhood.
• Another example is that many successful games have a plethora of mods, skins, etc., and actively try to make as many adjustments as possible. However, most of the time, modeling is done by amateur gamers who find it difficult to monetize. If the game is built on an AppChain, then mods can expand that IP on top of the rollup and profit from using that chain.

Issues with AppChains

However, everything has its downsides:

Limited Composability and Atomicity

• AppChains somewhat isolate infrastructure and users from other ecosystems. While this does not break composability (you just need a good enough bridge on the same VM), it does break atomicity (a "all-or-nothing" property where all sub-operations in a single transaction are either executed or none are).
• That said, while atomicity is a special property of all applications being on the same settlement layer, it is not crucial for many applications (e.g., P2E games do not rely on flash loans to maintain their economies).

Rebuilding Walled Gardens

• As a thought experiment, if all AppChains have read/write permissions, the resulting market structure would limit developers' ability to innovate without permission and users' ability to trade freely, bringing Crypto back to the issues it aimed to solve.

Liquidity Fragmentation

• Liquidity assets from other layers or chains will need to connect to AppChains via cross-chain bridges, and while this can be done through bridging infrastructure, it adds extra "friction" for users.

Self-Referential Security Models

• If application tokens are used as security models, there is an edge case where if the token price drops to 0, the application will no longer have economic security.

Resource Waste

• If an application does not receive sufficient usage, AppChains may waste resources (physical or economic). If an AppChain has dedicated validators, those validators could deploy their resources more efficiently elsewhere.

Additional Complexity

• Because it is not as simple as deploying a smart contract, managing additional infrastructure (e.g., sorters or validators) adds extra complexity.

Limited Ecosystem Tools

• There may not be "out-of-the-box" resources such as block explorers, RPC providers, indexers, or oracles, and ecosystem funding.

Emerging Market Structure for AppChains

Due to the many downsides of building in more isolated ecosystems, AppChains are best suited for applications that have the following characteristics:

• Achieved scale (e.g., user numbers, protocol revenue, TVL) and product-market fit
• Performance can provide significant advantages for the product
• Lower requirements for security and atomicity (e.g., P2E games, NFTs, crypto social)

Therefore, we have reason to believe that most applications will continue to launch on public L1 and L2. Additionally, as the landscape of L2 remains quite fragmented, we will see DeFi protocols continue to launch on L1 due to their security, liquidity, and atomicity properties. Furthermore, if non-DeFi applications achieve a sufficiently large ecosystem and network effects, they may launch on general-purpose L2 and migrate to application-specific L3 or application-specific L1. We can roughly imagine this operational sequence as follows:

Another reason is that most applications launching AppChains will choose modular execution layers (especially rollups) rather than monolithic chains, as they lack the funding needed to attract large validator pools. Moreover, high-quality validators are unlikely to choose to allocate their resources to AppChains with low and unstable token prices.

Nevertheless, as the crypto industry matures and becomes more widespread, more applications will continue to launch their own AppChains, and the future market structure of AppChains will take various forms:

• AppChains connected through various cross-chain bridges
• Application-specific sidechains connected to L1
• Application-specific rollups that do not use a settlement layer

How AppChains are Designed

When deciding on the infrastructure for building an AppChain, several design trade-offs need to be considered:

Type of Security: How difficult is it to change the state through attacks?

• Shared: State protected by multiple heterogeneous validators, possibly run by different parties (e.g., Polkadot parachains, Skale)
• Isolated: Security provided by the application itself; may use validators or sorters owned by the application and utilize the application's tokens for economic benefits (e.g., Cosmos chains, Axie Ronin)
• Inherited: Security provided by the underlying settlement/consensus layer (e.g., zkSync, Optimism)

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

• Ethereum: Using Ethereum as a settlement layer for fraud proofs, validity proofs, and general double-spend protection (e.g., Arbitrum, zkSync)
• Non-Ethereum L1: Using non-Ethereum security and possibly having completely different consensus models (e.g., NEAR Aurora, Tezos rollups)
• Application Tokens: Using the application's tokens as crypto-economic security (e.g., Avalanche subnets, Cosmos chains)

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

• Permissionless: Anyone can read/write contracts and validate state transitions (e.g., Optimism, StarkNet)
• Selectively Permissioned: Only whitelisted validators/developers can read/write/validate the chain (e.g., Polygon Supernets, Avalanche subnets)

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

• All: Move to any application with minimal latency and maximum security (e.g., Polkadot XCMP, Cosmos IBC)
• Limited: There are restrictions in terms of connectivity, latency, or security (e.g., Avalanche subnets, Polygon Supernets)

Finality: When is a transaction considered final?

• Instant: Typically using BFT consensus mechanisms (e.g., NEAR Aurora, Evmos)
• Final: Typically using rollups, once a block is published to L1 (and assuming data is available), the transaction can be considered final (e.g., Arbitrum, zkSync)

Gas Tokens: What tokens do users use to pay transaction fees?

• Non-application Tokens: Typically the base asset of the L1 or L2 on which the application is built (e.g., Ethereum, Evmos)
• Application Tokens: Typically the tokens of the application itself running on an application-specific L1 or L2 (e.g., Avalanche subnets, Osmosis)
• No Tokens: L1 or L2 validators or applications provide cost subsidies for users (e.g., AltLayer, Skale)

There are also several more direct factors:

• Required Staking: The amount of staking required for the application to protect its chain
• Transactions Per Second (TPS): A subjective measure of throughput, as the size of transactions may vary (i.e., larger transactions will lead to lower TPS, and vice versa)
• EVM Support: The ability to support Solidity and EVM opcodes simultaneously without requiring developers to modify their codebases

We can map existing AppChain solutions based on these factors:

Conclusion

Despite the issues with AppChains, their continued growth indicates a demand from developers. As Apple has demonstrated, vertical integration often leads to a better user experience; similarly, blockchain developers will seek to provide fully optimized Web3 applications supported by AppChains. That said, AppChains are not suitable for everyone, and developers should carefully consider/weigh the needs of their applications before investing resources into launching them.

AppChains have many implications for the economics of security models, monetization strategies, platform defensibility, overall value accumulation across the stack, and the structure of the crypto market, which we will observe in the coming years.