Does Saga Support Appchains or Rollups?
Introduction
As the number of users of public blockchain networks grow, much experimentation, innovation and investment has been poured into making blockchains more scalable. Public blockchain networks can be segmented into one of three categories: “monolithic”, “modular” or “multichain” — each with their own trade-offs in regards to scalability, security and decentralization.
In a previous post, we discussed how Saga’s original vision as a ‘chain to launch chains’ fits squarely into the multichain mold of blockchain architecture. That said, as our technology has matured, we’ve realized that our automation technology can play a critical role in modular blockchains as well. In this blog post, we’ll touch upon the key distinctions between multichain blockchain networks (otherwise known as appchains) and modular blockchain networks (which heavily rely on rollup technology). We’ll discuss how Saga’s partnership with Celestia is an important first step to making Saga one of the key infrastructure providers across all of Web3. Finally, we’ll go over blockchain design from a developer’s point of view and the trade-offs that must be considered when deploying to different kinds of dedicated blockspace. Let’s dive in.
Saga Automates the Deployment of Appchains
Saga’s original design is meant to provide critical infrastructure to the appchain vision, where the Saga protocol abstracts away the creation of a blockchain by leveraging IBC. All blockchains deployed via Saga’s tooling come equipped with IBC for cross-chain communication and are validated by the same validator set for the Saga mainnet. IBC is utilized, along with interchain security, to secure new blockchains. Should validators ever misbehave in their validator duties, IBC is utilized to relay this misbehavior back to the Saga protocol, where a validators’ financial stake can be slashed.
Most public blockchains (and Saga chainlets) have four core components: Consensus, Execution, Data Availability and Settlement. More explicitly, Consensus is related to the mechanism whereby validators/miners can come to agreement on the order of transactions (also known as messages) for a specific block. Execution refers to the computation required to make state changes from a set of transactions in a new block. Settlement refers to the finalization of any state-transition on a blockchain. Data availability refers to the notion that data posted on the blockchain can be downloaded by anyone to verify that the history of transactions is valid.
Appchains are centered around the premise that blockchain applications should have their own dedicated blockchain. When appchains are created, much effort goes into recruiting validators who are responsible for validating the chain, and each validator plays a role in driving consensus, execution, settlement and data availability for the new network. Each appchain maintains its own validator set, and when appchains are built with a standardized tech stack (like Tendermint, ABCI and the Cosmos SDK), it opens up the possibility for appchains to communicate with each other in a trust minimized way. Inter-Blockchain Communication (IBC) is the crown jewel of the Cosmos tech stack and is the protocol that enables sovereign appchains to communicate with each other, despite each chain having its own unique validator set.
Modular Blockchains — A Different Paradigm
A chain that is structured in a modular way will differ from appchains in one key manner: validators are only responsible for a subset of execution, consensus, data availability and settlement. For example, when Ethereum launched in 2015, validators were responsible for all four functions, but as the protocol has matured, the ecosystem has gradually shifted in the direction of modularizing the network. Layer 2s like Polygon, or rollups like Arbitrum and Optimism, are where an application’s transactions are ordered and executed. Eventually, this data will be posted to the Ethereum mainnet, where validators are only responsible for final settlement and data availability. Because validators are not responsible for ordering and executing transactions for Layer 2s or rollups, the infrastructure requirements for validators on Ethereum is much less than validator requirements for most appchains within the Cosmos ecosystem. This helps to ensure the validator requirements are manageable, which supports the decentralization of the overall network.
Celestia — like Saga — is building on top of the Cosmos SDK and utilizing Tendermint consensus. One of the key pioneers in modular blockchains, Celestia allows developers to build their own plug and play rollups to order and execute transactions on top of Celestia’s data availability and consensus layer.
What makes Celestia unique is that they can decentralize their base layer via a novel technique called data availability sampling (DAS). DAS refers to the process of obtaining data from nodes on the network in an efficient and scalable manner. Celestia will sample data from only a subset of nodes, rather than every node in the network, to ensure fast and reliable data retrieval. The results obtained from DAS can be used to ensure the security and integrity of the network. DAS are typically done by light clients and provide a check that the validators of the network are behaving in an honest manner. As more light clients are added to the network, the Celestia chain can scale to include more and more data in the base layer.
The base layer of Celestia, with Data Availability Sampling, is a reasonable solution to maintaining decentralization at a base layer. Put another way, DAS helps to decentralize settlement and data availability of a modular blockchain network. But what about the execution and consensus layer for Celestia or any other modular network? Is that also sufficiently decentralized?
Modular Blockchains — What’s the Rub?
The modular framework is not without its drawbacks.
Consider dYdX — a popular crypto trading application deployed on Starknet, one of the leading ZK-rollup solutions on Ethereum. Starknet currently utilizes a single sequencer — an entity that is responsible for ordering and executing transactions within a particular block. While single sequencers are able to execute and order transactions very quickly, single sequencer rollups are, by definition, not decentralized. Decentralization implies the existence of multiple entities, where no one entity has control over a particular function. Furthermore, if one defines a blockchain’s decentralization by its most centralized part (like how a steel chain is only as strong as its weakest link), then modular blockchains can’t be considered to be decentralized if the sequencer set for rollups is dominated by only one or a few entities. It is for this reason that dYdX recently made the move to Cosmos, where there is a viable tech stack that can properly decentralize the execution of transactions for their suite of trading applications.
Starknet isn’t unique in regards to its centralization issues. Arbitrum and Optimism — two other rollup solutions on Ethereum — also rely on a single sequencer set to execute transactions. Rollups on Celestia suffer from the same issue of centralized sequencers as well. Rollups — while an interesting technology and a key part of modular blockchains — must have multiple sequencers in order to be able to properly decentralize the application layer. If multiple sequencers were available for rollups, then modular blockchains can effectively solve the blockchain trilemma — scalability can be achieved without sacrificing security or decentralization. But how would one decentralize a sequencer set, and preferably do so in an automated way to make it easy for developers? Enter Saga.
Saga X Modular Blockchains
While Saga was originally focused on furthering the multichain vision by automating the creation of new appchains via IBC, Saga’s automation infrastructure can also be utilized to decentralize a key aspect of modular blockchains in a scalable way. Recently, Saga announced a collaboration with Celestia to implement a sequencer-as-a-service to scale rollup architecture. The solution will enable applications on Celestia rollups to have a decentralized sequencer set, where the sequencer set is Saga validators that offer their services to order and execute transactions on Celestia. By utilizing the Saga validators as sequencers, it solves the centralization issue that plagues many rollups, since they often rely on a small set of sequencers. As opposed to a rollup having to rely on one sequencer, it can have as many sequencers as there are active validators in the validator set for Saga. Also, by utilizing Saga validators for sequencing, rollups can rely on the added economic security from the Saga mainnet, which ensures that validators, turned sequencers, are incentivized to act correctly. More specifically, the Saga and Celestia collaboration can deliver the following:
- Saga provides a service to organize validators into sequencers and punish misbehavior via shared security.
- Validators become sequencers via a rollup scheduler on a weighted per-epoch basis.
- The service has a mechanism to detect two types of faults: for invalid block production, a fraud proof, and for offline & censoring, a challenge to process a set of transactions.
- Celestia is the underlying data availability layer that securely persists and makes available the data needed to generate fraud proofs and offline censor challenges.
- Communication between rollups and Saga will be handled via optimistic rollup IBC.
Put another way, in the same manner that Saga validators can take turns proposing new blocks for an appchain, Saga validators can also take turns proposing new blocks for a rollup on Celestia. In either situation, should a validator ever misbehave with the validation or sequencing duties, their misbehavior can be relayed back to the Saga mainnet via IBC, where the validator’s stake can be slashed. The key distinction is that with Saga appchains, all aspects of a public blockchain — consensus, execution, settlement and data availability — is tied to the economic security of the Saga mainnet; with a Celestia rollup, the underlying data availability and settlement is secured by the Celestia chain, whereas execution and consensus is secured by Saga. Having multiple chains secure a blockchain transaction is a relatively novel concept within Web3, and if the collaboration is successful, it opens up the possibility for Saga’s infrastructure to decentralize sequencer sets on any modular blockchain, including Ethereum. As more blockchain networks like Ethereum modularize their tech stack, there will be a greater need to decentralize sequencing across all of Web3.
Saga Chainlets vs Rollups
From a developer’s perspective, a relevant question is: should I deploy a full blockchain on Saga or a rollup on Celestia? The answer to this question depends on how a developer views the trade-offs between deploying to a modular blockchain vs an appchain.
Because validators who provide sequencing services on rollups are only required to execute and order transactions, validators do not need to commit as many resources as they would for a fully provisioned blockchain, where validators are also responsible for data availability and settlement. As a result, deploying a rollup on a modular blockchain like Celestia or even rollup layers on Ethereum should be more cost-effective to the end developer.
On the other hand, a fully provisioned blockchain can very easily connect to other blockchains via IBC. One of the necessary conditions for IBC to connect sovereign blockchains is that both blockchains must have deterministic finality for its transactions. Deterministic finality ensures that transferred tokens aren’t exposed to double-spend attacks, which may be possible if a chain’s transactions can be rolled back. Because rollups are not responsible for final settlement (this is the responsibility of the base-chain), it is difficult to connect rollups to an interconnected universe of blockchains. This makes it infeasible for rollup applications to communicate with other chains via IBC. So while a fully provisioned blockchain may be more expensive than rollups, it comes with the added benefit of being able to communicate with other chains. From a developer’s point of view, the choice of deploying onto a rollup vs deploying onto a blockchain may depend on the pros and cons of bottom-line costs vs cross-chain communication.
Conclusion
Modular blockchains are here to stay and will offer different ways to scale blockchain networks and contribute to the growing Web3 movement. Saga’s validator orchestration infrastructure is well-positioned to service both modular and our own multichain ecosystem, offering validation services to Saga-provisioned blockchains and sequencing services to rollups on modular chains.
Our partnership with Celestia was just the beginning. Using similar architecture, Saga is able to offer automated deployment of any dedicated blockspace. A few weeks after Celestia, Saga announced a partnership with Polygon, whereby we will automate the instantiation of their Supernets. As Web3 grows and needs more blockspace for scaling, Saga will be in a great position to meet the need for easy deployment of this blockspace and serve as critical infrastructure for the greater industry.
