Maven11 Research: Why the Definition, Evolution and Future of Modularity Matter to the Crypto World

foreword

Back in 2019, when we invested in LazyLedger (now called Celestia), the word modularity hadn't caught on in terms of blockchain design. And in the past year, it has been popularized by many KOLs as well as L2 teams, and of course the Celestia Labs team, who coined the term in their first blog post about separating consensus and enforcement.

As such, we are pleased to present an updated overview of our investment in Celestia. It will provide insights into the modular world we envision, the various layers and protocols within such an ecosystem, and why we are so excited about the potential capabilities it offers.

architecture

At present, most public chains are monolithic chains, that is, the blockchain network simultaneously covers the three functional layers of data availability, settlement and execution (hereinafter referred to as the functional layer). Although these monolithic chains have also evolved, such as Ethereum Rollups and Avalanche's subnetworks with modular components. However, these are not really what a modular blockchain is.

Let's define what we mean by "modularity" so there are no misunderstandings. When we talk about modularization, we mean that the functional layers of the blockchain network are decoupled, that is, one of the three functional layers of the blockchain network is decoupled, so either the execution layer or the The consensus layer, or the data availability layer. This means that you can say that Rollups are a manifestation of modularity, since they are only responsible for execution. But Ethereum as a whole handles everything else.

Taking Celestia as an example, we can say that it is modular because it is only responsible for data availability and consensus. Instead, it delegates settlement and execution to other layers. These layers are also modular in that they only handle part of the three major functional components themselves. This means that we cannot call Ethereum a modular blockchain, because these Rollups networks are only responsible for the transaction execution of their own network, and Ethereum itself also executes transactions, which means that in its current implementation, Ethereum is still A monolithic chain. Despite this, Ethereum is still the ideal settlement layer, as well as the most decentralized and secure public chain.

Now, what about Polkadot and Avalanche, you might ask? For Avalanche, it is not modular, each subnet has three major functional components. This means that they cannot be extended modularly, but by using other monolithic chains horizontally. Polkadot's parchains are responsible for execution, similar to rollup, while sending blocks to the relay chain for consensus and data availability. However, the relay chain still guarantees the validity of transactions.

Over time, the growth of a monolithic chain can lead to massive congestion and inefficiencies. If we want to carry more people, it is completely unfeasible to rely solely on the monolithic chain that takes care of these three functions. Because it imposes extremely high costs and delays on the end user. This is why we see more and more chains deciding to split their chains. We've all heard about the fabled merger that will transition Ethereum to a PoS chain. However, they also plan to eventually move to sharding. Sharding refers to the horizontal splitting of the blockchain into several parts. These shards only handle data availability.

Sharding and rollup are how the Ethereum community plans to solve its scalability problems. Is there any other way? Of course, we also see Avalanche moving towards modularity in Subnets, but, as explained earlier, we wouldn't classify it as fully modular.

To better understand how each of the different "modular" architectures work, let's try to draw them out to better outline their differences.

Architecture comparison

First, let's take a look at the current architecture of Ethereum and what the architecture will look like after sharding is enabled in the future.

Currently, Ethereum is responsible for all functional layers, but it also separates some transaction execution to L2 Rollups, which process transactions in batches and then settle them on the main network. After sharding is enabled in the future, the architecture of Ethereum will look like this:

This will turn Ethereum into a unified settlement layer, and shards will be responsible for data availability. This means, shards will just be DA environments for Rollups to submit data to. On shards, validators only need to store data for the shard they are validating, not the entire network. Sharding will eventually let you run Ethereum on lightweight nodes, similar to Celestia.

For Avalanche, their main scaling proposition is through subnets that can be easily created. Avalanche's architecture looks a bit like this:

A subnet has a new set of validators that independently validate its own network. All Avalanche subnetworks are responsible for consensus, data availability, and execution on their own. Each subnet will also have its own Gas token, designated by validators. An example of a subnet that is currently live is the DefiKingdoms subnet, which uses JEWEL as its Gas token.

Before we move on to Celestia's architecture, let's take a look at Cosmos. Celestia borrows heavily from Cosmos and will interact with it a lot through IBC, as it is also built with the Cosmos SDK and Optimint, a version of Tendermint. The Cosmos architecture is very different from other current architectures because it enables dApps to be applications of the blockchain itself, rather than providing a virtual machine. This means that a sovereign Cosmos SDK chain only needs to define the transaction types and state traditions it needs, while relying on Tendermint as its consensus engine. The Cosmos chain splits the application part of the blockchain and connects it to the network (p2p) and consensus using ABCI. ABCI is the interface that connects the application part of the blockchain to the Tendermint state replication engine that provides consensus and networking mechanisms. Its architecture is usually advertised like this:

Now, let's take a look at Celestia's architecture:

This is what the early ecology looks like on Celestia. Celestia will operate as a shared consensus and data availability layer between all types of Rollups operating within the modular stack. The settlement layer exists to facilitate bridging and liquidity between the various Rollups on it. And you'll likely also see sovereign rollups operating independently, without a settlement layer.

Now that we have identified different levels of modularity, how they work, and what they look like, let’s take a look at some of the unique capabilities and functions of a purely modular blockchain like Celestia.

shared security

One of the advantages of monolithic chains is shared security, so what about in a modular stack?

It's actually quite simple, Celestia provides the fundamental functionality needed to establish shared security on a blockchain network: data availability. This is because each network layer using Celestia needs to pass all their transaction data to the data availability layer to prove that the data is indeed available. This means that blockchain networks can connect, observe and interoperate effortlessly. Hard forks and soft forks are also made very easy by always having the security of the underlying DA layer, which we will discuss later.

Likewise, Celestia allows various types of experimental execution layers to run concurrently, even independent of settlement layers, while still having the benefit of a shared data availability layer. This means that the speed of iteration will become faster, because it may scale linearly with the number of users. So our thesis is that over time this will lead to compound improvements in the execution layer because we're not constrained by having a single hub for the execution layer because execution and data availability are decoupled. The permissionless nature of modularity allows experimentation and gives developers flexibility of choice.

Data Availability Sampling and Block Validation

Celestia's block verification works very differently from other current blockchains because blocks can be verified in sublinear time. This means that throughput increases sublinearly with cost compared to linearly with cost. We can understand it more intuitively through the diagram:

This is possible because Celestia's light clients do not validate transactions, they only check each block for consensus and block data availability.

Celestia eliminates the need to check transaction validity as it only checks for block consensus and data availability, as shown in the diagram above.

Instead of downloading entire blocks, Celestia light nodes download random data samples from within blocks. If all samples are available, then this proves that the entire block is available. Basically, by sampling random data from a block, you can probabilistically verify that the block is indeed complete.

This means that Celestia reduces the problem of block verification to data availability verification, which we know how to do efficiently with sublinear cost using data availability sampling.

DA proof means that when you request the block being sent, you need to perform erasure coding. This means that the original block data is now doubled, and the new data is encoded as redundant data. Celestia's erasure coding increases the block size by 4x, where 25% of the block is original data and 75% is copied data. So requiring a misbehaving sequencer or something like that to withhold data for more than 75% of blocks if it wants to commit fraud.

Thus, it allows light clients to check with a very high probability that all data of a block has been published, only by downloading a fraction of the block (DA sampling). Each round of sampling reduces the probability of data unavailability until it is certain that all data are available. This is very efficient because instead of every node downloading every block, there are many lightweight nodes downloading a fraction of every block, but the safety guarantees are the same as before. This means that as long as there are enough nodes sampling the availability of data, it is possible to increase throughput as the number of sampling nodes increases. You are probably familiar with this type of network (DA Proof) in your daily life, even if you have not used blockchain, by using protocols like BitTorrent.

scalability

When we talk about scalability, the first thought that comes to most people's mind is usually TPS. However, this should not be an actual discussion around scalability. When talking about the scalability of the professional DA layer, it should be mb/s, not TPS, which should be the main obstacle to overcome. Mb/s becomes an objective measure of a chain's capacity, rather than TPS, because transactions vary in size. Celestia does a good job of doing this because it does away with the DA layer and utilizes data availability sampling to increase the number of mb/s the system can handle.

By this we mean that the real limit to how many transactions a blockchain can handle is based on inputs and outputs. Therefore, by decoupling data availability from the input and output process, Celestia will be able to generate much higher mb/s than monolithic chains.

It all stems from the problem of data availability. That is, in a proposed block, the amount of data that a sorter or similar can verify, while being limited by the data throughput of the underlying DA layer. Now, for monolithic blockchains utilizing full nodes, the normal step to address this problem is to increase the hardware requirements for full nodes. However, if you do this, there will be fewer full nodes, and the decentralization of the network will be shaken along with it.

Therefore, by utilizing the techniques we mentioned earlier in the block verification section, we can improve scalability without increasing node requirements, making full nodes equal to light nodes through DA sampling. This in turn causes node growth to lead to more throughput, since DA sampling results in sub-linear growth that is proportional to the number of light nodes being added. In a monolithic chain design, an increase in block size would also increase the cost of validating the network, but on Celestia, this is not the case.

Although, Ethereum also hopes to solve some scalability problems with EIP-4844, which will enable a new type of transaction: blob transactions. It will contain a large amount of data that cannot be accessed by EVM execution, but can still be accessed by Ethereum. This is done because currently, rollup transactions on Ethereum rely on trivially available calldata to execute their transactions. Sharding would also help, but it's still pretty far off, but with blob transactions enabled, that should give around 16MB of data per block for rollups. However, it remains to be seen how fierce the competition for blob transaction space will become. Although, once you solve one of the scalability puzzles, another might pop up. Therefore, by moving to a modular structure, we can allow different parts of the stack to be dedicated to the specific resources they can best utilize.

fork

In most cases, when a monolithic chain hard forks, you lose the underlying security because the execution environments do not share the same security. Often hard forks are not feasible and undesirable because new forks will not have the data availability and security of the consensus layer. It's the same idea when we say you can submit changes to the blockchain code, but you have to convince everyone to agree to your changes. Take bitcoin for example. Bitcoin's code is easy to change, however, getting everyone to agree on the change is the hard part. If you want to hard fork a monolithic chain, you also need to fork the consensus layer, which means you lose the security of the original chain. The amount of security lost depends on the number of miners or validators not validating the new canonical chain. However, if all validators upgrade to the same fork, then there is no loss of security. On a modular blockchain, this is not the case, because if you want to fork a settlement or execution layer, you still have the security of the underlying consensus layer. In this case, forking is possible because the execution environments all share the same security. Although, this is not possible with settlement layer rollups, since the settlement layer acts as a source of trust for newly added blocks.

For the execution environment, hard forks are infinite and easy to accomplish, the reason being that bold ideas can be tested and tried. It also makes it feasible to build on the work of others without losing the security of the base layer. If you think about the idea of a free market (some might disagree with this), it can often create competing implementations that lead to better outcomes.

modular stack

The modular stack is a unique Celestia concept. It refers to the decoupling of all the different layers of the blockchain into independent layers. So when we say a stack, we mean all the layers working together.

So what layers exist? Needless to say, there is the consensus and data availability layer Celestia, but there are others as well. Here we specifically refer to the settlement layer, which can be a chain, and the rollups on this chain have a trust-minimized bridge for unified liquidity and bridging between rollups. These settlement layers can be of various types. For example, you could have restricted settlement layers that only allow rollups based on it to have simple bridge and resolve contracts. However, you can also have a settlement layer with your own applications and rollups on it. Although there are other types of rollups that do not depend on the settlement layer but rely solely on Celestia's own functionality, these are called sovereign rollups and we discuss these in the next chapter.

Now, it is also possible to have a stack where the execution layer does not publish block data directly to the settlement layer, but directly to Celestia. In this case, the execution layer just publishes their block header to the settlement layer, and the settlement layer checks whether all the data of a certain block is contained in the DA layer. This is done via a contract in the settlement layer that receives a Merkle tree of transaction data from Celestia. This is what we call data proof.

Another huge advantage of the modular stack is its sovereignty. In a modular stack, governance can be partitioned into specific applications and layers without overlapping with other applications. If there is a problem, the governor can fix it without disturbing other applications in the cluster.

Sovereign Rollups

A sovereign rollup (sovereign rollup) is a rollup that operates independently of any settlement layer. This means that instead of relying on a settlement layer with smart contract functionality (providing state updates and proofs), it functions purely through namespaces on Celestia. Typically, rollups function within an ecosystem, such as Ethereum, which has a rollup smart contract (parse contract). The rollup smart contract also provides a trust-minimized bridge between the settlement layer and the rollup. However, on Ethereum, all rollups compete for precious calldata. That's why EIP-4844 is being worked on, which will provide a new transaction type: blob transactions. This also increases the block size. However, even with blob transactions, there will likely still be intense competition for settlement.

Most monolithic chains are capable of handling smart contracts. Taking Ethereum as an example, there is an on-chain smart contract that handles the state root, which is the Merkle root of the current state of the rollup. This contract constantly checks whether the previous state root matches its current root's rollup batch. If so, then a new state root is created. However, on Celestia this is not possible as Celestia does not handle smart contracts.

On Celestia, instead, sovereign rollups publish their data directly to Celestia. The data here will not be calculated or settled, but just stored in the block header. A block header is what identifies a specific block on the blockchain, and each block is unique. In this block header, there exists a Merkle root, which consists of all hashed transactions.

So, how does it work? Rollup has its own peer-to-peer network from which both full nodes and light nodes download blocks. However, they also verify that all rollup block data is sent and ordered on Celestia (hence the term data availability) via the Merkle tree. Thus, the canonical history of the chain is set by the local nodes that verify that the rollup's transactions are correct. The implication of this is that sovereign rollups need to publish every transaction on the data availability layer so that any node can track the correct state. Thus, full nodes that are observers of the rollup namespace (think of the namespace as the rollup's smart contract) can also provide security for light nodes. This is because, on Celestia, light nodes are almost equivalent to full nodes.

Let's explain namespaces a little more. On Celestia, the Merkle tree is sorted by namespace, which allows any rollup on Celestia to only download data related to their chain, while ignoring the data of other rollups. Namespaced Merkle Trees (NMTs) enable rollup nodes to retrieve all the rollup data they query without having to parse the entire Celestia or rollup chain. Additionally, they allow validator nodes to certify that all data has been correctly included in Celestia.

So why is sovereign rollup a unique prospect? Because the previous rollup implementation, such as the implementation on Ethereum, is limited, because the Ethereum node takes care of all functions, so it needs to store execution-related states. However, in a modular design, we can have dedicated nodes for various purposes, which should make the network much cheaper to run. Therefore, the cost of running the network is proportional to the cost of a light node, not a full node because, as we explained earlier, a light node is equivalent to a full node.

Let's take a look at how some rollup implementations function as sovereign rollups. First, it's worth explaining how the various rollup proof systems work on Celestia.

Optimistic rollups rely on fraud proofs. Fraud proofs will be spread point-to-point between customers through rollup's full nodes and light nodes. We will investigate the implementation of this further. Sovereign rollups change the way fraud proofs are distributed. Instead of being validated on the settlement layer contract, they are now distributed across the rollups peer-to-peer network and validated by local nodes. With Sovereign Optimistic Rollups on Celestia, we also potentially minimize the challenge period, which means we solve one of the main hurdles for current ORs, as they currently have a very conservative dispute window on Ethereum. This is possible because currently, all fraudulent interactions occur on-chain in Ethereum's highly competitive block space, which leads to long periods of finality. However, on a sovereign rollup, any light node has the security of a full node if connected to an honest full node, so fraudulent interactions should be faster.

ZK rollups rely on validity proofs (such as zksnarks). ZK rollups as sovereign rollups function fairly similarly to the current implementation. However, instead of sending ZK proofs to the smart contract, it is distributed in the rollup's peer-to-peer network for nodes to verify. Sovereign ZK rollups are much like ZK rollups on the Unified Settlement Layer, allowing various execution runtimes to operate as sovereign chains on top of each other since their transactions are not interpreted by Celestia. Here, the runtime on top of ZK rollup can operate in a number of ways. There can be privacy-preserving runtimes, application-specific runtimes, and so on. This is called Fractal Scaling.

Now that we have established the concept of sovereign rollups and have an idea of how they will be implemented on Celestia, let's see how two different rollup architectures look like:

So why do they need Celestia? Optimistic rollups require DA in order to detect evidence of fraud, while ZK rollups require DA in order to know the state of the rollup chain.

It's also important to always think backwards when you see something. Because if you don't, you're often blinded by your own beliefs. In this section, I try to explain some of the downsides of sovereign rollups.

Sovereign rollups will rely heavily on new ecosystems (eg dApps) built on top of them. However, it is much easier to do so if the rollup itself is already established and the dApps are open source. Still, liquidity remains a major issue to overcome. Liquidity is usually divided into sovereign rollups and runtimes based on them. As such, rollups will rely heavily on secure, trust-minimized bridges to other layers such as other sovereign rollups or settlement layers. We'll cover some possible implementations later. Furthermore, the implementation of sovereign rollups is heavily dependent on the infrastructure being built to support their various functions.

Optimistic Rollup implementation

In this section we try to explain how a possible implementation of sovereign optimistic rollup works.

One of the unique ways to construct fraud proofs for OR is to play a game on rollup using full nodes and light nodes. The game is played between two nodes, one is the challenger and the other is the answerer. The challenger will send a query to the responder through a third node acting as a validator. The responder's reply to this query will occur through the same channel. Upon receiving a challenge, the verifier forwards the query to the responder, who then generates a response that is sent back to the verifier and challenger. Validators will consistently perform checks to ensure there are no mismatches between the two and that they are not malicious. The action of the verifier is to ensure that the responder did not send the wrong Merkle tree, while the action of the challenger is to ensure that the responder follows the correct root. If the responders are able to defend themselves, then the game will continue as usual. In this game, the honest challenger always wins, and the honest responder always wins.

Celestia acts as a data availability layer and X acts as a settlement layer

It is also possible to use neither a settlement layer purely connected to Celestia for bridging nor a sovereign rollup feature. Since Celestia simply provides shared security for the underlying DA layer, any settlement layer can be used as long as Celestia can send the Merkle root of available transaction data to a settlement layer contract. This means that any settlement layer can be used for rollup if desired. So why are they doing this? Many existing settlement layers, such as Ethereum, already have a thriving ecosystem. So there is already liquidity and users to take advantage of. This is especially beneficial for rollups that don't want to depend on building an entire ecosystem from scratch. Now, this is not limited to Ethereum as a settlement layer. For example, you can also use Mina as a ZK rollup. This means you can send your transaction data to Celestia while simultaneously sending state updates and zk-proofs to Mina. By doing this, you already have a settlement layer that proves validity by default.

If you are a rollup operator looking to leverage liquidity and users on other blockchains, then this type of solution is very attractive to you. It could also be a plug-and-play type of rollup operator. You can plug different sorters into different settlement layers. For example, a ZK rollup sequencer can connect to Mina and provide state updates and validity proofs. And another sorter on a different ZK rollup can be connected to Ethereum for settlement through Quantum. What they have in common is that they will send all transaction data to Celestia, and then Celestia will operate a smart contract or similar contract at the settlement layer, where it will send a Merkle tree of available data (authentication).

Let's take ZK rollup as an example to see how it is implemented architecturally:

value capture

The source of income for Celestia itself will be transaction fees from various submitted transaction batches. Celestia's transaction fees will work very similarly to Ethereum's current EIP-1559, so it's a burn mechanism. This means that there will be a dynamic base fee, which will be burnt, and a "tip" for validators to push certain transactions through faster, and these validators will also get value from token issuance after new blocks. However, this is from the perspective of Celestia's validators, so what would it look like from a user's perspective? Let's first understand the handling fee corresponding to your level (L1 or L2), and then we can figure out what the user experience will look like.

The fee structure for executing rollups will be primarily operational costs and DA issuance costs. There will likely also be overhead costs such that the rollup will generate a profit. This means that for users, you may pay a fee that includes these three aspects plus a congestion fee. However, due to less congestion, this fee may be much lower.

The source of income for the settlement layer is the settlement contract fee that rollups pay to be able to settle it. In addition, through the settlement layer, there will also be trust-minimized bridges between rollups, so it can also charge bridging fees.

So, what happens to sovereign rollups without a settlement layer? In a sovereign rollup, users must pay a gas fee to access the rollup's computation. This rollup will set a fee, most likely determined by governance, and then you may also need to pay congestion charges. These fees on the rollup will include the cost of posting data to Celestia, and a small overhead for the rollup validators. You can waive settlement fees, which can result in extremely low fees for end users.

Finally, we can create a fee structure to understand the impact of various fees on end users. End users of modular stacks may get 3 for a flat fee, 4 is also possible. This is DA publishing fee, settlement contract fee and rollup execution fee. A fourth possible charge is a congestion charge during periods of congestion. Users pay only one fee on the execution layer, which will cover the cost of all layers in the modular stack. So let's see what the fee structure looks like from a user's point of view:

So what does this mean for the future?

If Celestia proves to be a cheaper and faster data availability layer for rollups, while still providing decentralization and shared security, then you could see rollups using it more and more for data availability. If we consider how much a rollup currently costs to use Ethereum's security, a rollup on Celestia will cost less. However, Ethereum's congestion issues are about to be fixed, mainly blob transactions, staking, and sharding.

