header-langage
简体中文
繁體中文
English
Tiếng Việt
Scan to Download the APP
Partnered With:

Detailed explanation of the development of AppChain, what opportunities are worth paying attention to in the future?

Read this article in 32 Minutes
The design of AppChain not only includes a monolithic blockchain (such as Osmosis), but also includes a modular execution layer (such as Rollups, Sidechains, Plasma) that handles application state transitions, and ultimately relies on a separate settlemen
Original title: "A detailed explanation of the development of AppChain, what opportunities are worth paying attention to in the future?" "
Original author: Dmitriy Berenzon 
Original compilation: 0xMoonda

 

p>

In the past, blockchain applications mainly revolved around the currency and financial fields. However, in recent years, compared with other categories, the number of blockchain applications in the fields of art, games and music has surged. At the same time, the number of users is growing super-linearly, which puts a lot of pressure on the underlying infrastructure and reduces the end-user experience. Therefore, the application needs a wider customization space and a more powerful business model to meet its own development needs.

 

In order to solve these problems, based on Application-specific blockchains (also known as AppChains) are gradually coming into view. Simply put, AppChain refers to a blockchain that dedicates block space to specific applications. Applications built on AppChain can customize different layers of its stack, such as security models, fee tokens, and write permissions.

 

Actually, AppChain is not a new concept. The Bitcoin network can be regarded as a dedicated blockchain for "digital gold"; similarly, Arweave can also be regarded as an application chain for permanent storage. That is to say, the design of AppChain not only includes a monolithic blockchain (such as Osmosis), but also includes a modular execution layer (such as Rollups, Sidechains, Plasma) that handles application state transitions, and ultimately relies on a separate settlement or consensus layer to complete.

 

In fact, "Layer" ( Such as L2, L3, etc.) in most cases refers to the blockchain with the lowest trust cost, and this blockchain also has the connection bridge attribute of the lowest two-way trust cost.

 

L3 is still in the research stage, but it is theoretically achievable through recursive zero-knowledge proof

 

History of AppChain


After years of evolution, the blockchain has developed into an available The underlying infrastructure of AppChain used by developers. Even though Cosmos and Polkadot started to promote this concept as early as 2016, it will not be put into practice until early 2021 (ie IBC and parachain). In terms of scalability, on-chain applications place ever-increasing demands on Ethereum’s block space. At the end of 2020, the extremely high transaction fees of Ethereum made developers realize that the search for alternative solutions was imminent. At that time, scalability research focused on Optimistic, ZK-rollups, and sidechains (collectively referred to as “L2s”). Meanwhile, Polygon, Skale, zkSync (1.0), StarkWare (StarkEx), Optimism, and Arbitrum are launching in 2020 and 2021.

 

Other bottom layers ("L1" ) also realized the importance of supporting EVM; Avalanche (C-Chain), NEAR (Aurora), Polkadot (Moonbeam) and Cosmos (Evmos) all launched EVM compatible chains around 2020 and 2021.

 

based on application-specific design aspects , Celestia (formerly known as LazyLedger) proposed a new concept of modular design in 2019, which separates the execution, settlement and data availability layers of traditional single-chip blockchains, making the implementation of blockchains based on specific applications a reality, and The rest of the stack doesn't need to be rebuilt either.

  

Better late than never...

 

Now there are multiple platforms that provide the underlying infrastructure of AppChain. While some of them only support shared blockspace layers (e.g. Optimism, zkSync), it is likely that there will be support for dedicated execution layers if the developers are well-staffed.

 

 As of October 3, 2022

 

Although the launch and interaction of AppChain has always been very difficult, in the past few years, developers and users have gradually accepted this approach. Axie launched its Ethereum sidechain Ronin in early 2021; DeFi Kingdoms announced the migration from Harmony to the Avalanche subnet at the end of 2021; about 46% of Apecoin community members hope to launch ApeChain in mid-2022; dYdX announced the launch of the product in mid-2022 The V4 version will use the Cosmos SDK technology to build an independent L1. At present, countless applications have been built in AppChain across various platforms.

 

As of October 3, 2022, "Ethereum" includes Polygon, Skale, L2 and other side chains

 

Reason for choosing AppChain


More and more developers do not Then deploy smart contracts on the shared block space, but choose AppChain for three main reasons:

 

Performance


· Because DApps compete with each other for block space in the same network, a certain A popular DApp often consumes a lot of resources, causing transaction costs of other DApps (such as Polygon and Arbitrum) to increase and network delays.

 

· AppChain enables transactions The cost and low network latency are kept within the predictable range of the project party, thus bringing a better experience for end users.

 

