Application-Specific Blockchains: The Past, Present, and Future

Published in

1kxnetwork

10 min readOct 4, 2022

While the initial applications of blockchains were around money and finance, the last several years have seen a proliferation of applications across art, gaming, and music, amongst others. In parallel, the number of aggregate users across these applications has been increasing superlinearly, straining the underlying infrastructure and degrading end-user UX. Furthermore, those applications are increasingly requiring more customizability and more robust business models as they scale to meet demand.

One emerging design pattern that addresses these issues is application-specific blockchains, or “AppChains”. Simply put, an AppChain is a blockchain that dedicates its blockspace to a specific application. Applications that build AppChains can customize multiple layers of their stack, such as their security model, fee token, and write permissions, among others.

AppChains are not a new concept; Bitcoin can be considered an application-specific blockchain for digital gold and Arweave for permanent storage. That said, AppChain designs do not only encompass monolithic blockchains (e.g. Osmosis) but also modular execution layers (e.g. rollups, sidechains, plasma) that process state transitions for applications but rely on a separate settlement or consensus layer for finality.

In fact, “layers” (e.g. L2s, L3s, etc.) are, in most cases, just trust-minimized blockchains with two-way trust-minimized bridges.

Illustrative; L3s are still in R&D but conceptually possible through recursive zero-knowledge proofs

In this piece I will:

Outline the history of AppChains
Explain the pros and cons of AppChains
Describe the future AppChain market structure
Outline the AppChain design space
Compare the different AppChain solutions currently live

The Past & Present of AppChains

It took many years for blockchains to offer AppChain infrastructure for developers. While Cosmos and Polkadot embraced and generalized this concept back in 2016, it took them until early 2021 to fully launch their networks (with IBC and parachain functionality, respectively). In the meantime, on the scalability front, there was increasing demand for Ethereum blockspace and transaction fees became frustratingly high towards the end of 2020, at which point developers were desperate for alternative solutions. In parallel, Ethereum scalability research was slowly being implemented in the form of optimistic & zero-knowledge roll-ups and sidechains (collectively referred to as “L2s”). Polygon, Skale, zkSync (1.0), StarkWare (StarkEx), Optimism, and Arbitrum all launched throughout 2020 & 2021.

Other base layers (“L1s”) also realized 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) all launched EVM-compatible chains in 2020 and 2021.

Separately and in parallel, on the application-specific design front, Celestia introduced in 2019 (initially as LazyLedger) a novel modular design that separates the execution, settlement, and data availability layers of a traditional monolithic blockchain and, as a result, allows for application-specific blockchains without the need to rebuild the other parts of the stack.

Today, there are a variety of platforms providing AppChain infrastructure. While some of them currently only provide shared blockspace layers (e.g. Optimism, zkSync), it is likely that they will launch support for dedicated execution layers given sufficient developer demand.

Furthermore, while launching and interoperating with AppChains has historically been difficult, the last few years have seen an acceleration of both developers and users entertaining the idea; Axie launched their Ethereum sidechain, Ronin, in early 2021, DeFi Kingdoms announced its move from Harmony to an Avalanche subnet in late 2021, ~46% of the Apecoin community still voted in favor of ApeChain in mid-2022, and dYdX announced in mid-2022 that their V4 will be built on a sovereign L1 using the Cosmos SDK. Today, there are a myriad of applications building on AppChains across a variety of platforms.

Not comprehensive; As of October 3rd, 2022; “Ethereum” includes Polygon, Skale, and other L2s & sidechains

Why AppChains?

There are three main reasons why developers have increasingly turned to building AppChains instead of launching smart contracts on shared blockspace.

Performance

Because dApps compete with each other for blockspace on the same network, it is often the case that one popular dApp consumes a disproportionate amount of resources, which increases transaction costs and latency for users of other dApps (e.g. Polygon and Arbitrum).
AppChains offers projects the ability to keep transaction costs & latency low & predictable, which results in better UX for end users.

Customizability

