Celestia — The Foundation of a Modular Blockchain World

24 min readJan 22, 2022

Unless you’ve been living under a rock lately, you’ve likely read about the evolution from monolithic to modular designs that a number of blockchains are working on. What you may not have heard about is Celestia (formerly known as LazyLedger), the first blockchain designed with a modular architecture in mind. Celestia is one of the most exciting projects in the entire crypto space, and its upcoming mainnet launch could be a landmark in reshaping the construction of blockchains as we know them today.

Celestia is a layer one proof of stake blockchain which provides a pluggable data availability and consensus layer. It orders data and makes it available, but it does not execute transactions. Celestia is optimized as a shared security layer for specialized execution environments such as rollups to live on top of. While Celestia will support all flavors of rollups, it is initially focused on the EVM and Cosmos SDK. Celestia itself is built on the Cosmos SDK and uses Tendermint as its consensus engine. The key team members behind it each have incredibly impressive track records in the space:

Mustafa Al-Bassam — CEO and co-founder
Ismail Khoffi — CTO and co-founder
John Adler — CRO and co-founder
Nick White — COO

Modular vs. Monolithic Blockchain Designs

This topic has been covered in depth by many others (specifically Polynya has a number of great posts), so I’ll keep it brief here. Fundamentally when you break blockchains down to their core components, they do three things:

Execution — This is the computation required to update the chain. Take the current state, add in a bunch of new transactions, and out comes the transition to the new state.
Consensus — This provides security and agreement regarding the transactions and their ordering.
Data Availability — You need to make sure that the transaction data behind the block headers has been published and made available so that anyone can readily compute the state and check state transitions.

Take your pick of major blockchains today, and you have a monolithic approach of doing those three core components all together. Split them up across specialized chains, and you have a modular approach. A modular design is the well-documented approach for Ethereum’s current scaling roadmap, but it’s also what the Celestia team has been working on for several years now. Celestia flips the current model on its heads by decoupling execution from data availability and consensus. Leave the execution to specialized environments like rollups. Those rollups can then turn around, post their arbitrary data to Celestia, and rely on it for data availability and consensus.

Blockspace is one of the most in-demand commodities in the world right now, and legacy blockchains such as Ethereum are at their scaling breaking points. The core of the issue comes down to how monolithic blockchains process transactions. Currently for a consensus node to validate a new block you have to first check the block has consensus (e.g., in Proof of Work coupled with Nakamoto Consensus, is this the valid chain with the most work done?). Nodes must also download and execute all of the transactions to make sure the block is valid in a computationally demanding process. However, doing all of this together does not scale effectively.

Celestia nodes are different — they don’t worry about execution at all. Nodes in Celestia only need to check that the data behind the transactions has been published, and they don’t even have to care if it was correct or not. They simply order transactions and verify that the data being published has been made available which is a far more scalable task.

The Data Availability Problem

To properly analyze Celestia we must first understand the data availability problem blockchains face and why it is so important. The heart of the problem is how nodes can be sure that when a new block has been produced, was all of the data behind that block published to the network? Without the data, users would be unable to detect if there were invalid transactions included in the block.

How Blockchain Nodes Work

The two types of node participants in a blockchain are:

Full Nodes (a.k.a. fully validating nodes) — Full nodes download and verify all transactions. This is resource-intensive, but they are also more secure. In the event of a 51% attack for example, full nodes could be censored but not convinced of invalid transactions because they would recognize them as such.
Light Clients (a.k.a. simplified payment verification or SPV clients) — Light clients are non-fully validating nodes, and as such they are easier to run but less secure. They only verify block headers as opposed to checking all underlying transactions. They assume that the majority of consensus is honest and that the chain favored by the blockchain’s consensus algorithm contains valid blocks. As a result, they are susceptible to 51% attacks resulting in invalid transactions.