Customizability


· As the audience of DApps gradually increases, developers need to continuously optimize products for users.

 

· Larger scale The application needs to make trade-offs in the design, such as throughput, finality, security level, permission, composability, ecosystem consistency, etc. For example, as a validator, there may be high performance requirements for hardware (such as running SGX or FPGAs to generate zero-knowledge proofs).

 

· For traditional institutions For example, AppChain provides a way to enter Web3 without accepting a completely permissionless approach from the beginning; for example, companies can require validators to perform KYC; pre-screen out engineers who want to develop on their network; choose cross-chain start and end.

 

Value Capture


· Although general-purpose scaling solutions reduce transaction costs and preserve security and development experience, these solutions provide few opportunities for developers to obtain other benefits.

 

· on the other hand , Existing products have a strong commercial demonstration effect for AppChain, and developers can fork existing agreements in other ecosystems and obtain benefits (such as AMM mechanism or NFT transaction fees).

 

· Token of AppChain Benefits can be obtained from the price decline of other security models (such as pledged Token or gasToken) and the return of the Token to the value of the L2 or L1 Token in the market.

 

· In addition, the application can avoid MEV by running its own sequencer or validator, which will have the opportunity to generate new encrypted business models. For example, the validator of dYdX can become a market maker, reducing or exempting users from handling fees, but there is no Provide the best execution price, similar to Robinhood's "sell order flow" (PFOF, Payment for Order Flow) model.

 

· Another one For example, many successful games have a large number of mods, extensions, skins and other elements, and the developers will try to make the mods as easy as possible to modify as the game develops. It's just that most of the time, these modifications are done by amateur gamers with no financial benefit. If these games are on the AppChain, the mod can extend this IP to Rollup to obtain economic benefits by sharing the block space.

 

Problems with AppChain


Limited composability and indivisibility


· AppChain will itself to a certain extent Isolated from the underlying infrastructure and other ecology. Although it does not break composability (using the cross-chain bridge of the same type of VM to achieve cross-chain), it breaks indivisibility (a property of "full completion" or "all incomplete", that is, either in a single transaction Sub-operations are all executed, or none of them are executed).

 

· That is to say , while indivisibility is a unique property of all applications on the same settlement layer, it is not paramount for many applications (eg, P2E games do not rely on flash loans to keep their economies running).

 

Privilege restrictions


· Assuming that all AppChains have read and write permissions, the resulting market structure will limit developers' innovation in terms of permissionlessness and composability. Users' rights to conduct free transactions and opt out will also be restricted, which instead causes problems that should have been solved by the encryption industry to reappear.

 

Liquidity fragmentation


· In the use of AppChain, other underlying liquidity and assets need to use cross-chain bridges to transition to the ecosystem, and vice versa. Although there is nothing wrong with using a cross-chain bridge, it does increase the inconvenience of interaction from the perspective of users.

 

Reflexive Security Model


< p ql-global-para="true" line="9t0Z">· If the application Token is used as a security model, there may be edge cases, that is, if the value of the Token returns to zero, then the economic system in the application will no longer There is no security to speak of.

 

Resource waste


· If the utilization rate of applications on the chain is too low, then AppChain itself causes a waste of resources. If AppChain has dedicated validators, these validators can deploy resources to other ecosystems.

 

Additional development costs


· Different from the deployment of smart contracts, the development process of AppChain is cumbersome, so it increases the technical difficulty in managing the surrounding infrastructure (such as validator or sequencer).

 

Limited ecosystem tools and technical support


· There are no "off-the-shelf" resources available, such as block explorers, RPC providers, indexers, oracles, fiat channels and ecological funds.

 

AppChain’s Emerging Market


Due to the above-mentioned defects that may be encountered when establishing an independent ecosystem, AppChain is more suitable for applications with the following characteristics:

 

·  Reach a certain scale in a certain aspect, such as the number of users and agreements Revenue, TVL, product market fit, etc.

· Significant product or performance advantage in dedicated block space

< p ql-global-para="true" line="1Tml">· Low requirements for security and indivisibility, such as P2E games, NFT, encrypted social, etc.

 

Therefore, it is reasonable to infer that most applications will continue to share block space Launched on L1 and L2. In addition, since the existing structure of L2 is still very fragmented, DeFi protocols, especially DeFi protocols, will still choose to launch on L1 due to security, liquidity and indivisibility considerations. It needs to be emphasized that indivisibility is especially important here, because even with a zero balance sheet, effective and unlimited use of funds can still be obtained with flash loans.

 

