What risks and opportunities will the rise of application chain bring? How will the future develop?
Compilation of the original text: Bai Ze Research Institute
Compilation of the original text: Bai Ze Research Institute
While blockchain's initial applications revolved around currency and finance, applications in areas such as art, gaming and music have proliferated over the past few years. 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, fees, write permissions, and more.
AppChains are not a new concept; Bitcoin can be thought of as an application-specific blockchain for digital gold, and Arweave for permanent storage. That is, the design of AppChain encompasses not only monolithic blockchains (e.g. Osmosis), but also modular execution layers (e.g. rollups, sidechains, plasma) that handle application state transitions, but rely on a separate settlement layer or consensus layer to achieve finality.
In fact, "layers" (such as L2, L3, etc.) are in most cases just trust-minimized blockchains with bi-directional trust-minimized cross-chain bridges.
In this article, I will:
Overview of the history of AppChains
Explain the pros and cons of AppChains
Describe the future AppChain market structure
Outline how AppChain is designed
first level title
The past and present of AppChains
AppChain took many years to emerge. While Cosmos and Polkadot proposed and promoted the concept back in 2016, they didn't 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 of users on Ethereum, ETH transaction fees became prohibitively high in late 2020, and application developers desperately needed alternative solutions. Meanwhile, Ethereum off-chain scalability research is slowly being implemented in the form of "L2s", Polygon, Skale, zkSync (1.0), StarkWare (StarkEx), Optimism and ArbitrumBoth launch in 2020 and 2021.
Other base layers ("L1") also realize the importance of supporting the EVM (Ethereum Virtual Machine) as part of their business development efforts; Avalanche (C-Chain), NEAR (Aurora), Polkadot (Moonbeam) and Cosmos (Evmos ) are launching EVM-compatible chains in 2020 and 2021.
In terms of application-specific design, Celestia introduced in 2019 (initially as LazyLedger) a novel modular design that separates the execution, settlement, and data availability layers of traditional monolithic blockchains, allowing specific application-specific blockchain without rebuilding the rest of the stack.
Today, there are various platforms that provide AppChain infrastructure. While some of them currently only offer public blockspaces (e.g. Optimism, zkSync), if there is enough developer demand, they will likely roll out support for dedicated execution layers.
first level title
Why choose AppChains?
There are three main reasons why developers are increasingly turning to building 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 a disproportionate amount of resources, which increases transaction costs and latency for users of other dApps.
Customizability
Customizability
As dApps grow in popularity, developers need to continue optimizing their dApps for users.
Large-scale dApps need to weigh certain design choices, such as throughput, finality, security level, permission, composability, and ecosystem consistency. For example, a verifier may have high-performance hardware requirements (such as running SGX or an 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 screen 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 few monetization opportunities for developers.
On the other hand, there is a strong business case for AppChains, as dApps are able to fork and monetize existing protocols within their ecosystems (e.g. transaction fees from AMMs or NFT marketplaces).
Their tokens benefit from additional tokens that are used as a security model (i.e. staking tokens or gas tokens).
Additionally, the ability for applications to capture MEV by running their own orderers or validators could create opportunities for new crypto business models; for example, dYdX's validators (possibly market makers) could offer users low- or no-fee Fees, but give them a slightly lower execution price, similar to the pay-per-order model Robinhood uses.
first level title
Problems with AppChains
However, everything is a double-edged sword:
Limited composability and atomicity
AppChains isolate infrastructure and users from 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 of all applications being on the same settlement layer, it doesn't matter for many applications (e.g. P2E games that don't rely on flash loans to keep their economies running).
Rebuild the Walled Garden
As a thought experiment, if all AppChains had read/write permissions, the resulting market structure would limit the permissionless and combinatorial innovation of developers, and the ability of users to trade freely, which would bring Crypto back to the problem it was designed to solve. on the question.
Liquidity dispersion
Liquid assets from other layers or chains will need to connect to AppChains across chain bridges, and while this is possible through the bridging 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 that if the price of the token drops to 0, the application will no longer be economically secure.
waste of resources
AppChains can be a waste of resources (physical or economical) if the application is not used enough. If the AppChain has dedicated validators, those validators can deploy their resources elsewhere more efficiently.
additional complexity
Because it is not as simple as deploying a smart contract, it adds additional complexity when managing additional infrastructure such as orderers or validators.
Limited ecosystem tools
first level title
Emerging AppChain Market Structure
Due to the many disadvantages of building in more siled ecosystems, AppChains are best suited for applications with the following characteristics:
Achieved scale (e.g. number of users, agreement revenue, TVL) and product market fit
Performance can bring significant advantages to the product
Fewer requirements for security and atomicity (e.g. P2E games, NFT, encrypted social)
Therefore, it is reasonable to assume that most applications will still continue to launch on the common L1 and L2. Additionally, since the L2 landscape is still fairly fragmented, we will see DeFi protocols continue to launch on L1 due to their security, liquidity, and atomic properties. Additionally, if non-DeFi applications have a sufficiently large ecosystem and network effects, they may launch on general-purpose L2 and move to application-specific L3 or 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 (especially rollups) over monolithic chains because they don't have the capital needed to attract large validator groups. Also, high-quality validators are less likely to choose to dedicate their resources to AppChain where token prices are low and unstable.
Nevertheless, with the maturity and popularity of the encryption industry, more applications will continue to launch their own AppChain, and the future AppChain market structure will take various forms:
AppChains connected through various cross-chain bridges
Application-specific sidechains connected to L1
first level title
How AppChains are designed
There are several design trade-offs to consider when deciding to build an AppChain infrastructure:
Security Types: How hard is it to mutate state via 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; possibly using validators or orderers owned by the application and using the application's tokens for economic benefit (e.g. Cosmos Chain, Axie Ronin)
Inheritance: 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: Use Ethereum as a settlement layer for fraud proofs, validity proofs, and general double spend 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 application tokens as cryptoeconomic security (e.g. Avalanche subnets, Cosmos chains)
Permissions: How are nodes selected, and who can read/write state?
Permissionless: Anyone can read/write contracts and verify state transitions (e.g. Optimism, StarkNet)
Selective permission: only whitelisted validators/developers can read/write/validate the chain (e.g. Polygon Supernets, Avalanche subnets)
Composability: Is it easy and safe for fluidity and state to move 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: Limitations in connectivity, latency, or security (e.g. Avalanche subnets, Polygon Supernets)
Finality: When is a transaction considered final?
Immediate: typically using BFT consensus mechanisms (e.g. NEAR Aurora, Evmos)
Final: Typically using rollups, transactions can be considered final once a block is published to L1 (and assuming data is available) (e.g. Arbitrum, zkSync)
Gas Token: Which token will users use to pay transaction fees?
Non-application tokens: usually L1 or L2 underlying assets to build applications on (e.g. Ethereum, Evmos)
Application Tokens: Often the application's token itself runs on application-specific L1 or L2 (e.g. Avalanche subnet, Osmosis)
No Tokens: L1 or L2 validators or applications provide cost subsidies to users. (e.g. AltLayer, Skale)
There are several other more immediate factors:
Required Stake: The amount of stake required for the application to require validators to secure its chain
Transactions per second (TPS): A subjective measure of throughput, as transactions can vary in size (i.e. larger transactions will result in lower TPS and vice versa)
EVM Support: Ability to support both Solidity and EVM opcodes without requiring developers to modify their codebase
in conclusion
in conclusion
Despite AppChains' problems, their continued growth shows developer demand. As demonstrated by Apple, 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 application before committing resources to launching it.
According to the "Notice on Further Preventing and Dealing with the Risk of Hype in Virtual Currency Transactions" issued by the central bank and other departments, the content of this article is only for information sharing, and does not promote or endorse any operation and investment behavior. Participate in any illegal financial practice.
risk warning:
According to the "Notice on Further Preventing and Dealing with the Risk of Hype in Virtual Currency Transactions" issued by the central bank and other departments, the content of this article is only for information sharing, and does not promote or endorse any operation and investment behavior. Participate in any illegal financial practice.