This raises an important question — how can we make light clients reject invalid blocks so they don’t have to trust miners? The answer lies in fraud proofs, which are small proofs that a specific transaction is invalid.

Fraud Proofs

Fraud and data availability proofs were formalized in 2018 by Mustafa Al-Bassam alongside his co-authors Vitalik Buterin and Alberto Sonnino. Their paper describe some of the key components to scaling a modular blockchain stack securely. Using these techniques, light clients can rely on full nodes to look for invalid transactions and send them succinct fraud proofs if they detect any. This is also quite easy to do, as the fraud proof essentially just consists of the transaction itself in question, the pre-state root, the post-state root, and the witnesses for that transaction. They can then send this to the light clients who can easily recompute that specific transaction and detect that it is invalid without needing to know the state of the entire blockchain.

Data Availability Sampling (DAS)

This is where the data availability problem comes into play. In order for the full node to generate the fraud proof, all of the underlying data needs to have been published. If the data is not available, then nobody would be able to recompute the state or prove malicious activity. So, then what we really need is a way for light clients to check that the miner has published the transaction data to the chain while they are checking the headers. As long as this is being published and is available to the full nodes, then they will be able to generate fraud proofs. Enter data availability proofs.

The crux of DAS is that users (light clients) can split up a block into chunks using erasure coding, randomly sample only a small subset of that data, and in the process verify with statistical certainty that the entire block has been published.

To make it a bit more concrete, just how easy will it be to run this light node? Well this should answer that:

Security Assumptions

Using DAS allows light clients to verify that all of the data in a block actually is available to be downloaded, and therefore fully validating nodes will be able to generate fraud proofs in the event of any invalid transactions. Combining these techniques, we are able to rely on far weaker security assumptions. Let’s recap the three scenarios now:

Full Nodes — Still the most secure scenario, full nodes can’t be tricked into accepting invalid blocks.
Standard Light Clients — Because they do not validate the blocks, they assume the majority consensus is honest.
Light Clients + Fraud Proofs — We can now replace the honest majority assumption for state validity with a much weaker honest minority assumption. You now just need a minimum number of light clients making enough sample requests such that together they can reconstruct the entire block.

The combination of fraud proofs and probabilistic data sampling are central in enabling on-chain blockchain scaling (e.g. via sharding or block size increases) while maintaining a strong assurance of data availability and validity. Celestia’s roadmap contrasts with Ethereum’s in a key way here:

Celestia will be launching with DAS and no plans for sharding
Ethereum’s roadmap implements sharding well ahead of DAS

Ethereum plans to implement sharding using random sampling (randomly shuffling around the validator list across verifying different blocks), but it does not have DAS until years down the road. As Vitalik himself notes, “sharding through random sampling has weaker trust properties than the forms of sharding that we are building towards in the Ethereum ecosystem, but it uses simpler technology.” The fact that Ethereum’s current roadmap has sharding coming long before its implementation of DAS is in fact one subtle but important point, as sharding without DAS is less secure.

Blockchain Scaling & Celestia’s Approach

Blockchains generally have a finite capacity based on the resource requirements of an end user full node. Bitcoin for example has a theoretical maximum size of 4 megabytes which is set incredibly low so that any regular user can spin up a node on regular hardware and validate the chain. Ethereum has a similar goal in mind for regular users to validate the chain, though slightly higher resource requirements than Bitcoin. This ability for anyone to check the chain themselves is critical for the notion of self-sovereignty, that you don’t have to trust any third party in validating the network. For a set of given hardware requirements and costs to run a full node, that essentially constrains the TPS of the network.

The notable exception can be seen in Solana’s approach — the prime example of a monolithic chain looking to scale without modularizing. Solana’s scaling largely boils down to leveraging Moore’s law in a bet that hardware costs will continue to fall and the network will continue to increase its hardware requirements, thus boosting the throughput. The upshot of this is that Solana should always have more capacity than demand, and a fee market won’t need to emerge for blockspace. Transaction costs can therefore be kept incredibly low, just high enough to prevent spam attacks.