In addition, if non-DeFi applications When the development of a company has reached a certain scale and has formed a large enough ecological and network effect, they are likely to choose to launch products on the general-purpose L2, and then transfer to the application-based L3 or directly launch on the L1 based on this application , the development process is roughly as follows:

 

 

Most applications will choose a modular execution layer when they decide to develop AppChain (especially are Roll-ups) rather than monolithic blockchains because they don't have the capital needed to start a large validator set. In addition, a high-quality validator will not choose an AppChain with a low price or an unstable token for deployment.

 

Even so, with encryption With the development and popularization of the industry, most applications will continue to launch their own AppChain. The future AppChain market structure is also very diverse:

 

· A specific application-based monolithic blockchain connected through different cross-chain bridges

· Connection list One-piece blockchain and application-specific sidechain

· Application-specific Roll-ups in a monolithic blockchain< /p>

· No need to use the settlement layer and independent application-specific Roll-ups

 

  < /p>

Design space of AppChain


Choose which AppChain to develop on , you need to refer to the following points to make a trade-off:

 

Security Type: How difficult is it to attack the chain and change its state?


· Shared: Protected by multiple heterogeneous validators, with a high probability of being run by different objects

(such as Polkadot's parallel chain, Skale)

· Isolated: Security is guaranteed by the application itself; it is likely to use the validator or sequencer that comes with the application; the Token of the application Used for pledge to obtain economic benefits

(such as Cosmos, Axie Ronin)

· Inherited: Apply underlying settlement or consensus layer to ensure security

(such as zkSync, Optimism)

p>

 

Security source: security guaranteed Where did it come from? Where does settlement happen?


· Ethereum: Use Ethereum as a settlement layer for fraud proofs, validity proofs, and common double-spending attacks to ensure network security

(such as Arbitrum, zkSync)< /p>

· Non-Ethereum L1: Using the security of non-Ethereum L1, there is a high probability of having a completely different consensus model

(such as NEAR Aurora, Tezos rollups)

· App Token: Use the application Token as the security guarantee of the ecology

(such as Avalanche's Subnets, sub-chains in the Cosmos ecology)

 

Permission: How are nodes selected? Who can read or write state?


· No permission : Anyone can read and write contracts, verify state transitions

(such as Optimism, StarkNet)

· Selective permission: only whitelisted validators or developers can read, write or verify the state of the chain (such as Polygon's Supernets, Avalanche's Subnets)

 

Composability: In the same ecology, What is the ease and security of liquidity and state transfer to different applications?


· Unlimited : can be transferred to any application, with low latency and high security

(such as Polkadot's XCMP protocol, Cosmos' IBC protocol)

· Limited: There are limitations in connectivity, latency, or security

(such as Subnets of Avalanche, Supernets of Polygon) 

 

Finality: When is a transaction considered finalized?

(assuming "finality" is the true completion state)


· Instant: usually use BFT consensus mechanism (eg NEAR Aurora, Evmos)

· Conditional requirements: usually using the rollups scheme, once the block is sent to L1 (assuming data is available), the transaction can be considered finalized (such as Arbitrum, zkSync)

 

GasToken: Which Token does the user use as gas for payment?


· Non-application Token: usually the underlying asset of L1 or L2 where the application is located

(such as Ethereum, Evmos)

· Application Token: Application Token itself runs on L1 or L2 based on a specific application

(such as Avalanche's Subnets, Osmosis)

· No gas: L1 or L2 validator or the application itself provides users with hardware cost subsidies< /p>

(such as AltLayer, Skale)

 < /p>

Other important reference factors:


< /p>

Pledge requirements: how many Tokens the application needs to pledge, so that the validator can guarantee the normal operation of the network

· TPS: The subjective measure of throughput will vary with the size of the transaction

(i.e. larger transactions degrade throughput, and vice versa)

Supports EVM: no need for developers to modify their code base Can support both Solidity and EVM opcodes

 

Based on the above points, the existing AppChain solutions can be summarized as:

 

 

Summary


Despite AppChain's current problems, the demand from developers indicates that AppChain continues to grow. Just like Apple back then, the integration of vertical fields usually brings better user experience; similarly, blockchain developers will deliver better Web3 applications under the empowerment of AppChain. However, AppChain is not suitable for all scenarios. Engineers should think deeply about the requirements of the application and weigh the pros and cons before devoting energy to development. In addition, there are many factors that will affect the security model economics, monetization strategy, platform defensibility, the natural growth of the overall value of the stack, and the secondary effects of the encryption market structure. The development of AppChain in the next few years is worth looking forward to.



This article is from a contribution and does not represent the views of Rhythm BlockBeats.   


Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia

举报 Correction/Report
Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit