The Celestia Thesis
An article on light client security and modular blockchain technology
Preface
This is going to be an article on arguably one of the most fascinating new projects emerging in the blockchain space. Celestia is bringing new concepts and ideas into the industry and endeavouring to be a pioneer in a world of copycats. Celestia at this point doesn't have a token, so no “wen token?” in the comments, but rather, try to enjoy the technical aspects and the ideas.
Intro
To give a basic understanding of the concepts we'll be exploring in this article, this part will serve as an appetizer to the ideas that I will be talking about throughout this piece.
Separation
In a normal blockchain both the consensus layer and the execution layer are on the same layer and are both enforced by the same set of validators. What Celestia does instead is to decouple the consensus and the execution layer, and enable the users to deploy their own execution layers on top of the Celestia consensus and data availability layer. The execution layers will exist as their own blockchains (think L2's) where they can decide what to specialize and optimize for.
Something rather interesting is that something similar to this was actually proposed by the great Vitalik himself, in the form of Plasma. The original Plasma paper described a mechanism for constructing a “tree of blockchains”1. Each node in the tree would represent a unique blockchain that was connected to its parent, and all of these blockchains were arranged in a hierarchy of chains, with the data availability layers at the heart of it.
Rollups
Rollups are scaling solutions that force the execution off-chain and instead rely on a base chain layer for consensus and data availability. Although the majority of transactions still occur on Ethereum, these will eventually move off-chain once Ethereum fully integrates their PoS and various L2 solutions.
Two obvious examples are optimistic and zero-knowledge (zk) rollups, optimistic rollups require data availability (DA) to be able to detect fraud and zk-rollups require DA to be able to recreate the chain. This proves that DA layers (consensus) are needed for rollups since the rollups are the execution layer.
Optimint
Replacement for Tendermint that allows developers to build Cosmos-based chains as rollups that can use other chains such as Celestia as a consensus and data availability layer. In the future, it would be possible for rollup-based Cosmos chains to form a cluster of chains with each other using the IBC protocol, providing incredible levels of interoperability.
Data Availability Sampling Light Client
Unlike most other blockchains, Celestia is designed strictly to provide consensus and data availability, not transaction execution. Likewise, Celestia light clients do not verify transactions, they only check that each block has consensus and that the block data is available to the network.
The idea for this is actually from the original Bitcoin Whitepaper - In the paper, Satoshi mentions that light clients could be made more secure if full nodes sent them “alerts” when an invalid block was published.
“One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency" - Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System. 2
Celestia's light clients depend on security in numbers. There must be a minimum number of light clients to guarantee that the original block data is recoverable from all the samples they take each. As the number of light clients grows, so can the size of each block also increase without compromising on the security or decentralization of the network itself. Larger blocks mean more data throughput and more scaling - so the network's ability grows by adoption, quite the opposite from current blockchains.
Data sampling light clients are a key component for all rollup-based sidechains built on top of Celestia, because rollups rely on data availability for their security, as laid out in the intro.
Cross-chain interoperability relies on light clients which are typically not secure because they make an honest majority assumption. However, with Celestia, light clients do not need this assumption, which unlocks secure cross-chain interoperability.
Instead of downloading the entire block, Celestia light nodes just download small random samples of data from the block. If all the samples are available, then this serves as proof that the entire block is available. Basically, by sampling random data from a block, you can probabilistically verify that the block is indeed complete.
Clusters
In real-world terms a cluster is a group of similar things that are closely tied together, think of star clusters, galaxy clusters etc.
In the world of blockchains, a set of chains can communicate with each other in a cluster. A cluster could for instance be a set of rollups connected to a parent chain (as is the case with Ethereum rollups), or standalone layer 1 chains such as Polygon (yes, Polygon is an L1) or Solana. These clusters can then communicate with one another and provide intra-cluster communication3.
Every chain in the cluster can validate the state machine (storing the status of the blockchain) of other chains in the cluster. For example, all Ethereum rollups are EVM-compatible, so it is possible to validate the fraud or ZK proofs of rollups within the EVM. However, it is not practically viable to validate the Solana state machine within the EVM, so Solana cannot share a cluster with Ethereum (A brilliant example here would be the recent Wormhole hack). Inter-cluster bridges come with serious security trade-offs - you have to trust that a set of validators won't steal your funds.
Celestia solves this problem by providing a consensus and data availability layer for blockchains, including rollups. It's a blockchain where consensus and execution are decoupled as it doesn't provide an on-chain smart contract environment such as Ethereum, only consensus and data availability. The Celestia ecosystem is not a cluster itself as it doesn't enforce any specific cross-chain communication mechanism between Celestia-based chains, but it provides the core ingredient for building clusters.
Celestia provides the data availability layer, while others can build their execution layers and smart contract layers on top of Celestia. All chains in the cluster need to check that the blocks of each other were included in the Celestia data availability chain, and are thus able to verify the data with minimal amounts of trust.
Think of it this way - blockchain infrastructure have evolved from individual execution chains (L1) to shared execution chains (L2's) and finally individual execution chains on a shared consensus layer (Celestia)
Let us quickly sum up some of the main parts of Celestia, before we move on to the main benefits of using modular blockchains instead of monolithic ones.
The base layer (DA layer) only guarantees the availability of messages (no execution)
Transactions are executed by applications built on top (scalable)
Node growth causes more throughput since DA sampling is sublinear
Modular blockchains are the result of separating the core components of a single blockchain and running them on separate layers
Celestia, will when released serve as a data availability layer for both optimistic and ZK-rollups. There will be no restrictions on the type of rollup that can utilize Celestia for scalable data availability and security.
Benefits of modular blockchains
As stated earlier, Celestia has a modular blockchain architecture, so what are the benefits of this vs. non-modular chains?
Scalability
Layers that specialize in a pair of core features will allow for much greater scalability without the limitation of making tradeoffs that come with a monolithic blockchain. For instance, a modular data availability (DA) layer with DA sampling can scale linearly with the number of users.
Interoperability
Blockchains can employ a modular shared security layer, such as Celestia, to enable trust-minimized bridging between blockchains in the same cluster. This improves both the security and the level at which several blockchains can communicate with each other.
Bootstrapping
New blockchains can be created with minimal cost and time. Rollup Software Development Kits, such as Optimint, will not only aid this but deliver a way to bootstrap without needing a consensus mechanism, validators, or token distribution mechanisms.
Experimentation
Blockchains can easily be created and used to test new innovative technologies that bring further scalability and optimizations to the entire stack of chains. Doing this allows new chains to focus directly on the elements they want to innovate on, which can then be spread to the rest of the chains.
Think of it this way versus monolithic blockchains, let's take an example of two restaurants running in two completely different ways (shoutout to Celestia's Twitter)
Modular: Each employee is given a specific role, like a waiter, so that they can specialize in a specific task. They then split up duties and cooperate, allowing the restaurant to produce more food at a higher quality.
Monolithic: has a single person working as the waiter, cook, and cleaner simultaneously. It works when the restaurant only has a few customers, but beyond that, the restaurant will struggle.
This should hopefully make it obvious as to why modular blockchains are much better for scalability4.
You can also practically explain Celestia in the form of a Dyson Sphere, in which the execution layer (Sphere) surrounds the data availability layer (Star), the same way the Dyson Sphere would encase a star - utilizing the power underneath.
Just like a Dyson Sphere would capture a large percentage of a star's power output, so would the execution layers make use of the Celestia data availability layer underneath it.
Now let's try to explain the concept of modular vs monolithic in more traditional terms with examples from the real world. To do this we can explain it in the traditional form of monolithic- vs microservice-architecture, let's take a look:
Microservices (modular) are in general seeing an increase in usage, especially by newer tech giants, that you might be familiar with within your daily life.
Microservices architecture allows major applications to divide into small, loosely coupled services.
Over time growth becomes very difficult in monolithic architecture as it becomes oversized and increasingly complex.
Microservices allows you to use and see your application in terms of small, loosely coupled components, anyone can get started with the existing application in a short span of time and, it wouldn’t be too difficult to add new components or change existing ones within the structure.
The Holy Trinity
Building an optimal settlement layer for EVM rollups with Celestia, Evmos and Cosmos
Presently, most rollups use the Ethereum main chain for settlement. However, the Ethereum chain is not a perfect settlement layer for rollups, since it is shared with non-rollup apps that use the chain directly for smart contract transactions.
So what do we do if we want the Celestia cluster of blockchains to communicate with other chains?
Celestia desires to create an inter-cluster bridging technology, that will enable the clusters to communicate with other non-rollup chains.
Inter-cluster bridging
Let's assume if a roll-up within the ecosystem of Celestia/Evmos/Cosmos cluster wants to communicate with another non-rollup chain (let's consider any other IBC network), or a rollup that uses a different settlement layer, a committee-based bridging service would be required, as a trust-minimized bridge wouldn’t be possible.5
In this case, we would be able to use a third party chain to operate a committee-based bridge (such as Ethereum or Solana). In the circumstance that the EVM of a settlement rollup is too restricted for bridge contracts, the bridge could be with a rollup (such as Arbitrum or ZKSync) on the settlement layer - rather than the consensus layer itself.
So how can we possibly achieve this? There are currently two possible ways:
A Cosmos chain could act as an “intercluster rollup hub”, where the validators of the chain could operate the bridge by following the conditions of the settlement rollup (L2's) and authorising assets on the settlement rollup to be transferred to the zone via a multi-sig or similar contract, possibly using the Evmos chain (This is one of the reasons why Evmos is so incredibly exciting for the Cosmos ecosystem as a whole)
Rely on an existing “interchain communication as a service”, such as Axelar (decentralized state machine responsible for facilitating cross-chain requests) in the Cosmos ecosystem.
The Future
Will we ever get a token from Celestia, possibly? However, there doesn't necessarily have to be one, as put in the original white paper
"There does not need to be a native currency to the system, as consensus nodes can choose to accept transaction fees in any currency application that they choose to recognise."6
Which could mean that any IBC enabled chain's native token, or others could be used to pay for transaction fees. However, it is highly likely that there is going to be a token to incentivize securing the network as a validator.
If larger block sizes are required in the future, a message too big for a single block could be chunked into multiple messages and then parsed back into a single one by the light clients.
So what are the advantages of Celestia compared to concurrent chains? Let's look at four ways Celestia is pioneering in the blockchain space.
Deploy a blockchain easily, as Celestia provides consensus and security
Scalability with DA sampling, since Celestia doesn't validate txs. Its throughput scales automatically with its number of users
Interoperability with all chains built on top of Celestia
Various execution chains, whether that would be EVM or Cosmos SDK rollups
In short to conclude, what Celestia tries to solve is by reducing block verification to data availability verification, blocks can be verified in sub-linear time (allowing for better scalability). Furthermore, using the concept of application state sovereignty, multiple sovereign applications(chains) can use the same chain for data availability, with only a limited impact on the workload of each other’s users.
If you enjoyed this article, please do follow me on Twitter at @0xRainandCoffee
https://www.plasma.io/plasma.pdf
https://bitcoin.org/bitcoin.pdf
https://blog.celestia.org/clusters/
https://celestia.org/resources/
https://forum.celestia.org/t/an-open-modular-stack-for-evm-based-applications-using-celestia-evmos-and-cosmos/89
https://arxiv.org/abs/1905.09274
Great piece my friend!