In-depth analysis of the risks and opportunities of application chains: Where is the next opportunity for application chains?

Original Title: 《The Appchain Universe: The Risks and Opportunities》

Author: Mohamed Fouda, Alliance DAO

Translator: Hailsman, Chain Catcher

The author of this article, Mohamed Fouda, is a cryptocurrency researcher, Venture Partner at Volt Capital, contributor to Alliance DAO, and a PhD candidate at Northwestern University in the United States.

In the past year, several star applications have launched their own app chains or announced plans to deploy their own app chains. For high-growth projects, the direction of app chains is undoubtedly a foreseeable future. Some articles related to app chains have even begun to predict that every popular Web3 application will eventually have its own blockchain.

Based on this trend, some project founders have started to believe that the right approach is to build applications as app chains from the very beginning. Of course, I believe this is applicable for certain applications, but choosing to spend money too early on building an app chain is, in fact, "self-deprecating" for many projects.

We often discuss this topic in the Alliance DAO community, and from it, some solutions have emerged, including: the best use cases for app chains, the problems that need to be solved when building app chains, and what entrepreneurial opportunities exist.

1. What is an App Chain?

An app chain is designed to primarily execute a single function or application, such as a game or DeFi application. This means that the application can utilize all the resources of the chain, such as throughput and state, without competing with other applications. Additionally, the application itself can flexibly optimize the chain's technical architecture, security parameters, throughput, etc., to match the application's needs. Since it targets specific applications, app chains are generally not "permissionless" for developers but are "permissionless" for users. In this respect, app chains deviate from standard blockchain practices, where blockchains are open to both users and developers.

Comparing App Chains to "Small Towns"

We can compare smart contract chains (public chains) to cities to understand the compromises founders must make when choosing to build an app chain.

General-purpose computing chains like Ethereum and Solana are like metropolises, with diverse infrastructures to support different types of businesses (applications). This makes general-purpose chains more popular, more crowded, and often more expensive, sometimes even busier. However, this flow creates a lot of traffic and opportunities for businesses within the ecosystem: it is easy to move from one business to another. Different business activities can also be combined to create new and interesting ventures.

Building your own app chain is like having a small town with a single business activity. The town can set its own rules and policies. It is less crowded and cheaper but may not have good connections to the outside world. Everyone in the town is using the single business available. If it is popular enough and unique enough, customers might even come to this "specialty town" specifically for that business.

Moreover, there are security differences. Larger cities have more people, wealthier and stronger populations. All businesses in the city share a common interest in having a secure and reliable city. These factors make large cities harder to attack and safer. On the other hand, the security of small towns is closely related to the popularity and success of the single business. If the business does well, the number of residents will increase, and the town will become stronger; if the business does poorly, people will leave, which will reduce the town's security and make it easier to attack.

A compromise between these two models is specific industry chains, such as dedicated DeFi or gaming chains, which are akin to suburban cities—more popular and secure than small towns but not as busy as large cities.

General-purpose computing chains, app chains, and industry chains can coexist and meet different needs. It is important to identify which use cases require app chains rather than building smart contracts on general-purpose computing chains or industry chains. The first part of this article discusses app chains and their use cases, the second part covers the entrepreneurial opportunities that exist in this field, and the final part compares different implementation methods for app chains.

2. What are the specific use cases for App Chains?

As we have seen in the past few years, app chains can be launched for various reasons. In this section, we will discuss the most common scenarios that are better suited for app chains.

1. Ecosystem Needs

Application builders on ecosystems like Cosmos and Polkadot essentially need to build their applications as app chains. Both protocols focus on interconnected multi-chain ecosystems, where no main chain in either ecosystem has implemented an execution engine that supports smart contracts. Therefore, to build applications in these two ecosystems, one must either build their own app chain or choose a chain that has already implemented a general-purpose computing execution engine.

In the Cosmos ecosystem, chains that implement smart contract execution engines include Evmos (EVM compatible) and Juno (CosmWasm smart contracts), both of which contain multiple DeFi and NFT applications, while Osmosis (AMM DEX), Mars hub (loans), and Secret (privacy) belong to app chains.

In the Polkadot ecosystem, general-purpose computing parachains include Moonbeam (EVM compatible) and Astar (WASM smart contracts). Examples of app chains on Polkadot include PolkaDex (order book DEX), Phala (privacy), and Nodle (IoT network).

2. Throughput Needs

When some general-purpose computing chains cannot meet the throughput or cost needs of applications, choosing to build an app chain is the ideal state. If one wants to build applications in Web3 that perform similarly to Web2, app chains are the best choice.