As a dApp grows in popularity, developers need to continue optimizing their applications for their end users.
Larger applications will want to make certain design choice trade-offs, such as throughput, finality, security level, permissioning, composability, and ecosystem alignment, amongst others. For example, validators can have high-performance hardware requirements (e.g. running an SGX or FPGAs for generating zero-knowledge proofs).
For traditional organizations, AppChains offer a way to dip their toes into Web3 without going fully permissionless from day one; for example, companies could require KYC’d validators, prescreen developers who want to build on their network, and select which chains they want to bridge assets to/from.

Value Capture

While generalized scalability solutions lowered transaction costs while preserving security and developer experience, they offered few monetization opportunities for developers.
On the other hand, there is a strong business case for AppChains because applications are able to fork existing protocols and monetize them within their ecosystem (e.g. trading fees from an enshrined AMM or NFT marketplace).
In addition, their token benefits from additional token sinks from being used as the security model (i.e. staking token or gas token), as well as a market repricing of that token to something closer to an L2 or L1 token.
Furthermore, an application is able to capture MEV by running its own sequencers or validators, which can create opportunities for new cryptonative business models; for example, dYdX validators, who will likely be market makers, can offer low or no fees for users but give them slightly worst execution prices, similar to the payment-for-order-flow model that Robinhood uses.
As another example, many successful games have tons of mods, extensions, skins, etc., and actively try to be as moddable as possible. But most of the time, modding is done by hobbyist gamers who struggle to monetize; if that game were an AppChain then mods can extend that IP on top of a rollup and monetize through the use of that blockspace.

Issues with AppChains

These benefits do not come without several issues, however:

Limited composability and atomicity

AppChains add a degree of isolation to infrastructure and users within other ecosystems. While this does not break composability (i.e. you just need sufficiently good bridges across the same VMs), it does break atomicity (an “all-or-nothing” property whereby either all sub-actions within a single transaction are executed, or none of them are).
That said, while atomicity is a special property from having all applications on the same settlement layer, it is not critical for many applications (e.g. P2E games do not rely on flash loans for a functioning economy).

Recreating walled gardens

As a thought experiment, if all AppChains have permissioned read/write access, the resulting market structure would limit permissionless & composable innovation for developers and the ability for users to transact freely and opt out of systems, effectively recreating the issues that crypto aims to solve.

Liquidity fragmentation

With AppChains, liquidity or assets from other layers or chains will need to be bridged over to that application and vice versa. While this is possible with bridging infrastructure, it adds an additional layer of friction for end-users.

Reflexive security model

If the application token is used as the security model, there exists an edge case where if the value of the token drops to 0, there will no longer be economic security for the application.

Waste of resources

AppChains can be a waste of resources (physical or economic) if the application does not command enough usage. If the AppChain has dedicated validators, those validators could be deploying their resources more efficiently elsewhere.

Additional developer lift

Because it is not as simple as deploying a smart contract, there will be additional complexity in managing additional infrastructure, such as sequencers or validators.

Limited ecosystem tooling & support

There might not be “out-of-the-box” resources like block explorers, RPC providers, indexers, oracles, fiat on/off ramps, and ecosystem funding.

The Emerging AppChain Market Structure

Because of the many downsides of building in a more isolated ecosystem, AppChains are best suited for applications that have:

Reached some notion of scale (e.g. number of users, amount of protocol revenue, TVL) and product-market fit
Significant product/performance benefits from dedicated blockspace
Fewer requirements for security and atomicity (e.g. P2E games, NFT collections, cryptosocial)

As such, it stands to reason that the majority of applications will continue to be launched on L1s and L2s with shared blockspace. Furthermore, because the L2 landscape is still quite fragmented, we will see teams, especially DeFi protocols, continue to launch on L1s because of their security, liquidity, and atomicity properties, the latter of which is particularly important because flash loans provide effectively infinite capital efficiency with zero balance sheet risk. In addition, non-DeFi applications will likely launch on generalized L2s and move to app-specific L3s or app-specific L1s if they develop a large enough ecosystem and network effects. We can roughly visualize this order of operations as the following:

It also stands to reason that most applications launching AppChains will choose modular execution layers (particularly roll-ups) rather than monolithic chains because they don’t have the capital required to bootstrap a large validator set. Moreover, it is unlikely that high-quality validators will choose to direct their resources towards an AppChain whose token has a low and unstable market price.

That said, more applications will still continue to launch their own AppChains as the crypto industry matures and gains adoption, and the future AppChain market structure will have many flavors:

App-specific monolithic blockchains connected by a variety of bridges
App-specific sidechains connecting to a monolithic chain
App-specific rollups that settle on a monolithic chain
Sovereign app-specific rollups that don’t utilize a settlement layer

The AppChain Design Space

There are several design tradeoffs to consider when deciding which AppChain infrastructure to build on:

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

Shared: State secured by multiple heterogeneous validators, likely run by different parties (e.g. Polkadot parachains, Skale)
Isolated: Security provided by the application itself; likely using application-owned validators or sequencers, and using the application’s token for economic stake (e.g. Cosmos chains, Axie Ronin)
Inherited: Security provided by an underlying settlement/consensus layer (e.g. zkSync, Optimism)

Security Source: From where does security come from and where does settlement occur?

Ethereum: Uses Ethereum as the settlement layer for fraud proofs, validity proofs, and general double spend protection (e.g. Arbitrum, zkSync)
Non-Ethereum L1: Uses non-Ethereum security and potentially has a different consensus model altogether (e.g. NEAR Aurora, Tezos rollups)
Application token: The application’s token is used as crypto economic security (e.g. Avalanche subnets, Cosmos chains)

Permissioning: How are nodes selected and who could read/write to state?

Permissionless: Anyone could read/write contracts and validate state transitions (e.g. Optimism, StarkNet)
Permissioned-by-choice: Only whitelisted validators/developers can read/write/validate the chain (e.g. Polygon Supernets, Avalanche Subnets)

Composability: How easy and safe is it for liquidity and state to move across other applications within the same ecosystem

Full: Moves to any application with minimum latency and maximum security (e.g. Polkadot XCMP, Cosmos IBC)
Limited: Has limitations with connectivity, latency, and/or security (e.g. Avalanche Subnets, Polygon Supernets)

Finality: When are transactions considered final? (Assuming probabilistically final is considered final)

Instant: Usually with BFT consensus mechanisms (e.g. NEAR Aurora, Evmos)
Eventual: Usually with rollups, where a transaction can be considered final once the block has been posted to L1 (and assuming data is available) (e.g. Arbitrum, zkSync)

Gas currency: In which token do users pay for transactions?

Non-application token: Usually the base asset of the L1 or L2 that the application is built on (e.g. Ethereum, Evmos)
Application token: Usually the application token itself is running on an app-specific L1 or L2 (e.g. Avalanche Subnets, Osmosis)
None: The L1 or L2 validators or application subsidizes hardware costs for users. (e.g. AltLayer, Skale)

There are several other more straight-forward factors:

Required Stake: The amount of stake required for applications to have validators to secure their 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: The ability to support both Solidity and EVM opcodes without having developers modify their codebase

We can map the existing AppChain solutions according to these factors:

As of October 3, 2022; Not comprehensive

Conclusion

Despite the existing issues with AppChains, developer demand points to their continued growth. As demonstrated by Apple, vertical integration often leads to better UX; similarly, blockchain developers will look to deliver fully-optimized web3 applications, which AppChains enable. That said, AppChains are not for everyone and developers should think deeply about their application’s needs and the inherent trade-offs prior to dedicating resources towards launching one.

There are many implications to security model economics, monetization strategies, platform defensibility, overall value accrual across the stack, and second-order effects on crypto market structure that will be exciting to observe over the next several years.

If you are building AppChain-focused infrastructure or applications, please reach out!

Many thanks to Josh Bowen, Cem Özer, Pseudotheos, and Dan Elitzer for conversations around this topic.

You could follow me on Twitter here.