The Celestia roadmap is very well aligned with the ideology that regular users on minimal hardware should be able to validate the chain themselves, and so they also intend to scale by making that validation easier (not by increasing the hardware assumptions). As such it does not guarantee that capacity will always outstrip demand. There will be constraints, and a fee market will emerge. What Celestia does deliver on is massively more capacity than other contemporary blockchain designs which will in turn lead to incredible scalability and lower fees. It can do this because of its design which makes it computationally easy to validate the chain (not having to worry about execution).

Celestia’s key to scaling is in the fact that it requires sub-linear work to validate the chain with respect to block size. More concretely, clients only need to download the square root of the amount of data they are checking. For example, let’s say you’re doing DAS on a block with 10,000 chunks. You would only need to download and check 100 of them. You’ve now gone from a model where a node needs to download and execute every transaction in a block to a model where you only need to download and check the availability of the square root amount of the data in the block.

Making this validation so easy is the key to scaling because the number of chunks you need to sample is irrespective of block size, so it’s a roughly constant cost to check the block regardless of the block size. This allows you to increase the size of the block (or shard) and therefore TPS without increasing cost to the end user to validate the chain. However, the bigger the blocks get, the more users you need in the network to be downloading random samples to be sure that users have collectively sampled everything in the block. The limitation on securely hosting more data is therefore just having more nodes. You’ve now created a blockchain that scales linearly with the number of users (light nodes) on it, and you’ve made it incredibly easy to do this. As more nodes join the network, you can safely increase block size without sacrificing security or decentralization. Increasing block size on legacy blockchains increases the hardware requirements to validate, in turn sacrificing decentralization and security. Rollups sitting on top of Celestia rely on it for data availability, so by increasing the data availability at the base layer this then translates to increased scaling in their own execution environments. This is how Celestia delivers massive scalability.

In fact, we’ve already seen ideas analogous to this in practice. BitTorrent is the communication protocol for peer-to-peer file sharing which enables users to distribute data and electronic files over the Internet. It has been one of the world’s most scalable decentralized protocols, even at one time handling over a quarter of the entire traffic of the internet. The reason it is so scalable is much the same reason that Celestia’s design is so scalable. P2P users don’t have to execute anything, they just share storage and distribution with each participant only contributing and storing a small part of the network. The more users in the network, the more data it can store and distribute, scaling directly with its user base. Celestia takes this key insight of simplifying a network to data availability and applies it to blockchain to achieve similar scalability.

Rollups

Now that we have a method of creating a secure base layer capable of securely providing data availability, we have a viable home for rollups to live on top of. Rollups are blockchains themselves with their own block producers that optimize as execution environments. They can then rely on a base layer such as Celestia to provide data availability where they can dump their transactions. Let’s take a quick look at the two major flavors of rollups and why they require data availability and consensus:

Optimistic Rollups — Optimistic rollup aggregators or sequencers first collect transactions into a rollup block. In the case of an Ethereum rollup, the aggregators will then send that block back to a smart contract on the base layer while also posting a bond. These rollups are optimistic in the sense that their blocks are initially assumed to be valid (innocent until proven guilty). The aforementioned fraud proofs can be leveraged to show otherwise in the case of invalid transactions. After the blocks are posted, there is a challenge period where anyone can submit a fraud proof challenging the blocks. In the event of a successful fraud proof challenge, the aggregator’s bond will be slashed and the blocks will be rolled back. If the period ends without a challenge, the blocks are finalized. As discussed, data availability is required to submit these fraud proofs. In Celestia (which does not have on-chain execution), fraud proofs would instead be distributed via a peer-to-peer network instead of having to be published to a smart contract on the base layer.
Zero-knowledge (ZK) Rollups — ZK rollups work the other way around, requiring a cryptographic proof upfront known as a validity proof to show that the block being posted is valid (guilty until proven innocent). While validity proofs themselves do not require data availability, it is still required for the security of the chain. If the ZK rollup block producers were to create blocks without posting the data, users would be unable to recreate the state. For example, imagine a scenario where block producers for a ZK rollup on top of Ethereum start censoring transactions. If the data is available on the main chain, users on the rollup can recreate the state, prove their account balances, and force an exit from the rollup to the main chain. Alternatively, other sequencers could also just step in to recreate the state and start producing blocks. If they are unable to do this because the data is unavailable, they will be frozen.

So, What Would a Rollup on Top of Celestia Look Like Exactly?

There are currently two main ways that Celestia is looking to provide a base for rollups:

“Celestia-native Rollups” — These rely solely on Celestia for data availability and consensus. This is the original vision of building out an ecosystem of rollups on top of Celestia with client-side execution. In the longer term, this is still the primary goal and likely more scalable.
“Ethereum-native Rollups” — These are rollups (or more accurately for now “Volitions” in this context, we’ll cover that shortly) which currently settle to the Ethereum main chain, but also rely on off-chain data solution options. Data availability is still incredibly expensive on Ethereum, so a hybrid solution of rollups leveraging both Ethereum and Celestia makes a lot of sense in the short and medium-term.

Celestia-native Rollups

Celestia’s primary vision is quite simple at a high level — provide a pluggable data availability and consensus layer for rollups to operate on top of. The main difference between how rollups would operate on Celestia versus Ethereum comes down to the fact that Celestia has no execution environment. Let’s take a look at how this impacts ZK rollups for example:

Ethereum Model — ZK rollups post their data and validity proofs to Ethereum, and a smart contract on Ethereum would validate the proofs (i.e., Ethereum serves as the settlement layer).
Celestia Model — ZK rollups post their data and validity proofs to Celestia, but the proofs would then need to be verified locally by the rollup’s execution environment because there is no execution environment enshrined in Celestia to do this (i.e., Celestia does not handle settlement).

In Celestia’s case there isn’t any kind of two-way bridge between the base layer and rollup. You don’t have a client of both chains running as Celestia is essentially agnostic to all these rollups, and doesn’t comprehend what the data from these rollups mean. In the case of Celestia-native rollups, the rollup sequencer would likely be running a client of the Celestia main chain. It would follow the blocks, submit a transaction to Celestia with the rollup’s data, and pay for the inclusion of that data.

Ethereum-native Rollups

While a hybrid solution working alongside Ethereum wasn’t the initial plan, a clear product market fit has developed here. As a result, Celestia has been discussing an alternative solution with different Ethereum ZK rollups. Let’s first quickly look at the current data availability bottleneck on Ethereum. At a high level, the Ethereum main chain remains challenged to scale and fees will increase meaningfully even when using rollups on top of it. This is because Ethereum is still far from optimized as a data availability layer with sharding and DAS years down the line. As a result, other off-chain data availability solutions are arising. Below is an overview of the current rollup lay of the land on Ethereum:

Celestia becomes quite interesting in the case of Volitions. As pioneered by StarkWare, Volitions refer to a system where users have the option of operating in either:

ZK-rollup Mode — Inherit the full security of Ethereum, relying on it for both settlement and data availability.
Validium Mode — A weaker security model where Ethereum is still the base settlement layer, but data availability is put off-chain.

Volitions offer a great degree of freedom to users, allowing them to choose their tradeoff between higher security (rollups) and lower costs (Validiums) on an individual transaction basis while maintaining full composability as both modes share the same state. StarkNet will be providing its Validium solution, and zkSync 2.0 will be launching its analogous zkPorter solution to operate in a similar mode as they continue along their launch roadmaps this year. The current versions of Validiums such as StarkWare’s permissioned scaling engine StarkEx rely on closed committees of well-known trusted parties (such as ConsenSys and Nethermind) to attest to the data availability off-chain. This type of permissioned scenario is of course far from ideal, as all users on that Validium are then at the mercy of these centralized committees who could freeze the state and withhold the data. Going forward StarkWare and Matter Labs will be launching their permissionless rollups (StarkNet and zkSync 2.0 respectively). zkSync will also include zkPorter (its Validium solution) which will move to host its data availability off-chain as well, secured using proof of stake secured by zkSync token stakers termed Guardians as follows:

These Validiums can still provide higher security than sidechains or alternative layer one blockchains if their data availability committee is secure. In the worst case of a malicious actor controlling the sequencer and over 2/3 of the total stake, the worst they can do is sign a valid state transition but withhold the data, effectively freezing the state. Full rollup mode users are protected from such an attack because their data is available on the Ethereum main chain, and as such they can always recreate the state to prove their account balances for example and force an exit to layer one Ethereum.

This is where Celestia comes in. If Ethereum’s main chain data availability option is cost prohibitive, then ZK rollups are currently left with the option of either a permissioned setup for data availability (such as in StarkEx now) or needing to bootstrap a new secure committee of validators (zkPorter’s approach). Rather than going through this process and fragmenting security across various ZK rollups, Validiums can instead opt to plug into Celestia for off-chain data availability while still leveraging Ethereum for settlement.

In practice, the Celestia validator set could post signatures to Ethereum attesting to the fact that the data for a given Ethereum-native Validium has in fact been made available on Celestia. Celestia blocks are organized using what are called Namespaced Merkle trees (will describe this is further detail later), allowing for the data specific to the given Validium to be attested to on an Ethereum smart contract. Then rollup clients can read these attestations on Ethereum, and know that the data is available for them to recompute the state.

In this hybrid scenario, Celestia will continue to undercut Ethereum on data availability costs and scalability because of their different structures. On Ethereum, posting data will continue to compete against the state execution of huge amounts of smart contracts. Ethereum’s innovations to make itself a well-suited data availability layer (data sharding followed by DAS eventually) are still a long way off. There will be some added cost for Celestia to be posting this attestation to Ethereum, but this can be optimized in ways such as possibly batching attestations for different rollups. More importantly, you’re just posting signatures and Merkle roots from Celestia to Ethereum, which is far cheaper than posting the full transaction data to Ethereum.

As a note, the reason Celestia can only be used in the case of Ethereum-native Validiums and not actual rollups at this time is because Ethereum doesn’t currently support off-chain data availability proofs. However, the previously mentioned scenario of the rollup clients just verifying signatures of Celestia attesting to the data availability does fit within their threat model. For you to have the security assumptions of a rollup, you want to inherit the full security assumptions of the base layer (i.e., having Ethereum actually verifying the data availability by supporting the off-chain data availability proofs) as opposed to relying on the attestation of an off-chain committee.

As a result, in this Validium example relying on both Ethereum and Celestia, it should be noted that this does indeed bring additional security assumptions compared to a full rollup mode. However, it should still be more secure than either a rollup entirely reliant on a less secure layer one or a situation where many Validiums rely on their own weaker data availability committees (and cheaper and more scalable than a rollup relying on Ethereum alone).

A Full Modular Stack — Utilizing Cevmos & Recursive Rollups

Celestia is currently working alongside the Evmos team to build out Cevmos (Celestia/EVMos/CosmOS), an incredibly exciting full modular stack built for hosting EVM-based rollups.

For background, Evmos is an application-agnostic chain that will be interoperable with Ethereum mainnet, EVM-compatible environments, and other BFT chains via IBC. Evmos aims to be the EVM Hub of Cosmos, making it easy to deploy smart contracts and communicate within the Cosmos ecosystem.

