In-depth analysis of TIA's potential

Author: Can Gurel, delphidigital

Compiled by: BTCdayu

Source: X, @BTCdayu

Key Points

The overall chain where everyone executes every transaction is fundamentally unscalable. Therefore, a multi-chain world in some form is inevitable. We believe that modular blockchains may be the best approach for a multi-chain world.

Celestia is the first true modular blockchain. "Its vision is to combine the sovereign interoperation of Cosmos with a rollup-centric Ethereum that has shared security."

Celestia scales by decoupling execution from consensus and introducing data availability sampling. This allows Celestia to mimic the characteristics of BitTorrent, one of the most scalable and decentralized protocols to date. In the foreseeable future, Celestia is expected to effectively support any potential user demand while keeping verification costs relatively stable.

Reimagining blockchains as a modular stack has implications beyond scalability. Celestia's unique advantages include trust-minimized bridges, sovereign chains, efficient resource pricing, simpler governance, easy chain deployment, and flexible virtual machines.

Modular blockchains represent a paradigm shift in blockchain design, and we expect their network effects to become increasingly apparent in the coming years. In particular, Celestia's mainnet is expected to launch in 2023.

I. Introduction

The overall chain where everyone executes every transaction is fundamentally unscalable. In fact, this is why nearly every major ecosystem is building a multi-chain world.

As we outlined in our previous article, ecosystems differ in how they envision a multi-chain world. The two approaches that attract the most activity today are Ethereum and Cosmos.

In short, Ethereum envisions a rollup-centric future. Rollups tend to be more expensive and less flexible than L1, but they can share security with each other.

In contrast, Cosmos is an ecosystem composed of interoperable sovereign L1s (called "zones"). While zones are cheaper and more flexible than rollups, they cannot share complete security with each other.

Celestia combines the advantages of both worlds. As a wise person once said, "Celestia's vision is to combine the sovereign interoperable zones of Cosmos with a rollup-centric Ethereum that has shared security."

If you don't fully understand the chart above, don't worry. As we delve into the modular blockchain design paradigm shift of Celestia, we will unravel everything in this article. We will use the first half of the article to answer the "how" of Celestia, and the second half to address the "why" of Celestia. If you are familiar with how Celestia works, we recommend you skip to the second half of this article, where we list its 8 unique properties. You may be surprised to find that Celestia has deeper and more profound implications than it appears.

II. How Celestia Works --- Decoupling Execution

To understand the "principle" of Celestia, we must first define its problem statement. Celestia was born to seek answers to the following question: "What can a blockchain do at a minimum to provide shared security for other blockchains (i.e., rollups)?"

Typically, consensus and validity are the same thing. However, it is possible to view these concepts as independent. Validity rules determine which transactions are considered valid, while consensus allows nodes to agree on the order of valid transactions.

Like any L1 blockchain, Celestia implements a consensus protocol (Tendermint) to order transactions. However, unlike a typical blockchain, Celestia does not reason about the validity of these transactions and is not responsible for executing them. Celestia treats all transactions equally; if a transaction pays the necessary fees, it will accept, order, and replicate it.