Gaming applications are the best example. Most interactive games require extremely high throughput to support user interactions. Additionally, transactions should be free or have negligible fees. General-purpose computing chains cannot meet these requirements. Some examples include:

• Axie Infinity: Launched on the Ronin sidechain
• Sorare: A fantasy football game launched as StarkEx L2

Beyond gaming, DeFi protocols like order book trading often require high throughput to provide an excellent user experience for professional traders. A known example is the DeFi derivatives exchange dYdX. The dYdX protocol currently processes about 1000 orders per second. The required chain throughput should exceed 1000 TPS. For this reason, dYdX V3 was launched as a dedicated Ethereum Rollup based on StarkEx technology. As the protocol plans to further scale and require higher throughput, it is transitioning to an app chain. Therefore, dYdX has announced that it will use a dedicated Cosmos chain for its V4.

3. The Need for Specific Technologies

If an application requires specific technologies that are not available on the L1 chain, another approach is to build an app chain that implements that technology. The best example is zero-knowledge proofs, such as zk-Snarks or zk-Starks. Privacy-focused applications like privacy payments or transactions require zk proofs to construct blocks. However, generating zk proofs is computationally intensive, and these computations are too expensive to execute on-chain.

In this case, the best approach is to implement the required technology on the app chain. For example, Aztec is a privacy-preserving payment and transaction application that launched L2 on Ethereum. There is also the Secret app chain in the Cosmos ecosystem.

4. The Need to Enhance Application Economics

When teams build applications as smart contracts on L1 blockchains, users have to pay two types of fees to the application: native application fees and gas fees. Native application fees, such as trading fees on exchanges or spreads on lending protocols, are essentially revenue streams for the application. This revenue is often used as incentives for application participants to develop the application community and accelerate application adoption.

On the other hand, users of the application pay gas fees to L1 validators. Gas fees are an expense for application users and can degrade the user experience. Gas fees do not contribute to the economics of the application; they are akin to paying "rent" for the custodial services of L1. Although this "rent" ensures the security of the application, it is more ideal if this portion of money could remain within the application economic system, which would better incentivize users.

App chains support this situation, allowing project teams to control their own gas fees to allocate rewards to participants trying the application. For example, Yuga Labs considered this aspect when wanting to separate the Bored Ape Yacht Club (BAYC) ecosystem into an independent chain. The BAYC community paid substantial fees to the Ethereum network during the minting period of the project's NFT assets, while migrating to its own app chain would retain those fees within the BAYC economic system.

3. What are the Risks of App Chains?

Despite the advantages of app chains mentioned above, they also face several risks. For instance, building an app chain is much more complex than developing smart contracts, requiring the development of infrastructure unrelated to the core business of the application. Additionally, app chains increase security and composability risks.

1. Security Guarantees

Smart contract applications derive their security from the underlying L1. As discussed earlier in the "Metropolis vs. Small Town" analogy, since L1 supports multiple applications, the motivation to keep L1 secure is shared among a large number of L1 participants. This makes L1 more secure and harder to attack. Furthermore, L1 security guarantees are independent of the adoption of specific applications.

In app chains, security largely depends on the adoption of the application and the price of the application's native token. Depending on the implementation details, an app chain can be an L2 sequencer or an independent PoS validator. In both cases, validator rewards are typically denominated in the native application token. Validators must stake native tokens and use complex infrastructure with high uptime to participate in the network. Validation rewards need to exceed the operational costs and risks associated with token staking that validators undertake. Some issues with this model include:

• Staking risks may complicate the situation for joining the network and may even attract amateur validators, which could jeopardize network security and uptime.
• The dependency of validator rewards on token prices may prompt application developers to use high token inflation or unsustainable gamified token economics.
• If application adoption is low and token prices are low, network security weakens, allowing malicious actors to attack the network at a low cost.

2. Costs and Team Time

Launching an app chain comes with a series of additional infrastructures that need to be built and activities that require coordination with validators. In terms of infrastructure, public RPC nodes are needed to allow wallets and users to interact with the chain. Data analysis infrastructure, including block explorers and archive nodes, is also required to allow users to view activities. Services such as network monitoring and validator information are also necessary.

Thus, there is a lot of additional infrastructure to build, which requires significant costs and engineering time, and engineering teams spend a lot of time dealing with tasks unrelated to application logic. Additionally, there are costs associated with maintaining the blockchain, which requires extensive planning and communication with validators to schedule network upgrades or respond to errors and downtime.

In general, developing an app chain requires a stronger team and higher costs, which is something startups cannot afford, especially in the early stages. These cumbersome matters can disrupt the development logic of the application and become obstacles to the project's rapid adaptation and achieving product-market fit.

3. Lack of Composability

One of the main advantages of building applications as smart contracts is atomic composability. Applications can build on each other, allowing users to interact seamlessly with multiple protocols in the same transaction. For example, a smart DEX router can route a single trade through different AMMs to achieve optimal pricing.

Another example is flash loans, where trades can borrow from lending protocols and execute trades or arbitrage on AMMs before repaying the loan. These interactions can occur "atomically" within the same transaction. Atomic composability is a unique feature in Web3 applications that enables interesting behaviors and business opportunities.

App chains lack this atomic composability because each application is isolated from others. Interactions between applications require cross-chain bridges or messaging, which need to span multiple blocks and cannot be "atomically composable." Of course, the lack of atomic composability may spur some interesting startups to address this issue. For example:

4. Cross-Chain Risks

Another issue with app chains is the increased risk of cross-chain assets. Specifically, DeFi applications need to bridge multiple assets, such as BTC, ETH, and stablecoins. Cross-chain assets can degrade user experience and introduce greater risks. Cross-chain bridges are common targets for attacks, and if a cross-chain bridge is compromised, it could lead to bad debts for DeFi applications that require assets to be bridged.

For app chains that cannot attract reputable and well-funded cross-chain bridges, the risks are even higher. In these cases, app chains may resort to centralized cross-chain bridges, such as centralized exchanges or develop their own cross-chain bridges.

4. What are the Entrepreneurial Opportunities in the App Chain Space?

The challenges of the app chain ecosystem create opportunities for startups to solve problems. In this section, we discuss some of these opportunities and encourage more interested founders to reach out.

1. High-Performance DeFi Protocols

The key driver here is the use of customizable tech stacks that can be adjusted according to DeFi protocol needs. DeFi protocols aiming to compete with Web2 performance need to be implemented as app chains. Central limit order book (CLOB) exchanges are the best choice. The dYdX derivatives exchange has initiated this trend, and it is expected that spot and commodity exchanges will be built as app chains, benefiting from low fees and low latency.

2. App Chain Game Engines

Some applications limited by public chain performance currently have limited options for building app chains, with StarkEx being a good choice in this regard. We hope to see startups build new efficient architectures for on-chain games that can support 100,000+ TPS.

3. Developer Tools for Customizing, Deploying, and Maintaining Sidechains and L2s

Launching sidechains or Rollups as app chains using appropriate architectures is very complex, and a developer platform that facilitates this task could become a very valuable business—think of Alchemy for app chains.

4. AI-Supported App Chains

Similar to zero-knowledge proofs, AI is a computationally intensive transformative technology. Therefore, applications supporting AI cannot be built on-chain. Many successful Web2 AI products require users to pay substantial subscription fees. App chains can be used to open access to AI applications to the public. Consider building applications that run trained AI models, such as Dall-E or GPT3, which are open for public use.

5. Composability Solutions and Cross-Chain Communication

The lack of atomic composability in app chains creates opportunities for startups to create cross-chain messaging and establish perceived composability. Ideas include:

• User frontends executing cross-chain functionalities in the background, such as IBC transfers or LayerZero messaging, and creating multiple applications that work in a composable manner. For example, cross-chain zapper.
• Wallets implementing secure multi-chain accounts through multiparty computation (MPC) and locally processing cross-chain activities by executing simultaneous trades across multiple chains. For example, cross-chain arbitrage.

6. Cross-Chain DeFi Protocols

Although app chains have several advantages in throughput, they also lead to liquidity fragmentation, resulting in increased slippage and a degraded user experience. Cross-chain DeFi protocols that automatically split trades across different chains for better pricing will provide a better user experience and a larger customer base.

7. Trustless Cross-Chain Messaging Between EVM and Non-EVM Chains

The implementation of app chains is divided into Cosmos, Polkadot, and EVM L2. One possible way to enhance composability is to build a universal trustless cross-chain messaging protocol that can connect EVM L2, Cosmos zones, Polkadot parachains, etc. Such a product could replace existing cross-chain bridges and facilitate billions of dollars in transaction volume annually.

8. Unlocking Cross-Chain Security Sharing

Using products that support cross-chain security can mitigate the security challenges of app chains. Similar to merged mining with PoW chains, we envision a method that allows unrelated PoS chains to share security, such as validators staking ETH instead of native app chain tokens to secure the app chain. Liquidity staking protocols could play a significant role in this system.

5. How to Build an App Chain?

App chains can be implemented in various ways with different complexities and security levels. This section briefly compares some methods for building app chains.

1. Cosmos Zone

Cosmos is the first ecosystem to envision a multi-chain world. Based on this vision, Cosmos development focuses on standardizing and simplifying the process of launching dedicated chains that can interconnect. This work has produced the Cosmos SDK, a modular framework for customizing and developing blockchains. The Cosmos SDK natively supports the Tendermint consensus mechanism but allows for other consensus mechanisms. The Cosmos SDK was later enhanced by adding the IBC module, which allows for trustless communication between Tendermint-based chains.

Each of these chains is referred to as a Zone. The Cosmos ecosystem has evolved to include over 45 zones, consisting of more than 700 IBC interconnected relayers. Many Cosmos Zones have been used to create single-purpose app chains. Osmosis is one of the largest Cosmos Zones, implementing an AMM DEX.

Cosmos initially adopted the concept of isolated security, meaning each zone is responsible for its own security. Each zone needs to recruit validators to run the network and reward them with the zone's native tokens. Although this approach is flexible, it raises the entry barrier for app chain builders. Therefore, Cosmos is implementing a change that allows smaller zones to obtain security from the Cosmos Hub through a cross-chain security module.

2. Polkadot Parachains

Similar to Cosmos, Polkadot has developed a multi-chain ecosystem. Chains in the Polkadot ecosystem are called parachains, which can be launched using the Substrate SDK. The main difference between Polkadot and Cosmos is that Polkadot unified its security vision from the start. All parachains share security with the Polkadot main chain, known as the relay chain. The primary function of the relay chain is to provide consensus and security for parachains. Therefore, the relay chain does not implement smart contract functionality.

Due to shared security guarantees, the Polkadot ecosystem does not allow parachains to launch without permission. Instead, parachain slots are auctioned to developers who want to build custom chains. Bidders must lock DOT to secure a parachain slot. So far, 27 parachains have been auctioned.

Different parachains on Polkadot can communicate using the cross-consensus messaging (XCM) format. XCM communication is still in the implementation phase and is currently operational, but it requires storing messaging data on the relay chain.

3. Avalanche Subnets

The implementation method of Avalanche's subnets is very similar to that of Cosmos. Developers can launch their own subnets, each of which can support multiple chains. Subnets need to recruit their own validators. However, in addition to validating dedicated subnets, these validators also need to validate Avalanche's main network. While this requirement enhances the security of the main network, it raises the entry barrier for dedicated subnets compared to Cosmos.

Currently, the subnet ecosystem does not support native inter-subnet communication; subnets must develop their own gateways. Of course, to increase adoption, the Avalanche team is working to support related functionalities.

4. Ethereum L2

In Ethereum, the term "app chain" may not always accurately describe applications that require dedicated environments. In Ethereum, such applications can be implemented as dedicated L2s or as sidechains. L2 implementations cannot be called app chains because they do not implement a complete blockchain stack. L2s are Rollups or validators that only support transaction execution and ordering. For Rollups, consensus and data availability are provided by Ethereum L1. For validators, L1 only provides consensus, while data is stored off-chain. Examples of applications using this architecture include Sorare and Immutable X.

Another approach, sidechains, requires launching independent blockchains validated by a small number of validators to achieve high throughput. Sidechains are typically connected to Ethereum by bridges validated by the same group of validators. A known example is the Ronin sidechain supporting the Axie Infinity game.

The main advantage of the L2 implementation method compared to all other methods is its superior security guarantees. L2 inherits security from Ethereum L1 through zk proofs or fraud proofs. Nevertheless, they can still achieve very high throughput and negligible fees. These requirements are well-suited to the needs of gaming applications.

The main drawback of the L2 method is that composability between L2s or between L2s and L1 is more challenging. Rapidly transferring assets between different Rollups often requires third-party providers, such as LayerZero. Although some technologies support trustlessly transferring assets between Rollups without going through L1, these technologies introduce significant delays, which applications like DeFi cannot tolerate. This is why DeFi protocols use general-purpose L2s like Optimism and Arbitrum as scaling mechanisms rather than application-specific L2s.

Another challenge of the L2 method is the complexity of implementation. Compared to launching a Cosmos app chain using the Cosmos SDK, launching application-specific L2s on Ethereum does not have standardized scripts. However, as Ethereum progresses further along its Rollup-centric roadmap, this situation is expected to improve in the future.

Conclusion

The app chain narrative is gaining attention but is also evolving in a direction different from the original vision. The implementations of app chains on Cosmos, Polkadot, Avalanche, and Ethereum are trending toward a shared security approach, but the differences are minimal. With shared security, app chains do not actually need a consensus mechanism. Instead, applications can simply use dedicated execution environments that serve the applications and rely on L1 for consensus and data availability. This execution environment can be a Rollup or an independent execution layer following a modular blockchain approach.