As you will recall from earlier in the case of sovereign Celestia-native rollups, those rollups were responsible for local verification of fraud and validity proofs (i.e., serving as their own settlement layer). In this new stack, Cevmos would serve as an optimized settlement layer built on the Cosmos SDK running a restricted EVM. It will be based on Evmos and built to host EVM recursive rollups (a rollup within a rollup) on top of it. This settlement layer will itself be a rollup, so we can therefore call it a “settlement rollup.” The Cevmos settlement rollup will be built using Optimint (Optimistic Tendermint) instead of the Tendermint Core consensus engine used on existing Cosmos chains. Optimint is a replacement for Tendermint BFT that enables developers to deploy new chains using an existing consensus and data availability layer such as Celestia.

At its core, any settlement layer built for rollups is a chain that has a trust-minimized two-way bridge with rollups, using some sort of dispute resolution contract on the settlement layer. This allows tokens to be transferred between the two, or from one rollup to another routed through the settlement layer, in either direction in a trust-minimized way.

The issue at present is that the Ethereum main chain is not optimized only for rollup settlement, and so rollups must always compete with other applications which becomes expensive and is not scalable. The Cevmos settlement rollup will instead be far more restricted, allowing only for:

Rollup smart contracts — it must handle the verification of validity proofs and the disputes necessary to host ZK and optimistic rollups on top of it
Simple transfers between rollups

Because the Cevmos settlement rollup will be fully EVM-equivalent, you will be able to easily port over and run your favorite EVM rollups (Fuel, Optimism, Arbitrum, StarkNet, etc.) on top of it.

To recap, the full Cevmos stack could consist of:

Celestia — at the bottom providing data availability.
Cevmos Settlement Rollup — This Evmos-based chain will sit on top of Celestia. It will be optimized solely as a settlement layer for EVM-based rollups to sit on top of.
EVM-based Rollups — Handling execution, a potentially huge number of execution rollups will sit atop the stack.

For a nice comparison to the alternatives:

Quantum Gravity Bridge

Aside from just having a really cool name, the Quantum Gravity Bridge is one of the more interesting developments underway in Celestia. The bridge will be a relay from Celestia to an EVM-compatible chain (e.g., Ethereum, Avalanche, BSC, etc.). This will allow you to relay those attestations that data is available on Celestia to that EVM-compatible chain. This would be used in the case of those Volitions built on an EVM-compatible chain, but isn’t quite ready yet to jump over to fully deploy its code on Cevmos. However, you can still benefit from Celestia’s scalable data availability in that hybrid system which would look like:

Celestia for data availability through the relay
EVM-chain for settlement (alternative to the Cevmos settlement rollup)
EVM-native rollup for execution

The bridge would relay the attestation to the EVM-compatible chain that the data has in fact been made available on Celestia, then you can continue to use the EVM-compatible chain for settlement.

Execution Environments for Celestia Rollups

Though Celestia itself is built on the Cosmos SDK, the beauty here is that rollups built atop it maintain the ability to choose whatever execution environment they want. In fact, it’s actually currently quite difficult to use the Cosmos SDK for rollups because it’s difficult to make them state fraud provable. This is due to the fact that the Cosmos SDK is not a very specific or well-defined execution environment like the EVM. Because of this, a single transaction could touch all of the state making it difficult to provide a fraud proof for a given transaction to a light client to check. (You’ll have noticed an exception before in the case of the Cevmos settlement rollup, though this should work because of its more restrictive and constrained environment).

As a result, Celestia is actually looking at other environments aside from the Cosmos SDK as a kind of default execution environment. One that is being looked into is Arbitrum’s VM, which is a more constrained and clearly defined execution environment. It uses an interactive verification game as opposed to general state fraud proofs. In the short-term, this would likely be a more feasible solution to implement than making the Cosmos SDK easily fraud provable. That is still an end goal, but the plan is likely to start with the most readily available options now and continue to add new execution environments over time. To onboard new execution environments over time, they would need two main things:

Current execution environments are usually coupled with consensus, so you would need to decouple them and replace the consensus part with the ability to just dump the data on Celestia instead.
Ability for validity proofs or some sort of state fraud proofs (the options here are those two mentioned earlier — interactive verification games or general state fraud proofs).

Sovereignty of Rollups on Celestia

One of the key visions of a modular stack is to offer more flexibility to developers to optimize for the things they want and application users to have say in outcomes. Celestia provides the perfectly neutral and flexible base layer for this vision. If you’re running a rollup on top of a world computer model today such as Ethereum, you’ll be deploying a smart contract bridge on the base chain. As a result, you will be following the rules of that layer one. The logic and consensus of this rollup can’t easily be upgraded without an on-chain vote, so there’s no option to fork.

In the case of a rollup on Celestia, you can have a native bridge where the logic to do a fraud or ZK proof is done natively, and this code is what adjudicates. This can be upgraded without affecting the data availability layer. This is why Celestia rollups have greater sovereignty — they have the ability to hard fork easily without requiring permission. This is also the advantage of a system like Cosmos (which is not a world computer model), where individual zones can rely on their own governance to hard fork without hard forking every other zone simultaneously. The problem here is that zones are a bit too separated in the sense that they fragment security. Now what if you could offer that sovereignty to zones, but with the shared security of Celestia as the common base layer while all interacting via IBC?

There’s inherently a social consensus underpinning these systems, and Celestia hands the power back to the chains which deploy on top of it. Say you were to have a situation such as the DAO hack again, where the decision to hard fork had to be made by the entire Ethereum base chain. Now you can envision a world of app-specific rollups on top of Celestia which in a similar scenario would have the freedom to do as they wish if they suffered a hack without hard forking any of the other rollups.

How Celestia is Organized Using Application Namespaces

When applications deploy on Celestia, they will be able to choose their own “namespace” which all of their messages will then be associated with. Celestia then organizes its blocks using a Merkle tree ordered by the namespaces of each transaction. This allows users in the network to easily query Celestia’s full storage nodes to ask for transactions relating to their application, not needing to care for the data related to other applications. This counters existing blockchains’ where every smart contract is running on the same world computer with consensus and execution coupled. In that scenario, smart contract users do need to take an interest in and check the transactions of every other smart contract.

Token

Celestia will indeed have a token, though details are very limited at this time. It will be used to secure the network using proof of stake and pay for transaction fees on the network. A fee-burn mechanism similar to EIP-1559 is planned as well, creating deflationary pressure to counteract new issuance as adoption grows.

Timeline

Celestia launched its minimum viable product (MVP) and private devnet in 2021. The next step will be launching a testnet early in 2022 (there are plans for an incentivized testnet), followed by mainnet launch later in 2022.

Concluding Thoughts

To wrap things up, Celestia offers multiple advantages over traditional solutions:

Scalability — By decoupling execution from consensus and data availability, Celestia is able to specialize and scale linearly with the number of nodes on the network. Execution environments are then free to optimize on top.
Simplicity — Celestia refers to itself as a pluggable solution, hoping to make it as easy to deploy an app-specific blockchain as clicking a button. The long tail of a potentially infinite number of blockchains will have a natural home on top of Celestia.
Shared Security — No more need to bootstrap your own security and validator set as an individual chain. Whether this is for what would be an otherwise stand-alone chain, or a Validium that would need to bootstrap a data availability committee, those options are far more difficult and fragment security.
Sovereignty — The beauty of the simplicity of Celestia’s design is that it offers so much freedom to those applications built atop it. No more being tightly bound by the execution environments and governance decisions of the chain you sit on top of.

The Celestia team were far ahead of their time in thinking about data availability and a modular blockchain stack. Others such as Polygon Avail or other current layer one blockchains looking to modularize are just now realizing the inevitability of this paradigm shift. This is increasingly the direction that blockchains are moving to scale, and Celestia is set to provide a best-in-class solution.