Application Specific Blockchains vs Application Specific Rollups
Table of Contents:
Introduction
Appchains (Application-specific blockchains)
Appspecs (Application-specific rollups)
Case Study on dYdX on Cosmos vs dYdX ZK-Rollup
Conclusion
Introduction
There is an increasing amount of focus on application-specific networks, especially with the release of the Cosmos 2.0 whitepaper in September 2022 and dYdX’s announcement of its transition from ZK-rollup to Cosmos IBC appchain. The goal of this paper is to show the tradeoffs between pursuing an application-specific blockchain versus a traditional application-specific rollup as found on Ethereum. More specifically, this paper will only focus on Cosmos appchains vs application-specific ZK rollups. Finally, we evaluate both appchains (application-specific blockchains) and appspecs (application-specific rollups) through three areas of criteria: technology, user experience, and developer experience.
What are Appchains?
Application-specific blockchains dedicate their blockspace to a specific application instead of multiple applications unlike generalized blockchains. This enables developers to have more freedom over the economic structure, governance structure, and consensus algorithm for their app. Appchains also operate and improve on existing L1 blockchain structure and use the validators from the L1 the app is based on.
There are a few concrete benefits of appchains compared to L1 or L2 scaling solutions like performance, customizability, and value capture. Compared to L1’s, appchains don’t have to compete against other apps for computation and storage which results in an increased capacity for performance and the ability to keep transaction costs and latency low and predictable for end users. End users also benefit from the way appchains are able to optimize applications and make design choice trade-offs depending on the specific needs of the dapp. In addition to capturing more end users, appchains benefit developers from the economic value capture that occurs from forking existing protocols and monetizing them within their ecosystem and pay-as-you-go scalability.
Appchain issues include include a lack of security guarantees, lack of composability, bridging risk, and a high barrier to entry associated with cost and team time. The security of smart-contract applications comes from the underlying L1s and the incentive to keep the L1 secure is shared by all of the applications that are built on top of it, making it harder to attack. In contrast, appchains only have a single application built upon them so they do not have the benefit of working with other parties for security. The security of appchains is partially dependent on the adoption of the application and the price of the application’s native token so if adoption is weak and token price is low, it is possible for attackers to acquire enough stake of the network. Additionally, appchains in their original design lack the atomic composability that is one of the main advantages of building applications such as smart contracts. Since each application is hosted on its own chain, interactions between applications require cross-chain bridging or messaging which can be an inconvenient experience for users or developers. This bridging also creates a risk for exploitation and appchains might not be able to attract reputable and well-funded bridges. The independence of appchains creates problems related to a lack of support that applications might otherwise receive if they are developed on more built-out L1s with resources and reputation. Most importantly, the technological resources required to run secure appchains combined with the lack of ecosystem tooling and support that L1s provide create a high barrier of entry for smaller, less experienced developers to build their own chains.
In this discussion of application-specific blockchains, this paper will focus on those found within the Cosmos ecosystem and other models such as the Polkadot parachain or the Octopus Network relay-appchain will not be discussed.
What is Cosmos?
The Cosmos network of blockchains is a popular innovation in blockchain technology, and has gained a lot of traction recently. Cosmos is a technology that enables the creation of standalone blockchains with strong cross-chain capabilities. These chains are based on the Tendermint PoS consensus systyem, which uses a variation of the PBFT consensus model, Polka. Each chain can have its own set of validators and native token.
Furthermore, Cosmos uses a hub and zone where zones (independent blockchains) are connected through the IBC protocol. Block commits from zones are posted to the Hub, allowing the Hub to monitor the state of each zone. In particular, the Cosmos Hub functions as the central ledger for the Cosmos ecosystem.
All appchains on the Cosmos network use the Tendermint core which consists of several components and is key to a Cosmos blockchain’s architecture. Furthermore, an equally key component in the Cosmos infrastructure is the Interblockchain Communication Protocol (IBC) and the Application Blockchain Interface (ABCI). ABCI functions as an outlet to plug in applications to connect to Tendermint consensus, etc. It is extremely flexible and allows for an application to be written in any language and deployed. IBC is responsible for facilitating token transfer communication between cosmos appchains.
Pros and Cons of Cosmos
Interoperability
An important feature of Cosmos appchain architecture is the IBC protocol. It allows for independent blockchains to bridge with each other. IBC uses light clients which verify the consensus of transactions directly and messages are sent through a relayer. Relayers connect to full nodes of both chains and connect to communicate data between them. Once proofs are validated by the IBC light clients, the data from the relayer is stored on the destination chain. IBC sacrifices some flexibility for the sake of security, as these light clients must run on both connecting chains and both chains must have instant finality for compatibility.
Infrastructural advantages/disadvantages
Currently, IBC is still in its infancy as it was only earlier this year that Cosmos allowed the ability to call functions on blockchain B from blockchain A. This feature is to receive another expansion in the near future. The Tendermint core is responsible for the characterization of the chain and is provided to developers with the hope of plug and play adoption. In other words, developers need not worry about constructing an entire blockchain for their application, as they are essentially given a kit to make their own with a proper validator set as well.
Cosmos uses its Tendermint core to provide out-of-the-box functionality to its developers. The Tendermint core components include a transaction pool, the Polka consensus mechanism, the ledger, and a message passing system. Tendermint has yet to see or match network activity that Ethereum mainnet routinely experiences. Furthermore, there remains a large question on scalability for Tendermint’s validator node infrastructure, as previous studies have shown that to be a vulnerability within the Tendermint consensus mechanism due to its enforced wait time to prevent knowledge of the next possible validator for block proposal.
Ultimately, what this means is that there’s an eventual decentralization and scalability trade off as the number of nodes increase for a Cosmos blockchain, and with no modularity, this will serve to be a massive problem in Cosmos’ future. Nevertheless, it cannot be understated that Tendermint does provide high throughput.
Appchain Tokenomic Considerations
Because appchains are built on the premise of sovereignty, and thus pay for their own security, they also may decide to take on different token integrations to their chain. Oftentimes, appchains use their own token as the native currency to pay validators and ensure the security of the chain. This leads to various different tokenomic models that often use emissions or some synergistic element to incentivize users to help ensure on-chain security. For example, for the popular DEX chain Osmosis, token emissions are allocated to both liquidity providers and to stakers. However, here presents its own problem for tokenomic design. If you allocate more emissions to one avenue, there runs the risk of over-prioritizing certain avenues. Why would a user stake when they can simply participate in some other way that provides more yield?
Sovereignty
The sovereignty that Cosmos appchains provide cannot be matched unless a protocol intends to pursue building its own blockchain from scratch, a very laborious, resource-intensive pursuit. Furthermore, sovereignty can help with performance optimization. Different applications have different requirements from their native chain. For example, an on-chain game needs speed more than DeFi applications, and DeFi applications need decentralization more than an on-chain game. While sovereignty may provide some flexibility and freedom, it still comes with its own difficulties. For example, there will likely come a point where incentivization needs to occur across zones for some set of parties. This presents difficulties for the appchain thesis because with little liquidity fractured across chains, it is hard to align incentives for users and other parties, especially across zones.
EVM Maturity and Coding Experience
Because of the ABCI in the Cosmos SDK, any language can be used to create an application and essentially bolted onto the Tendermint core. As for EVM compatibility, as of this point in time, Evmos is the only EVM-compatible appchain, which launched on March 1st and was subsequently halted temporarily on March 6th. The chain’s failure was a result of the increasingly high number of integrations needed for proper functionality. Eventually, these flaws were fixed after halting the chain and some communication between the Interchain and Evmos teams. It is currently fully functioning.
MEV Capture
Unlike all current ZK-rollups, Cosmos appchains can capture protocol MEV. This can be good for a protocol because it can redistribute some of this value to possible stakers and helps create a more synergistic token security model. Currently there are two projects focusing on MEV capture within the Cosmos ecosystem: Mekatek and Skip Protocol.
What are ZK-Rollups?
The general purpose of a rollup is to bring scalability for its connected L1. Rollups promote a modular structure in blockchain design, where there exists different layers of blockchains specialized with the purpose of connecting to form a greater system.
Rollups function by updating an on-chain smart contract that contains a state root (a Merkle root of the state of the rollup). Someone publishes a batch (collection of compressed transactions) that are sent to the contract along with the previous state Merkle root and a new state Merkle root.
The smart contract checks to see if that previous root matches the current state root, and upon confirmation it switches the state root to the new proposed state root. To verify the validity of the post-state root suggested in the batch, ZK-rollups use validity proofs, where batches contain a ZK-SNARK that proves that the new state root is the correct result of the batch.
Rollups have their fair share of benefits and hiccups, and it's important to review them both as narratives change and new technologies emerge; in other words, do rollups really have as much potential as many think? And moreover, can application-specific blockchains compete with rollups?
Pros and Cons of ZK-Rollups
Sequencer and Prover Centralization Risk
Currently, across almost all rollups, there is a large centralization risk. This is because most rollups have centralized sequencers, provers, or some combination of centralized infrastructure that allows for a single point of failure. zk-Rollups require provers to generate proofs to verify the validity of their batches of transactions. Users send their transactions to a centralized sequencer on the rollup which then executes transactions and packs them into a rollup block. Centralized provers create a proof for that rollup block which is then uploaded to Layer 1 Ethereum for verification. There exists a substantial amount of centralization risk here as both the prover and sequencer are centralized. Because of this centralization, there runs the risk that StarkWare could front-run their own customers on their rollups, application specific or not, and gain profit through MEV. Furthermore, the centralization of both the sequencer and the prover on Starkware products, like the former dYdX chain allows for a single point of failure, making the entire network vulnerable to internal error or external attacks. This is likely not in the interest of StarkWare as frontrunning users would likely hurt more than creating an advantage for them in the long run.
EVM Maturity and Coding Experience
Solidity is fundamental to the basis of dapp development, and thus most blockchains go through the process to make their network EVM compatible. This allows for easier migration for developers to launch their applications. All current application specific zk-rollups are based on Cairo, as zkEVM technology is still in development. Cairo is not an easy programming language, hence why Starkware developers use a transpiler to help bridge this programming gap; however, there are still difficulties. The documentation for developers to learn Cairo is not widespread or easily found, making dev adoption significantly more challenging, in comparison to Cosmos and its plug and play.
While Starkware specific rollups may not be EVM compatible, rollups such as zkSync will eventually provide EVM compatibility, and while these developments are underway, they are unlikely to be the last and there is a high probability that many more EVM-compatible ZK-rollups emerge within the coming years. There already exist a few different zkEVM projects like zkSync, Taiko, and Scroll, and this trend is unlikely to stop. Furthermore, while not as ideal as a zkEVM, Starkware has a transpiler made specifically to aid developers in transferring code from Solidity to Cairo.
Economic and Infrastructural Advantages
Because zk-Rollups are built atop Ethereum mainnet they piggyback off the security of Ethereum as well. This means that they do not have to have the same security budgets as Cosmos appchains need. Furthermore, rollups have greater potential for scalability simply because they have a greater potential for higher throughputs. This is because rollups are only responsible for transaction execution, and are not tasked with security in the same way as an appchain. Having the ability to outsource parts of your application like security, etc, seems to be an easier method for decentralization and efficiency.
dYdX on Cosmos vs. ZK-Rollups
dYdX is a decentralized exchange platform that launched in 2018, and offers perpetual trading options. It is one of the biggest decentralized exchanges that offers perpetual trading options aside from other competitors such as GMX, GNS, etc. dYdX originally launched on L1 Ethereum, offering trading and lending services. Eventually, dYdX began working with Starkware on an Ethereum L2 zk-Rollup for its services. This rollup was primarily used for dYdX’s perpetual contracts. A year and a half later, the dYdX foundation made the choice to migrate from a zk-Rollup and to pursue an application-specific blockchain on the Cosmos Network.
Practical Comparison
We expect a shift away from the current dYdX tokenomic model to a plan that incentivizes users to stake through a combo of emission-based rewards and protocol revenue. dYdX will have access to a broader community compared to many of the Cairo/Starknet-based applications surrounding its former network. Furthermore, the Cosmos Builder Foundation raises funds from IBC chains and redistributes them to help fund builders, so it is likely that dYdX has received benefits in this regard.
In reference to decentralization, Cosmos is certainly in line decentralization ethos of v4. In the past, the dYdX foundation has stated that it needs a high throughput of around 10 trades per second and 1000 orders/cancellations per second. The Tendermint core would provide dYdX with the throughput it seeks for its trades, order placements, and cancellations, but perhaps would interfere with both decentralization and scalability down the line as the chain grows its user base. As previously stated, as nodes increase, throughput decreases, so there is the possibility of a trade-off between scalability and decentralization hindering progress down the line.
Trade flow may also be better optimized through the IBC protocol, making the user experience possibly better than it was on its previous Starkware rollup.
Conclusion
Ultimately, both rollups and appchains have a reasonable chance of success in the long run, but their success depends on different technological developments. The necessary development for Cosmos appchains is expanding modular architecture, IBC capabilities, and improving Tendermint scalability. ZK-Rollups require better decentralization and developer friendliness if they want to onboard more developers and users. Nevertheless, both of these approaches to scalability present novel solutions for the future.
Check us out @jarrenmims and @joykchen on Twitter!
Sources:
https://dydx.exchange/blog/dydx-chain
https://vitalik.ca/general/2021/01/05/rollup.html
https://arxiv.org/abs/2210.04484
https://arxiv.org/abs/2103.04234
https://medium.com/1kxnetwork/application-specific-blockchains-9a36511c832
https://forkast.news/why-appchains-are-critical-to-web3s-future/
https://polynya.mirror.xyz/zYV0g6II0iREbcaph8362sRBC2_a2hm6NlKj1-yuh6Q