What about MEVs? Currently, rollup utilizes a sorter to collect and sort users' transactions in a mempool, then execute and publish them to the DA layer. This is a question about MEV as in the current implementation the orderer is mostly centralized and thus not censorship resistant. The current solution is to decentralize the sorter, which is what many current rollup plans do, although this brings its own set of problems. Another way to solve this problem in some form is to separate the ordering of the validator and transaction lists.

Taken together, the layers of the modular stack earn revenue through transaction value. Users get value from transactions at a network layer and pay transaction fees.

bridging

As we discussed earlier, if a rollup has a settlement layer, then it will have a trust-minimized bridge to other rollups through this settlement layer. But what happens if it's a sovereign rollup, or wants to bridge to another cluster? Let's look at inter-rollup communication.

In the case of two sovereign rollups that want to communicate, they can actually use light client technology, which is very similar to what IBC does. The light client will receive the block headers from the two rollups and the proofs used by the rollups through the p2p network. This can be achieved both through locks and minting mechanisms (e.g. IBC) or validators on relayers. By using the Cosmos SDK to build chains, and those bridged using Tendermint or optimmint becomes more seamless, as you can take full advantage of IBC and ICS. However, this requires both chains to contain each other's state machines and have validators of the bridged chain log out transactions. Other means of communication may also exist. For example, we can imagine a third chain, which works with some light clients. Above, two chains that want to bridge can stream their block headers as a data stream, and then as a function of the two settlement layers. Alternatively, you can rely on the Cosmos chain to act as an "intercluster rollup hub", where the chain's validators can operate bridges based on rollup conditions. There are also various bridge-as-a-service chains such as Axelar and others.

However, by far the easiest way to facilitate bridging is to perform rollups using the same settlement layer since they have a trust-minimized bridging contract on that layer.

The bridge between layers is so important because it allows for uniform fluidity. Second, by allowing protocols and layers to compose with each other through shared state, we unlock new levels of interoperability. State sharing refers to the ability of one chain to call another chain. This is of particular interest, especially the ability to use ICS-27's interchain accounts.

Therefore, we can conclude that light clients are essential for an interoperability standard like IBC. Therefore, the Celestia light client will enable more secure inter-chain interoperability in various clusters. Regarding Celestia's connection to IBC, they plan to use governance to whitelist certain chains connected to Celestia to limit state explosion.

End User Authentication

While the various monolithic and modular design approaches over the past few years have been innovative, and the amount of talent that went into building it is staggering. Among the trade-offs, there is a fundamental problem that has existed in our field for quite some time. At the heart of this issue, we believe, is the authentication of end users and their needs.

You can argue endlessly about the various tradeoffs of different designs. But in the end, it probably boils down to the question of whether it matters to have the possibility of end-user authentication. Many design trade-offs (such as block size) revolve around the convenience of running a full node, and DAS makes light clients "first-class citizens" comparable to full nodes.

The basic assumption behind thinking this way is that users care about being "first class citizens". Users can easily verify the chain by running a light client/full node, but that doesn't mean they will, or that they will value the ability to do so.

The arguments in favor of this approach are fairly straightforward. If users don't care about verification, you might as well run a centralized database. It's always more efficient because decentralization often comes at the expense of efficiency. Therefore, the reason we build cryptographic protocols is so that end users can verify computations.

The counter-argument is that, as long as the network is sufficiently decentralized, end-user verification itself doesn't matter. As long as the user experience is good, users will not care about it. How important end-user authentication is, there is no clear answer. However, we believe that end users being able to verify blockchain networks is a worthwhile goal and the reason many are building in this space.

The Future of the Modular Stack

This section is intended as a way to envision what a modular stack built on top of Celestia might look like in the future. We'll give an architectural overview of how to look at the modular stack, and the types of layers we might see.

Below is a diagram of the many possible layers that can function in a modular stack. They all have one thing in common, they all use Celestia to fetch data. We may see various sovereign rollups, including OR and ZK Rollups, which will have no settlement layer functionality. We may also see rollups using Cevmos as a settlement layer, and various application chains. It is also possible that we will see other types of settlement layers. These settlement layers may be restricted, meaning they either pre-set contracts just for bridging and rollup, or rely on governance to whitelist contracts.

On the right side of the diagram are other non-native settlement chains, some rollups can also take advantage of their liquidity and settlement capabilities, while relying on Celestia to provide authentication of transaction data to the settlement layer.

All these clusters will be connected through various bridging services.

What you don't see is all the infrastructure that will be built to provide easy access to Celestia's various features, such as RPC endpoints, APIs, and more.