The app-chain theory has been implemented in various ways over the years. Over time, the demand for modularity has increased as blockchain developers realize that they can scale their platforms more efficiently by outsourcing some of the work involved in running a dApp.
Initially reserved only for sovereign chains, often built using the Interchain Stack, the evolution of application chains now includes consumer chains that lease security from the Cosmos Hub, and rollups that rely on layer 1 chains to perform some settlement and bridging work, as demonstrated by Celestia. These changes bring with them different security assumptions and problems that need to be solved. Celestia aims to solve a particular problem called data availability, but before we explain how this relates to your project, let’s try to understand the latest buzzword in Web3: modularity.
The work done by a single layer 1 chain, including Ethereum and sovereign #Cosmos chains, can be roughly divided into 4 layers:
The execution layer processes transactions and is responsible for updating the state on the chain. For example: updating your wallet balance when a friend sends you tokens.
The settlement bridge layer is responsible for finalizing transactions, or more precisely, confirming beyond a reasonable doubt that transactions are valid. This applies specifically to Rollups, which we’ll cover later. Lately, the settlement layer is more often viewed as a bridge layer that provides a way for Rollups to communicate with the wider blockchain network, while settlement itself has become a more controversial topic. On regular networks like the Cosmos AppChain, settlement is free because the consensus layer effectively validates every transaction before it reaches the execution layer.
The consensus layer is where multiple parties come to agreement on what a block contains and how its transactions are ordered.
The data availability layer is responsible for ensuring that everyone has access to the correct transactions that have been submitted to the network. As we will explain later, the settlement layer needs access to these transactions in order to verify that the execution layer is honest.
In the context of a Cosmos SDK-based chain (one that has its own validator set and operates as a sovereign application chain), the consensus layer is essentially responsible for data availability and final settlement of transactions. However, launching a sovereign chain requires you to have a set of validators and a proof-of-stake token, unless you choose a shared security solution like Interchain Security. In addition to the legal and operational complexities of launching a chain with a token, there are also scalability considerations to be aware of.
Efficient expansion through aggregation
As networks grow, the scalability trilemma becomes more apparent. At first glance, it may seem that blockchains must make sacrifices in terms of network security, decentralization, or the number of transactions they can process per second. For the overall chain, improving one chain has traditionally come at the expense of another. However, through the work done by Modular Protocol, we can see that some components of this trilemma are specific to each layer in the modular stack.
For example: the execution layer that accepts transactions and processes them into state changes requires fast throughput. Whether it is decentralized and secure is arguably irrelevant as long as there is a sufficiently decentralized and secure settlement, consensus, and data availability layer to guarantee and verify that the correct transactions are being executed. Some degree of decentralization in the execution layer helps with the liveness of the network, but is not critical to preventing any form of misconduct. In other words, it does not affect any trust assumptions about the network.
By modularizing the blockchain stack, developers are able to outsource a lot of the work required to operate a blockchain. Application developers are fully responsible for the execution layer, which improves scalability and significantly reduces development time. This is essentially why rollups are so effective and popular right now. Rollups, often referred to as layer 2, allow one or more servers to execute transactions off-chain without waiting for the slow consensus algorithm to agree on the contents of a block. This may seem unsafe, but they can do it without significant risk by providing computationally expensive proofs of validity in the case of so-called zero-knowledge (ZK) rollups, or by providing a time window in which node operators can submit proofs of failure as evidence that someone has misbehaved, as in the case of optimistic rollups. Within this framework, however, a new problem arises: the data availability problem.
What is the data availability problem?
When a user submits a transaction on a rollup, the message goes directly to a sequencer, which is typically just a very fast computer that batches these transactions together through an off-chain process. After compressing it to a smaller size, the batch is submitted to a settlement layer such as Ethereum. Due to the high demand for block space on these networks, this is a much cheaper solution than posting individual transactions directly to the settlement layer. Currently, most rollups employ a single sequencer (i.e., one entity that performs the ordering), although shared sequencers are being explored. This is generally safe because users can guarantee that the execution of the transaction is valid through proofs of validity or proofs of fault that can be checked on the settlement layer. However, rollups cannot guarantee that the sequencer is honest about the submitted transactions and is sending the same data to everyone.
This is the essence of the data availability problem. It is the job of the settlement layer, or any full node observing the network, to check what the rollup has done, and it needs the transaction data to do this. By default, the rollup cannot easily and cheaply prove that the sequencer processed all incoming transactions into a block, or that all transactions that have been added to the block are in the public domain. Therefore, the sequencer can censor transaction data submitted by users, or worse, prevent it from being verified by the settlement layer.
While technically this type of censorship could also happen on a regular blockchain, it is not practically possible due to the large number of validators in a proof-of-stake network, where only one of them needs to be honest. But more importantly, the settlement layer does not require data to be verified because transactions have already been settled through the consensus process.
#Celestia How to solve this problem?
#Celestia is a layer 1 blockchain built with the Cosmos SDK that provides data availability as a rollup service. Most commonly, the Celestia network receives all incoming user transactions from the sequencer, although it may also be the first recipient of these transactions before they enter the rollup execution, depending on the rollup's configuration. Let's explain this from a transactional perspective with an example. We will assume a fictional network called Roll Protocol, which is built as an optimistic rollup based on the Cosmos SDK.
Let's say you are using Keplr to send some $ROLL tokens to your friend via the Roll Protocol. Once submitted, the send transaction is first transmitted to the Roll Protocol's sorter.
The sequencer is a computer that runs an off-chain process for the Roll protocol, and it now looks at all transactions and tests them against the current state of the Roll protocol to see if they are actually valid. For a message you send, it checks if it contains a valid recipient address, and if you have enough $ROLL tokens to send to your friend, etc.
Valid transactions are then collected into a block and executed by the sequencer, which means making changes to its storage. Your and your friend's wallet balances are updated to reflect the tokens being exchanged.
This block containing the transactions is then shared by the sequencer to Celestia and placed under the "Roll Protocol" namespace, which is really just a label to easily separate data. Validators on the Celestia network then agree on the block contents and it is finalized on the network and distributed to all nodes.
At the same time, all successful transactions that are part of a block are turned into a batch by the sorter and submitted to the settlement layer, which is usually just a smart contract on a layer 1 chain like Ethereum. The settlement layer is the blockchain to which a fault proof is sent if someone finds that a particular transaction is invalid (for example, you don't actually have the funds to send some tokens to your friend). But who are the people who do this work?
Other full nodes run by separate dApps (e.g. DEXs) will also execute transactions at the same time as the sorter does. This enables them to be up to date and provide you with updates on your balances, for example. More importantly, they can check in advance if any transactions are invalid. If so, a proof of failure is submitted to the settlement layer.
As you may recall, optimistic rollups have a time window before transactions are settled. As long as you trust the entity operating the full nodes, having those full nodes check validity ahead of time can help users see transactions as “final” before the optimistic window closes. We call this system “trust-minimized” because you only need to truly trust the network to contain at least one of many honest nodes to skip the optimistic time window.
In order to test if the sequencer is misbehaving, full nodes, as well as the settlement layer, will need access to some data published to Celestia, as the sequencer may have executed invalid transactions. Fortunately, the Celestia network publishes a block containing all incoming Roll Protocol transactions that were previously included in the batch, so we are confident that we have the information needed to prove the honesty of the sequencer if needed.
It is important to note that Celestia does not care what each transaction contains. In fact, it cannot even understand these transactions because there is no execution environment on Celestia that speaks the same language. By separating these concerns through this modular stack, the sorter can focus on executing transactions quickly, the settlement layer can focus on security and providing bridging functionality, and the consensus and data availability layer can focus on decentralization. This greatly improves scalability and optimization by ensuring that each subcomponent responsible for the operation of the network is highly specialized.
Although our examples use Cosmos SDK-based rollups, EVM-compatible rollups are not excluded. Celestia can also operate as a data availability layer for the EVM ecosystem, arguably much cheaper than alternatives such as EIP-4844 (also known as Danksharding) on Ethereum.
Comparison of Rollups and Sovereign Chains
There are many benefits to building a Rollup and using the Celestia network. If you are already developing on an interchain, you can continue to use the tools and software you are familiar with while increasing the throughput of the protocol, eliminating the need for validators on the network, and potentially even launching without a token if desired. Let’s look at some of the differences between building a Rollup and a sovereign appchain:
Scalability and efficiency: Rollups using Celestia will generally provide greater scalability and efficiency than sovereign Cosmos SDK chains. This is because rollups move the majority of transaction processing to Layer 2, allowing more transactions to be processed more quickly, whereas sovereign chains are bottlenecked by the consensus algorithm. If your application requires a large number of transactions, a rollup may be a better fit than a sovereign chain. In this case, your application will need to spend tokens on the settlement layer, which can be expensive depending on the chain you choose, although Celestia reduces the amount of data to be published.
Liveness and Decentralization: Rollups typically run with a single sequencer. Research is underway to build efficient shared sequencers, but this work is still in the works and could reduce the efficiency of the rollup. Currently, decentralization of the execution layer is virtually non-existent. As a result, there is a greater risk that the redundancy and liveness of the rollup will be affected if the sequencer goes offline. Redundancy mechanisms can be designed, but rollup developers inherit the complexity of the infrastructure that is typically shared by validators on sovereign blockchains.
Security: Rollups leverage the security of the underlying settlement layer, while sovereign chains need to ensure the security of their own networks. If you choose to use a sovereign Cosmos SDK chain, you will need to ensure that you have a large and diverse set of validators to secure your network, as well as a large enough market cap (in case you use proof-of-stake) of staked tokens. With rollups, you inherit the security of the settlement layer, which can be helpful if some of the requirements of your app chain are challenging to implement yourself.
Complexity: Building a Rollup system can be more complex than creating a sovereign chain using the Cosmos SDK. This is because of the need to manage interactions between rollups, Celestia, and the settlement layer. If your team has no experience with rollups or doesn't want to deal with the added complexity, a sovereign chain may be a better option. However, using the Rollkit framework makes the development process much easier, allowing you to build rollups with relative ease.
Interoperability: Cosmos SDK chains benefit from the Inter-Blockchain Communication (IBC) protocol, which allows different chains to interoperate. While rollups can interact with other chains, the details will depend on the specific implementation and can be more complex. In most cases, rollups use the settlement layer as a bridging hub.
