The Benefits and Tradeoffs of Application-Specific Blockchains

Application-specific blockchains (appchains) allow developers to customize infrastructure for different use cases and have unique benefits and tradeoffs to consider.

Although it may seem distant, the 2017 CryptoKitties crash was an early indication of what could happen if a decentralized application (dapp) got too big for the underlying blockchain supporting it. Even today, spikes in the usage of certain applications are crashing some blockchains and causing gas fees to soar on others. To prevent a repeat of incidents like the CryptoKitties fiasco, developers are turning to application-specific blockchains (appchains). Unlike public blockchains, where dapps compete for computational and storage resources, application-specific chains dedicate blockspace to a single application.

Application-specific blockchains allow developers to customize infrastructure for different use cases. Not only does this make development easier, it encourages more innovation and allows web3 developers to build robust value models and scale their dapps to meet exponential growth in demand.

In this article, we explore application-specific blockchains in detail, including the differences in appchain designs, and the benefits and tradeoffs of using application-specific blockchain infrastructure. We also outline and compare current solutions available to developers for creating dedicated blockchains for web3 applications.

What is an application-specific blockchain?

Application-specific blockchains are blockchains created to operate a single decentralized application (dapp). Instead of building on existing blockchains, developers build a new blockchain from scratch with a custom virtual machine (VM) that executes transactions from users interacting with an application. Developers can also customize different elements of the blockchain network stack —consensus, networking, and execution—to meet specific design requirements.

Before the introduction of application-specific chains, developers had to deploy applications on public blockchains like Ethereum. These “shared blockchains” feature a single VM that handles execution logic for different dapps running on the network. In this case, application developers have no control over the underlying infrastructure and cannot adjust aspects like execution or consensus to suit their dapp’s needs.

General-purpose blockchains seemed beneficial at the time since they reduced initial and operating costs for development teams. But using a monolithic virtual machine for execution meant increased competition for computation and storage among dapps. This translated into higher latency and transaction costs for users, especially when a popular application (e.g., CryptoKitties) happened to consume a disproportionate amount of resources.

The introduction of out-of-the-box solutions for building application-specific chains (e.g., Cosmos SDK) gave developers the option of creating custom-built blockchains optimized for a specific application. More importantly, it promised to free dapps from the competition for blockspace—allowing developers to provide lower latency, cost-efficient transactions, and better UX.

Types of application-specific blockchains

Like public blockchains, application-specific blockchains come in different flavors—each designed with specific objectives and featuring unique tradeoffs and benefits. That being said, most application-specific chains fall under the following categories:

Application-specific L1 (Layer 1) blockchains

An application-specific L1 blockchain is one that coordinates consensus and execution on the same layer. Application-specific L1s usually have custom execution, protocol, consensus, and security designs. Moreover, L1 appchains may have a native token for users to pay transaction fees or participate in securing and governing the network.

Application-specific L1 chains can also be sidechains connected to a general-purpose L1 blockchain via a two-way bridge. This is usually the case when an application needs to stay within the ecosystem, but needs a separate execution layer optimized for performance needs. Ronin Network, an Ethereum sidechain dedicated to the Axie Infinity play-to-earn (P2E) game, is an excellent example of this appchain design.

Another variant of the application-specific L1 is one that retains control of certain parameters (e.g., throughput), but shares security with other application-specific L1 chains. Here, different appchains (often in the same ecosystem) run independently while relying on a central set of validators for consensus.

Application-specific L2 (Layer 2) blockchains

Application-specific L2 blockchains separate execution from consensus—transactions are processed on a custom execution layer but settled on a separate blockchain. Layer 2 appchains inherit security from the underlying L1 chain and will often use the latter's native token as the preferred unit of payment.

L2s have “inherited security” in the sense that transactions can only be finalized if the results are accepted on the L1 blockchain. For that to happen, the L1 chain must receive some form of “proof” that shows the validity of off-chain execution (or lack thereof). Such a setup removes the need for developers to bootstrap an appchain’s security, although it increases latency for users.

What are the benefits of using application-specific blockchain infrastructure?

Reliability and performance

Because shared blockchains force applications to compete with each other for blockspace, dapps are susceptible to the noisy neighbor effect. In this scenario, a high-traffic application (e.g., an NFT-based game) might consume a disproportionate amount of resources on a network—affecting the performance of other applications. By deploying on a separate chain, an application can avoid the constraints of an L1 blockchain and offer users lower latency and stable transaction costs.

Performance is another reason to deploy on an application-specific blockchain. Many blockchains have gas limits to prevent certain DDoS attack vectors and reduce hardware requirements for blockchain nodes. But these designs limit throughput (measured in transactions per second) and result in degraded UX when an application surges in usage.

With an appchain, developers can modify gas limits and other runtime parameters to optimize performance for dapps. As most appchains can be permissioned-by-choice, it’s easy to enlist validators that meet specific hardware requirements. For example, an appchain could require nodes to invest in high-CPU hardware or specialized machines (e.g., FPGAs for generating zero-knowledge proofs) to improve execution.

Flexibility