All transaction validity rules are enforced by rollup nodes at the client level. Rollup nodes monitor Celestia to identify and download transactions that belong to them. They then execute them to compute their state (e.g., determine everyone's account balances). If any transaction is deemed invalid by the rollup nodes, they will ignore it.

As you can see, as long as Celestia's history remains unchanged, rollup nodes running software with the same validity rules can compute the same state.

This leads us to an important conclusion. Rollups do not need another chain to execute any execution to share security. Instead, all they need is to agree on a shared history of ordered transactions. How does Celestia scale?

While decoupling execution from consensus lays the foundation for Celestia's unique capability, the level of scalability achieved by Celestia cannot be explained solely by decoupled execution.

The obvious advantage of decoupled execution is that nodes can freely execute transactions related to applications they are interested in, rather than everyone executing all transactions by default. For example, nodes of a gaming application (application-specific rollup) do not need to be interested in transactions that execute DeFi applications.

That said, the scalability advantage of decoupled execution is still limited, as it comes at the cost of composability.

Let’s imagine a scenario where two applications want to exchange some tokens with each other. In this case, the state of each application will depend on each other; to compute the state of one application, nodes must execute transactions related to both applications.

In fact, as each new application joins these interactions, the number of transactions that must be executed must increase. In extreme cases, if all applications want to interact with each other, we would revert to the aspects of a single chain where everyone downloads and executes every transaction.

So how does Celestia achieve unparalleled scalability, and how is this related to decoupling execution from consensus?

III. Scalability Bottlenecks

Scalability is often described as increasing the number of transactions without increasing the cost of verifying the chain. To understand where the scalability bottlenecks lie, let’s briefly review how blockchains verify.

In a typical blockchain, consensus nodes (validators, miners, etc.) generate blocks and then distribute them to the rest of the network, which consists of full nodes and light nodes.

Full nodes have high available resources and fully validate the content of received blocks by downloading and executing all transactions within them. In contrast, due to limited resources, light nodes (99% of users) cannot validate the content of these blocks and can only track the block headers (summaries of block data). Therefore, the security guarantees of light nodes are far lower than those of full nodes; they always assume that consensus is honest.

Note that full nodes do not make this assumption. Contrary to popular belief, malicious consensus can never deceive full nodes into accepting invalid blocks because they will notice invalid transactions (e.g., double-spend transactions or invalid minting) and stop following the chain.

The most notorious scalability bottleneck in the blockchain space is known as state bloat. As more transactions occur, the state of the blockchain (the information required to execute transactions) increases, and the cost of running full nodes becomes higher. This leads to an undesirable situation where the number of full nodes begins to decrease while the number of light nodes increases, resulting in the network centralizing around consensus nodes.

Since most chains value decentralization, they want their full nodes to run on consumer hardware. This is why they limit the rate of state growth by enforcing block/gas size limits.

Fraud and Validity Proofs

The invention of fraud/validity proofs effectively eliminates this bottleneck. These are concise proofs that light nodes can efficiently execute to verify whether the content of a block is valid without executing the transactions within it. The advantage of this solution is that any single node with the complete state of the chain can generate these proofs. This is very powerful because it means that light nodes can operate with nearly the same security guarantees as full nodes while consuming several orders of magnitude less resources.

Here’s a simplified example of fraud proofs. In a fraud-proof system, full nodes provide light nodes with enough data to allow them to independently identify invalid transactions. The first step of this proof requires full nodes to indicate to light nodes that a specific piece of data (e.g., a claimed invalid tx) belongs to the block body.

This is relatively simple because Merkle trees can be used to achieve this. By using Merkle trees, full nodes can effectively prove to light nodes that a specific transaction is included in a block without requiring them to download the entire block.

However, while proving the inclusion of a transaction is straightforward, proving the absence of a transaction is not. This is problematic because, as we will see in the next section, proving the absence of a transaction is just as important for fraud/validity proofs to function effectively as proving the inclusion of a transaction.

Data Availability Issues

For full nodes to generate fraud/validity proofs in the first place, they must be able to compute the state --- account balances, contract code, etc.

This requires full nodes to download and execute "all" transactions. But what if a malicious consensus releases the block header but retains some transactions in the block body?

In this attack scenario, full nodes can easily notice data loss in the body and refuse to follow the chain. However, light nodes that only download the headers will continue to follow it because they will not notice any differences.

Data availability is a prerequisite for fraud and validity proofs

Note that this issue applies to solutions based on fraud and validity proofs because, without access to the complete data, honest full nodes cannot generate fraud/validity proofs. If a data withholding attack occurs,

In a fraud-proof system, light nodes will track the headers of potentially invalid chains. Therefore, honest nodes can no longer validate blocks.

In a validity-proof-based system, light nodes will track the headers of chains with valid but unknown states. Therefore, honest nodes can no longer generate blocks. This means that the chain cannot continue without the attacker's consent. This is akin to the attacker holding everyone's funds.

In either case, light nodes will not notice the problem and will inadvertently fork away from full nodes.

The data availability issue is fundamentally a very subtle problem because the only way to prove the absence of a transaction is to download all transactions, which is precisely what light nodes want to avoid due to resource constraints.

Celestia Solves the Data Availability Problem

Now that we have identified the problem, let’s see how Celestia addresses it. Earlier, when we distinguished between validity and consensus, we mentioned that Celestia does not care about the validity of transactions. However, what Celestia truly cares about is whether the block producers have fully published the data behind the headers.

Celestia has extremely high scalability because this availability rule can be enforced by resource-constrained light nodes autonomously. This is accomplished through a novel process called data availability sampling.

Data Availability Sampling (DAS)

DAS relies on a long-standing data protection technique known as erasure coding. While the way Celestia implements erasure coding is beyond the scope of this report, it is important to understand its basic principles.

Applying erasure coding to a piece of data can extend it in a way that allows the original data to be recovered from a fixed portion of the extended data. For example, a piece of data can be erasure-coded to double its size, and it can be fully recovered from any 50% of the extended data. By erasure-coding blocks in a specific way, Celestia enables resource-constrained light nodes to randomly sample a few fixed-size data chunks from the blocks and have a high probability guarantee that all other chunks are available to the network. This probabilistic guarantee is due to the number of nodes participating in the sampling process.

Think of DAS as a game where malicious block producers try to hide data in blocks without being noticed by light nodes. Block producers publish headers. Based on the data root submitted in the header, each light node begins requesting random chunks from the block (along with the corresponding Merkle proof that the chunk contains data).

There are two outcomes to the game:

1. Data is available -> Malicious block producers release the requested chunks from the block based on light node requests. The released chunks propagate through the network. While each sampling light node only samples a small number of chunks, given that they collectively sample more than 25% of the erasure-coded chunks, any honest full node in the network will be able to recover the original block from the broadcast chunks. With the complete block now available to the network, all light nodes will eventually see their sampling tests succeed and be assured that the complete data behind the headers is indeed available to full nodes.

By autonomously verifying whether data is available, light nodes can now fully rely on fraud/validity proofs because they know that any single honest full node can generate these proofs for them.

2. Data is withheld -> Malicious block producers do not release the requested chunks. Light nodes notice that their sampling tests fail.

Note that this no longer poses a serious threat to security because malicious consensus can no longer deceive light nodes into accepting chains that full nodes reject. Therefore, blocks with missing data will appear as active failures of full and data-sampling light nodes. In this case, the chain can be safely recovered through the ultimate security mechanism of all blockchains --- social consensus.

In summary, in either case, the full data-sampling light nodes will ultimately follow the same chain, thus operating with nearly the same security guarantees.

How Scalable Can Celestia Be?

A key feature of DAS is that the more collectively sampled data there is, the larger the data volume can be provided with the same probabilistic availability guarantee. In the context of Celestia, this means that larger blocks can be safely increased (i.e., supporting higher tps) with more nodes participating in the sampling process.

However, DAS has inherent trade-offs. For technical reasons (which we will not discuss here), the block headers of data-sampling light nodes grow proportionally to the square root of the block size. Therefore, light nodes that hope to have nearly the same security as full nodes will experience O(√n) bandwidth costs, where n is the block size.

In terms of scalability, two dominant factors are at play:

How much data can be sampled collectively

The target block header size for light nodes

Either of these will impose limits on Celestia's DA throughput.

Below, we share the current estimates from the Celestia team’s research, considering the first influencing factor.

Importantly, block sizes can be much larger than what is shown here because DAS can be executed by a large audience using limited resources. Even smartphones can participate in the sampling process and contribute to Celestia's security and throughput. In fact, here is an example of a smartphone contributing to Celestia's security!

In practice, we expect the number of sampling nodes to be reasonably correlated with user demand. This is very exciting because it defines Celestia's block space supply as a function of demand. This means that, unlike monolithic chains, as user demand grows, Celestia can offer lower stable fees.

Now let’s zoom in on the second factor; the size of light node block headers grows proportionally to the square root of block size. While this may seem like a limiting factor, over time, the increased resource demands may be offset by improvements in network bandwidth.

Also note that DAS has a compounding effect on bandwidth improvements. If the average light node's bandwidth capacity grows by X, Celestia's DA throughput can safely grow by X²!

Finally, unlike the Moore's Law of computing, which is expected to end sometime in the 2020s, Nielsen's Internet bandwidth law seems likely to continue to apply for decades to come. Therefore, by completely decoupling execution from the chain, Celestia can fully leverage the exponential growth of network bandwidth.

Considering all factors, Celestia is expected to effectively support any potential user demand in the foreseeable future while keeping verification costs relatively stable. By relinquishing execution and introducing DAS, Celestia can mimic the scalability characteristics of BitTorrent, the most scalable decentralized protocol known on the internet.

IV. Features of the Modular Celestia Stack

Now that we have introduced how Celestia works, let’s look at the benefits of modular blockchains. The significance of reimagining blockchains as a modular stack goes beyond pure DA scalability. Below, we introduce 8 unique design properties of the modular Celestia stack that may not be immediately apparent.

Self-sovereignty

Today, rollups operate as child chains of Ethereum. This is because they publish their headers on Ethereum, and their fraud/validity proofs are executed on-chain. Therefore, their normative state is determined by a series of smart contracts on Ethereum.

It is important to recognize this because it means that rollups must have on-chain governance mechanisms by default. However, on-chain governance carries risks such as low voter participation, vote buying, and centralization. Due to these complexities, on-chain governance has not been adopted as the preferred governance method by most blockchains.

Rollups on Celestia operate quite differently. As we have seen earlier, Celestia does not ascribe any meaning to the data it stores and leaves all interpretation to rollup nodes. Therefore, the normative state of rollups on Celestia is independently determined by nodes that choose to run specific client software. In fact, this is how today’s L1 blockchains generally operate.

Thus, rollups on Celestia are essentially self-sovereign blockchains. By upgrading software and choosing to interpret the underlying data differently, nodes can freely perform hard/soft forks. For example, if the rollup community is engaged in a contentious debate over changes to block size or token supply, the opposition can update their software to follow different validity rules. When we think about the deeper implications of this feature, you will notice that it is more exciting than it appears.

In the realm of L1 blockchains, contentious hard forks are often considered risky because the forked chain ultimately weakens its security. Therefore, people often go to great lengths to avoid forks, stifling experimentation.

In the history of blockchains, Celestia has brought the ability to fork to blockchains for the first time without worrying about security dilution. This is because all forks will ultimately use the same DA layer without sacrificing the security advantages of the Celestia consensus layer. Imagine how smoothly the debates over Bitcoin's block size or the Ethereum DAO fork could have been resolved if blockchains operated this way from the start.

We expect this will accelerate experimentation and innovation in the blockchain space to levels beyond what today’s infrastructure can imagine. The visualization below perfectly illustrates this point.

Flexibility

Another force that will particularly accelerate innovation in the virtual machine space is the nature of Celestia being execution-agnostic.

Unlike Ethereum rollups, rollups on Celestia do not necessarily have to be designed to use EVM-interpretable fraud/validity proofs. This opens up the VM design space on Celestia to a larger developer community and exposes it to fierce competition.

Today, with the emergence of products like Starkware, LLVM, MoveVM, CosmWasm, FuelVM, etc., we have witnessed the rise and attention of alternative virtual machines. Custom virtual machines can innovate in various aspects of execution; supported operations, database structures, transaction formats, programming languages, etc., to achieve optimal performance while addressing specific use cases.

While Celestia itself does not directly scale execution, we expect its execution-agnostic nature to lay the groundwork for a highly competitive VM market seeking high-functionality, scalable execution.

Easy Deployment

If there is one trend in the cryptocurrency space that has not changed over the years, it is how easy blockchain deployment has become.

In the early days, decentralized networks could not launch without PoW hardware; eventually, the introduction of PoS eliminated this bottleneck. Like PoS, mature developer tools like the Cosmos SDK have made it easier to launch new blockchains. However, despite the progress, the overhead of guiding PoS consensus is still far from ideal. Developers must find new sets of validators, ensure they have widely distributed tokens, and manage the complexities of consensus, among other things.

While Polkadot parachains and Ethereum rollups have eliminated this bottleneck, the former still has high deployment costs, and the latter still has high operational costs.

Celestia seems to be the next evolution of this trend. The Celestia team is implementing the ORU specification using a tool called Optimint from the Cosmos SDK. This tool, along with others, addresses the future need for any chain to be deployable without developers having to worry about the overhead of consensus or expensive deployment/operational costs. New chains can be deployed in seconds and allow users to securely interact with them from day one.

Efficient Resource Pricing

Ethereum plans to roll out its sharding plan in phases over the next few years. Accordingly, it will have pure data shards, and rollups can only be used to publish data. As the capacity of the underlying layer increases, this will naturally lead to cheaper rollup fees. However, this does not mean that Ethereum will abandon its stateful execution environment on L1.

Ethereum has a sacred execution power. To run fully validated rollup nodes on Ethereum, one must also be interested in executing Ethereum's L1 state. However, Ethereum already has a massive state, and executing on this state is by no means a cheap task. This enormous state imposes growing technical debt on rollups.

Worse still, the same unit used to limit L1 state size (i.e., L1 Gas) is also used to meter the historical data of rollups. Therefore, whenever there is a surge in activity on L1, all rollup fees will rise accordingly.

In Celestia's modular blockchain stack, active state growth and historical data are completely handled separately as they should be. Celestia's block space only stores historical rollup data that is metered and paid for in bytes, and all state execution is metered through rollups in their own independent units. Since activity is influenced by different fee markets, a surge in activity in one execution environment will not impair the user experience in another execution environment.

Trust-Minimized Bridges

One way to understand the entire L1 vs. L2 debate is to view them as some chains and bridges.

In general, bridges come in two forms: trusted and trust-minimized. Trusted bridges rely on the consensus of the counterpart chain, while trust-minimized bridges can be secured by any single full node.

For blockchains to form trust-minimized bridges, they need two things: (i) the same DA guarantees (ii) a way to interpret each other's fraud/validity proofs.

Since L1s do not satisfy the former condition of shared DA, they cannot form trust-minimized bridges with each other. The best they can do is rely on each other's consensus for communication, which inevitably means a reduction in security.

On the other hand, rollups communicate with Ethereum in a trust-minimized manner. Ethereum can access the data of rollups and execute their fraud/validity proofs on-chain. This is why rollups can have trust-minimized bridges with Ethereum and can be secured by any single rollup node.

Chains with trust-minimized bridges can be viewed as clusters. Celestia lays the groundwork for forming clusters between chains. However, this does not force them to do so. Chains on top of Celestia can operate independently or form trust-minimized bridges in a vast bridging design space.

Contrary to popular belief, fraud and validity proofs do not have to be executed on-chain to be effective. They can also be distributed at the p2p layer (as shown below the Cosmos cluster in the diagram) and executed at the client level.

Minimal Governance

Blockchain governance progresses slowly. Improvement proposals often require years of social coordination to implement. While this is for security reasons, it significantly slows down the pace of active development in the blockchain space.

Modular blockchains provide a superior way for blockchain governance, where the execution layer can act independently and quickly break things, while the consensus layer can remain resilient and robust.

If you look at the history of EIPs, you will find that a large portion of proposals are related to execution functionality and performance. They often involve operational pricing, adding new opcodes, defining token standards, etc.

In a modular blockchain stack, these discussions will only involve participants from the respective execution layer and will not permeate the consensus layer. This, in turn, means that there will be far fewer issues that need to be resolved at the bottom of the stack, and progress will inevitably be slow due to the high threshold for social coordination.

Decentralized Block Validation, Not Production

It is common for decentralization to mean different things to different teams.

Many projects value highly decentralized block production and mimic the ability to decentralize block production in a PoS setting like PoW. Notable examples of this include Algorand's random leader election, Avalanche's secondary sampling voting, and Ethereum's consensus sharding. These design choices assume lower resource requirements for block producers to achieve highly decentralized block production.

While these are valuable technologies, it is difficult to say whether they actually bring about more meaningful decentralization than other technologies.

This is because, due to economies of scale external to the protocol, resource pools, cross-chain MEV, and other factors are important catalysts that tend to centralize block production. Empirically, despite the technology, stake/hash rates ultimately follow a Pareto distribution.

Beyond these, there is a more important point on this topic that is often overlooked. The most important factor in decentralization is block validation, not production.

As long as the behavior of a small group of consensus nodes can be audited by a large number of participants, the blockchain will continue to operate as the trust machine we love.

This is the core argument of Vitalik's recent article on the endgame, where he states, "So what’s the result? Block production is centralized, block validation is trustless and highly decentralized, and censorship is still being blocked."

Similarly, while Celestia has higher resource requirements for block producers, it has lower resource requirements for validators, thus achieving a highly decentralized, censorship-resistant network.

Simplicity

Clearly identifying the scalability bottlenecks of blockchains has helped the Celestia team make the simplest design choices.

While Ethereum ultimately implemented DAS at the end of its sharding roadmap, Celestia prioritized it and explicitly chose not to take the overly complex consensus sharding route.

Similarly, Celestia did not implement a new fancy consensus protocol but chose to use good old Tendermint, which has mature tools and widespread developer/validator support.

We believe that over time, these design choices will make Celestia stand out, and as Celestia enters the market at a time when rollups are increasingly seeking cheap data availability solutions, it will be appreciated more.

V. Future Challenges/Limitations

Celestia is pioneering a brand new blockchain design. While we believe this is a model superior to existing solutions, there are still some unexplored challenges.

The first challenge we foresee relates to determining the appropriate block size. As we discussed in this article, Celestia's block size can be safely increased with the number of data sampling nodes in the network. However, data sampling is not a witch attack-resistant process. Therefore, there is no verifiable way to determine the number of nodes in the network. Additionally, since the nodes participating in sampling cannot receive explicit rewards from the protocol, the assumptions about sampling must rely on implicit incentives. The process of determining and updating the target block size will be constrained by social consensus, which is a new challenge for consensus governance.

Another future challenge relates to the network effects that Celestia will guide. Clearly, a dedicated DA layer without execution has little utility. Therefore, unlike other blockchains, Celestia will rely on other execution chains to kickstart user activity. To this end, one of Celestia's initial use cases will be as an off-chain DA solution for validiums (i.e., Celestiums) on Ethereum. Celestium is the easiest target for launching Celestia's block space.

Another ongoing project is Cevmos; a Cosmos SDK chain with a built-in EVM specifically for rollup settlement. Rollups on top of Cevmos will publish their data to Cevmos, which will then publish it to Celestia. Like today's Ethereum, Cevmos will execute rollup proofs as a settlement layer. The goal of Cevmos is to allow Ethereum rollups to natively launch on Celestia without changing their codebase.

Finally, we foresee limitations related to the utility of Celestia's native token. Like any other chain, Celestia will have a fee market, and its native token will accumulate value from the demand for Celestia's block space. However, since Celestia does not execute state execution (except for a very small amount of state execution related to PoS activities), unlike most chains, its token's utility as a source of liquidity in DeFi and other verticals will be somewhat limited. For example, unlike Ether, which can move freely between rollups and Ethereum in a trust-minimized manner, Celestia's native token must rely on trusted bridges to be ported to other chains.

VI. Conclusion

We believe that modular blockchains represent a paradigm shift in blockchain design and expect their network effects to become increasingly apparent in the coming years. In particular, Celestia's mainnet is expected to launch in 2023.

By decoupling execution from consensus, Celestia not only achieves BitTorrent-like scalability and decentralization but also offers unique advantages, including trust-minimized bridges, sovereign chains, efficient resource pricing, simpler governance, easy chain deployment, and flexible virtual machines.

As the first dedicated DA layer, Celestia does less. By doing less, it achieves more.