This blog post outlines the choices that a sophisticated dАpp faces if they decide that the features of the smart contract are not enough (hitting the EVM constraints). It showcases the options they have - to become an app-chain or app-rollup. Lastly, it suggests some advancements in terms of infrastructure and protocols that can help the app-rollups become a viable choice for many sophisticated dАpps.
When Smart Contracts aren’t Enough
Arguably, the programability of the blockchains via smart contracts is the single most important factor that enabled web3 to gain traction. While this programmability is needed in order to foster the creativity of millions of developers around the world, smart contracts also come with limitations. These might be technical limitations - like missing a certain function or use-case-specific limitations - insufficient speeds, expensive operations etc.
Some dАpps start as smart contract-based applications, but eventually need their own sophisticated features, better costs or speeds. Some notable examples of these are Axie Infinity and dYdX.
Others cannot start as smart contracts due to the said limitations, and opt to go directly for a more sophisticated approach.
It is at this point that they arrive at crossroads, and need to decide their path forward. One option is to create their own chain and become an app-chain (requires the bootstrapping of own security). Another option is to create their own rollup and become an app-rollup (inheriting the security of L1).
Becoming an app-chain
The first viable option is launching its own chain. This gives the app the flexibility it needs in order to realise the use case needs. With App-chains the developers can:
- Have complete control of their tech stack - Complete control over the stack and infrastructural choices needed in order to realise the sophisticated use case.
- Have speed through focus - Ability to quickly steer and influence the app-chain development.
- Make specific use-case tradeoffs - Some dАpps are willing to sacrifice speed for lower costs, while others would do the opposite. The point is, with app-chains you can do any tradeoff that makes sense for your use-case and users.
- Interconnect with other highly specialised app-chains - While this is not necessarily true for all app-chains, for the ones built in the Cosmos, Polkadot or Avalanche ecosystems it is. In those ecosystems, app-chains are at arm's length and can be leveraged to even better use cases.
On paper, app-chains make complete and total sense, however, there is a hidden downside that needs to be pointed out.
App-chain developers need to procure their own validator set. This means, finding and persuading (normally through economical advantages and incentives) validators to start and continue validating your network. If you find too few of these, your app-chain will suffer massive centralisation. In practice, a very small percentage of app developers have the connections and resources to pull off getting a big validator set. This limits app-chains as a viable approach only to the most connected and resourceful groups.
Becoming an App-rollup
The second viable option is launching your app-rollups (sometimes referred to as L2/L3s). App rollups have similar flexibility to app-chains. With app-rollups developers can:
- Have good control over the tech stack - Control over the stack with limitations depending on the choice between validity and fraud proofs.
- Speed through focus - Similarly to app-chains, they can move at much greater speeds than a generalized system.
- Make specific use-case trade-offs - Again similarly to app-chains, app-rollups can make different trade-offs needed for the use case.
- Derive security from L1 - The security of the rollup comes from the security of the main-chain. This means that app-rollups do not need to worry about the validator set for their rollups.
While the last point is a major advantage of app-rollups over app chains, again, we find ourselves at a place where a hidden downside exists.
Unlike app-chain ecosystems, app-rollups don't have access to primitives that have proven valuable. App-chains within Cosmos and Polkadot can plug into existing infrastructure and utilise them through the use of IBC/XCMP. However, if an app-rollup needs a DEX it must build it on its own chain and bootstrap the liquidity. The same example is true for stablecoins, NFTs and NFT marketplaces etc. You get the point. In theory, you can go through bridges or through L1, but these are limited solutions and most dApps would need a more sophisticated interaction (f.e. a data oracle).
The Inflection Point for App-rollups
The main reason that hinders the existence of app-rollups is the lack of proper cross-rollup communication protocol and infrastructure. If we are to speculate, the creation of such infrastructure would be the inflexion point for app-rollups. It will remove their major downside.
Firstly, such an infrastructure would need to be able to pass arbitrary data messages between rollups. Secondly, such an infrastructure needs to be extremely easy to integrate into the app-rollup. Thirdly, the infrastructure should be scalable. Ideally, adding new rollups should reuse existing infrastructure.
Lastly, the infrastructure should be completely decentralised. This means using validity proofs to ensure security and crypto-economical incentives to ensure the liveness of the system.
If a protocol that meets the four requirements above comes, app-rollups can use it and create an ecosystem around it. App-rollups won't exist in a vacuum anymore and use cases won't be limited to the few groups with enough connections and resources to pull off an app-chain. This cross-rollup communication protocol, however, is a complex piece of work and is yet to come to life.
Conclusion
Complex dApps that cannot be efficiently expressed within smart contracts, face the choice between becoming an App-chain or an App-rollup. App-chains offer the freedom to express the business logic of the dApp but require complex social and crypto-economical coordination in order to procure and maintain an active validator set for its chain. App-rollups don't need a validator set as they derive their security from L1. App-rollups, however, currently exist in a vacuum and don’t have access to an ecosystem of services/dApps that is needed for the successful execution of most sophisticated use cases.
We describe an infrastructure that will enable app-rollups to interoperate and create a network for themselves, thus removing the ecosystem limitation and becoming a viable choice for most of the use cases. We strongly believe such infrastructure will be created soon.