As web3 goes mainstream, applications will need to optimize infrastructure for users and achieve business objectives. An application-specific blockchain infrastructure allows developers to tweak certain blockchain parameters (e.g., throughput, finality, security properties, etc.) to fit particular use cases.

The flexibility of appchains also makes them ideal for enterprise blockchain applications. For instance, companies might desire custom chains that have certain properties (e.g., privacy) or different rules around computation, consensus, and protocol governance.

Having fine-grained control of blockchain infrastructure is also useful in the context of regulatory compliance. Enterprise application-specific blockchains may operate permissioned infrastructure and control who can participate in consensus, deploy contracts, or make on-chain transactions.

Economic benefits

In web3, more value accrues to the underlying protocol than the applications built on top of it (the Fat Protocol thesis). As an example, validators on Ethereum enjoy a large share of the transaction fees and MEV revenue generated from interactions with DeFi applications today.

Conversely, a DeFi application on a native chain can retain 100% of protocol fees. More so, a DEX could decide to capture a larger share of MEV revenue by employing individuals to run validator or sequencer nodes. In this case, excess MEV profits could be redistributed to benefit the application’s community of users (instead of having to share it with others).

Another economic benefit of using appchains is that the application's token’s pricing becomes similar to that of an L1 or L2 token. This is possible where an appchain requires users to pay transaction fees in the app’s token or stake the token to become a validator. In both cases, the added utility can help increase the market value of an application's token.

Sovereignty

A decentralized application running on a general-purpose blockchain cannot propose changes to the underlying infrastructure, except such changes are considered beneficial to the larger ecosystem. The problem here is obvious: the community of the protocol is different from the community of the application.

In contrast, a single-application blockchain aligns the interests of the protocol and the application, so it’s easier to make changes that benefit an application. Such changes could include adding new VM precompiles for extra functionality, changing fee regimes, modifying gas limits, or upgrading key parts of the blockchain.

What are the tradeoffs of using an application-specific blockchain versus a general purpose chain?

Limited composability

Using a general-purpose L1 or L2 is ideal for projects that need better integration with existing assets and smart contracts. A new DEX, for instance, might be better suited to a public blockchain since it provides access to more liquidity and reduces friction in exchanging assets.

Building an appchain reduces interoperability with other applications and breaks composability (with some exceptions, e.g., Polkadot/Cosmos). Users can still bridge funds from other chains, but atomicity (a quality of blockchains where all parts of a transaction succeed or the entire transaction fails) is lost. As a rule, atomic transactions (e.g., taking out a flash loan to buy tokens on a DEX) work when all applications involved live on the same settlement layer.

That said, every blockchain application requires a high level of interoperability with other applications to work, though. For example, using a play-to-earn game doesn’t require taking out flash loans, so running a separate chain (with bridges to chains) for the application may be better in this case.

Security issues

Shared security is one reason deploying on public blockchains like Ethereum is the standard for developers. In contrast, building a secure application-specific from scratch requires bootstrapping a reliable and well-distributed set of validators, which can be difficult to pull off. A possible alternative is utilizing a separate, highly decentralized layer for settlement, but that can increase latency and constrain throughput as seen in current Layer 2 solutions.

This also brings up the issue of token design. Currently, most application-specific chains implement proof-of-stake (PoS) consensus in which application tokens are used as economic stake to secure the network. However, this requires developers to confront complex details around token issuance, burning, and inflation, which is necessary for the security of any proof-of-stake implementation.

Poor token designs can significantly affect the security of appchains. For instance, consider a potential edge case where the market value of an app's token drops sharply. In this scenario, a willing attacker can amass enough economic stake to compromise the network (and possibly perform a 51% attack).

Higher complexity and overhead

Even with out-of-the-box tools like the Cosmos SDK, creating and managing a dedicated blockchain is still difficult. Not only can this distract developers from spending time on building products, but the need for highly technical skills can raise the barrier to entry for new web3 developers.

Relying on application-specific blockchains also increases operational overhead for development teams. Today, web3 applications improve efficiency by outsourcing costs of managing critical infrastructure—block explorers, indexers, RPC providers, exchanges, bridges, oracles, fiat on/off ramps, and so on—to external entities.

Creating an application-specific blockchain would likely require managing critical infrastructure in-house, lowering efficiency and increasing costs passed to users. For this reason, appchains are best for applications that have acquired a large user base and product-market fit and are best served by a purpose-built blockchain network.

Increase in monopoly

The use of “shared databases” (i.e., public blockchains) is what enables competition and healthy rivalry in web3. Since no single application controls user data and assets on the blockchain, a new dapp with a superior or newer design can compete with an established rival from the first day (cf. SushiSwap vs Uniswap).

However, if every application in web3 decided to spin up a new appchain, we would simply have the same data moats and platform lock-in rife in Web2. Moreover, new applications would not have ready access to liquidity and users—reducing competition and fostering the monopolies web3 was designed to reduce.

The state of the application-specific blockchain ecosystem

Cosmos Zones

Cosmos, the self-described "Internet of Blockchains", was among the first proponents of application-specific blockchains. Its core product is the Cosmos Software Development Kit (SDK)—a suite of modules for building application-specific chains called Cosmos Zones. Each Cosmos Zone is an independent network with the power to control the details of its operation (e.g., token economics, fee markets, and security properties).

A Cosmos Zone can communicate with other Cosmos Zones by connecting to a Cosmos Hub. Once connected to a Hub, a Cosmos Zone can exchange information and data with all Zones connected to the Hub using the Inter-Blockchain Communication (IBC) protocol. As such, Cosmos appchains are said to adopt a "hub-and-spoke" model.

The Cosmos SDK provides all the tools for creating and managing aspects of a blockchain, including networking and consensus (based on the Tendermint consensus engine). This helps developers focus on building out the blockchain's application layer instead of contending with low-level details of blockchain infrastructure.

Projects: dYdX (v4), Osmosis, Akash, Juno Network

Polygon Supernets

Polygon Supernets are custom-built blockchain networks dedicated to servicing individual applications. Supernets are powered by Edge, Polygon's solution for creating new blockchains with minimal overhead.

Polygon announced Supernets early this year and believes application-specific blockchains can help web3 applications unlock the benefits of "dedicated hosting". Just as web2 companies improved scale by moving away from shared servers to dedicated servers, web3 projects can improve operations by using custom-built Supernets.

Polygon also solves the problem of bootstrapping a reliable validator set in appchains by implementing a shared security model for Supernets. Each Supernet can opt into a validator service comprising those who have staked MATIC (Polygon's native token). An added benefit of this arrangement is developers can focus on designing tokens with incentives for users, rather than focusing on the subtleties of designing a protocol-level token.

Avalanche Subnets

Avalanche Subnets are sovereign networks with a dynamic validator set providing consensus. A Subnet can have one or more blockchains (“Subnets” refer to groups of validators, not blockchains). Nevertheless, most Subnets in production are dedicated to one blockchain (e.g., an application-specific chain).

Subnets can configure different components of the blockchain to fit design specifications, including fee regimes, governance mechanisms, finality, and processing speeds. A Subnet can also be permissioned-by-choice in which case validators and developers need approval to join the network.

Subnet creators can control who gets to read the blockchain content or write to the chain, making it ideal for traditional institutions making forays into web3. For example, a Subnet may require prospective validators to meet certain regulatory requirements, such as passing KYC/AML checks, before joining the network.

Each Subnet is responsible for its security and doesn't share resources (e.g., computation and storage) with other Subnets. One potential difficulty with this setup is that projects will have to incentivize validators to join a specific Subnet to improve security.

Projects: DeFi Kingdoms: Crystalvale, Crabada, Dexalot

Polkadot Parachains

A parachain is an independent blockchain running in parallel with Polkadot’s Relay Chain. The Relay Chain comprises validators from the Polkadot and Kusama networks and provides security for all connected parachains. To do this, transactions from parachains are aggregated into blocks and passed to Relay Chain validators for validation.

While Cosmos, Polygon, and Avalanche allow anyone to create an application-specific chain, Polkadot uses an auction mechanism to assign parachains. Different projects bid for parachain slots, with projects that bid the highest randomly selected to build a new parachain.

Like Cosmos Zones, Polkadot parachains are expected to have full composability—thanks to the Cross-Consensus Message Format (XCM) system. With XCM, different parachains will be able to exchange data and read each other's states, unlocking the value of interoperability in the process. A potential benefit is that full composability for parachains should make moving liquidity and data across chains easier for users.

Projects: Acala Network, Astar, Interlay, Moonbeam, Kylin

Ethereum application-specific sidechains/L2s

Given Ethereum's status as the most popular blockchain, other blockchains often favor close integration with it. This includes application-specific chains that utilize Ethereum for security (e.g., app-specific rollups) or liquidity (e.g., app-specific L1 chains). Appchains in this category are often designed to improve on Ethereum’s major shortcomings (i.e., low TPS, high gas fees), while reducing friction involved in moving assets/funds from and to Ethereum.

Projects: Immutable X, Ronin Network, Palm NFT Studio

The future of application-specific blockchains

Today, appchains dedicated to file storage (Arweave/Filecoin), decentralized oracles (Band Protocol, Razor, Witnet), and data aggregation/management (Ceramic, The Graph) show the benefits of building dedicated blockchains for web3 applications. And while the application-specific blockchain industry is still nascent, we expect appchains to grow in popularity as more dapps look to scale infrastructure and capture more value.

That being said, application-specific chains do have drawbacks, particularly the lack of access to liquidity, low security, less composability, and high cost of infrastructure. As such, most DeFi protocols will likely persist in using general-purpose L1s and L2s. Occasionally, a DeFi application may switch to a sovereign chain for performance, reliability,customizability reasons—but it must possess significant revenue and considerable network effects to make this change work.

Predictions aside, the Infura team will be following the adoption of appchains in 2023. With Cosmos and Polkadot already working on innovations to further improve the usability, flexibility, and security of application-specific chains for web3 developers, we’re excited to see how this space evolves and to provide the infrastructure support developers need to work on the blockchain of their choice.