Rollups as Sovereign Chains

Most applications using Celestia as their consensus and data availability layer will be hosted on rollups. As a new layer 2 solution first proposed to increase transaction throughput, rollups may be the future home of almost all blockchain applications whether they use Celestia, Ethereum or another platform for consensus and data availability.

In this post, we will discuss what rollups are, how they currently work on Ethereum and how they will work on Celestia.

With current Ethereum rollups, the Ethereum chain is enshrined to the rollup as a settlement layer, making Ethereum rollups effectively 'baby chains' to Ethereum, where the correct rollup chain is defined by a smart contract on Ethereum. This is also comparable to the Polkadot parachain model, where the relay chain is enshrined as a settlement layer for parachains.

However in Celestia, we envision a new type of rollup: sovereign rollup chains. These are independent, sovereign chains in their own right where the correct rollup chain is defined by the rollup sub-network itself, similar to an independent L1, and may optionally have trusted or trust-minimized bridges with other chains or settlement layers.

Table of contents

• What are rollups?
• Rollups on Ethereum (enshrined settlement)
• Rollups on Celestia (sovereign)
• Sovereign cross-rollup communications
• Why sovereign?

What are rollups?

Rollups are blockchains that post their blocks to another blockchain, and inherit the consensus and data availability of that blockchain (referred to as a "consensus and data availability layer").

Typical rollups are maintained by three main parties: sequencers, rollup full nodes, rollup light clients. All rollups have a state, which may for example be all the account addresses and token balances of the users of a rollup at a point in time.

Sequencers are nodes which receive new rollup transactions from users, combine the transactions into a block, and post that block to the consensus and data availability layer. A block consists of two components: a block header, and the actual transaction data. The block header contains, amongst other things, a cryptographic commitment to the state of the chain—usually a Merkle root.

Rollup full nodes are nodes which download all rollup block headers and transaction data, process and verify all transactions, in order to compute the state of the rollup and check that all the transactions are valid. If a full node comes across an invalid transaction in a rollup block, it rejects and ignores that block. Therefore sequencers cannot create valid blocks with invalid transactions, because nodes will reject them from their view.

Rollup light clients only download the rollup block headers, and do not download and process any transaction data, and thus cannot compute the latest state or verify the state validity of the rollup themselves. They can instead learn about the latest state commitment from the latest rollup block header, and ask rollup full nodes for parts of the state. They also check the validity of the rollup transactions indirectly, using techniques such as fraud proofs or validity proofs.

When rollup nodes sync the rollup chain, they use the ordering imposed on the rollup blocks by the consensus and data availability layer. They finalize a rollup block if it is the first valid block at its height within the rollup to be published on the data availability layer—whether or not the validity is checked directly (full nodes), or indirectly (light clients).

For a more detailed and technical explanation of rollups, we refer the reader to this Celestia forum article on rollups.

Rollups on Ethereum (enshrined settlement)

Current rollups on Ethereum post their blocks directly to an EVM-based smart contract, also known as a bridge contract. This contract effectively implements an on-chain light client for the rollup, that receives block headers and processes fraud or validity proofs. In this model, there is an enshrined, hard coded, trust-minimized bridge to the Ethereum main chain.

Using the bridge contract, users can deposit and withdraw assets between the rollup and the execution chain that the bridge contract lives on in a trust-minimized way, because the contract will not accept invalid blocks from sequencers, thanks to fraud or validity proofs.

The Ethereum chain, acting as a consensus and data availability layer, only records and finalizes blocks that are valid according to the bridge contract. Thus the rollup full nodes and lights clients (outside of the smart contract) consider the Ethereum on-chain light client as the root source of truth as to what the canonical (correct) rollup chain is. In this model, we consider that Ethereum is enshrined as a coupled settlement layer for the rollup, where the rollup is a 'baby chain' to Ethereum rather than an independent chain in its own right.

Rollups on Celestia (sovereign)

Sovereign rollups on Celestia do not post their blocks to a smart contract, but directly onto the chain as raw data. The Celestia consensus and data availability layer does not interpret or perform any computation on the rollup blocks, nor run an on-chain light client for the rollup.

Instead, the rollup effectively operates like a layer 1 blockchain: full nodes and light clients download the blocks of the rollup directly from the rollup's own peer-to-peer network. The main difference is that they also verify that the rollup block data was included and ordered on the Celestia data availability layer via a Merkle proof. Therefore, similar to a layer 1 blockchain, the canonical chain is determined by nodes that locally verify the fork-choice rule and the transactions of the rollup, rather than an enshrined on-chain light client.

Fraud and validity proofs also work similarly to how they would work in a layer 1 blockchain. Fraud proofs are gossiped to clients directly via the peer-to-peer network, and validity proofs are simply included with the block header (for example, see Mina Protocol). Because the network synchrony delay in a peer-to-peer network is likely to be significantly smaller than the delay of getting a fraud proof included on-chain, this means that the challenge period for peer-to-peer fraud proofs can likely be much lower, leading to faster finality for light clients.

In this model, there is no enshrined bridge between the rollup and any settlement layer, because the rollup blocks are simply posted to a data availability layer directly, rather than a smart contract. This is aligned to the Cosmos design philosophy, where a bridge to the Cosmos Hub is not enshrined to Cosmos zones, but is optional and can be added while still allowing zones to retain their sovereignty. Rollups may still bridge to other rollups in a trust-minimized way—we will discuss this in the next section.

A rollup chain is sovereign if it does not enshrine a settlement layer to determine the canonical chain and the transaction validity rules of the rollup. Rather, the canonical chain of the rollup is determined by the nodes in the rollup's peer-to-peer network (provided that the blocks are available on the data availability layer). This means that the settlement layer cannot force inclusion of transactions into the rollup.

To “not enshrine a settlement layer” is primarily a social distinction rather than a technical one, which means that there is a social contract between the rollup’s community that the rollup’s transaction validity rules are defined by the community rather than an immutable L1 contract. In practice, this means that bridges to the rollup, which are not enshrined, must be mutable so that there is an upgrade path which acknowledges hard forks on the sovereign rollup (discussed in the next section).

Consequently, this means that the community of a rollup can upgrade the chain with a hard fork, without needing to hard fork the settlement layer or the data availability layer or embedding on-chain governance that defeats the trust-minimized nature of the chain. This is particularly relevant if there are assets that are minted natively on the sovereign rollup chain, rather than all of the assets being bridged from other chains.

Sovereign rollups can also use Ethereum as a data availability layer only without enshrining Ethereum for settlement, however this adds more overhead compared to using a “pure” data availability layer such as Celestia, because the rollup nodes need to take an interest in the validity of all the transactions in the Ethereum settlement layer, in order to run a node for the Ethereum data availability layer.

It is also possible to construct a “settlement rollup” on Celestia, which is a type of a sovereign rollup. A settlement rollup can have non-sovereign rollups that use it as an enshrined settlement layer. However, the settlement layer is sovereign in the same way that the Ethereum L1 is sovereign as its community often upgrades it with hard forks via social consensus.

Sovereign cross-rollup communications

As mentioned above, Celestia rollups do not have an enshrined bridge between the rollup and any settlement layer. The settlement layer and the execution layer of the rollup is therefore decoupled and modularized. So how can Celestia rollups bridge to other chains? Not having an enshrined settlement layer allows us to have a broader design space for cross-chain bridges. We explore the design space and various options below.

Let us assume that some sovereign rollup chain A wants to bridge with another chain B—which we will assume is also a rollup.

Peer-to-peer vs. on-chain settlement

Chains A and B could directly embed a light client for each other in both chain's light clients. For example, both chains would run a light client for chains A and B. The light clients would therefore receive the block headers and any associated fraud or validity proofs directly via the peer-to-peer network. We refer to this as peer-to-peer settlement.

A bridging contract would exist on both chains, that would allow assets to be withdrawn and deposited to either chain (e.g. via a lock and mint mechanism), and monitored (either directly or indirectly via a relayer) by each chain's sequencers or validators to execute the transfers.

On the other hand, the light clients could also be implemented as on-chain smart contracts, and block headers and fraud/ZK proofs would be submitted to the on-chain smart contracts. This is the status quo with Ethereum rollups. We refer to this as on-chain settlement.

Hub-and-spoke vs point-to-point bridging

Currently, rollups are expected to bridge to a single settlement layer that acts as a settlement hub, such as Ethereum (hub-and-spoke bridging). If rollup chains A and B are both connected to the same hub, then they can bridge assets to each other using the hub as an intermediary for settlement.

However, just like IBC, rollups could also choose to bridge directly to each other instead of using an intermediary hub chain (point-to-point bridging).

Dynamic vs. static bridging

Depending on the execution environment of the rollup chains, a chain upgrade or hard fork may be required to bridge new chains. This is because chains A and B must support the execution environments of each other in order to support the fraud or ZK proofs of each other.

Let us assume that the state machine of an optimistic rollup chain A is written directly in Golang (e.g. using the Cosmos SDK), rather than a smart contract environment such as EVM or CosmWasm. In order to bridge with chain B, chain B will need to upgrade their node software in order to include the state machine of chain A as a library, in order to validate the fraud proofs of chain A. This is because chain B cannot automatically add chain A's state machine code because it might be malicious or non-deterministic, thus posing a security risk. Therefore social consensus or governance is needed to add such a bridge. This would also be similarly needed in the case of a validity rollup that uses a ZK proof construction not understood by chain B. We refer to this as static bridging, because bridges must be explicitly added by chain upgrades. Such a bridge could be implemented as an IBC light client.

On the other hand, if an optimistic rollup chain A is written in a sandboxed smart contract environment such as EVM or CosmWasm, then chain B could allow the state machine code of chain A to be added directly into chain B's state machine, without any need for social consensus or governance, for example using a smart contract. Likewise, if chain A was a ZK rollup, it could be bridged dynamically to chain B, as long as chain B is capable of understanding chain A's ZK proofs. We refer to this as dynamic bridging.

Non-enshrined vs enshrined settlement layer

If a rollup chain posts its blocks and proofs to a settlement layer that acts as a settlement hub such as Ethereum, we say that the settlement layer is enshrined if the canonical chain and its transaction validity rules are determined by the settlement layer.

On the other hand, if the rollup posts its blocks and proofs to a settlement layer but the canonical chain of the rollup is ultimately decided by the rollup network itself, we say that the settlement layer is non-enshrined. In order for a non-enshrined settlement layer to make sense, it should have a way to upgrade the rollup that does not require hard forking the settlement layer.

Committee-based vs proof-based bridges

In order for a bridge between two rollup chains to be trust-minimized, the rollup chains must verify the fraud or ZK proofs of each other, which means they must understand the state machine of each other (proof-based bridges).

However, committee-based bridges also exist (such as IBC bridges today), where instead of relying on proofs for state validity, the bridge relies on a committee to attest to the validity of blocks. Such a bridge is not trust-minimized, as the committee can steal funds. However, such bridges may have lower complexity as the destination chain does not need to have functionality to process fraud or ZK proofs of the source chain.

In current IBC bridges, the committee is the validator set of the source chain. However, one can envision a world where the committee is operated by specialized bridge providers that attest to multiple chains. This can be thought of as interchain security for bridges only, rather than block production. In such a setup, the bridge committee is decoupled from the validator set of the source chain.

Upgradeable vs non-upgradeable bridges

The eventual goal of current Ethereum rollups is that the rollups should not be upgradeable by a multisig or a committee, because if they can they are not trust-minimized as funds can be stolen via an upgrade. In this model, rollups can only be upgraded by hard forking the L1 because the canonical chain is defined by the L1's settlement layer, meaning the rollups have no sovereignty.

However for sovereign rollups to be practical, there ought to be an upgrade path which acknowledges that the rollups are sovereign rather than enshrined to a settlement layer. There are several approaches that can be considered, which impact if the bridge is trust-minimized or not. Consider a rollup chain A is hard forking, and chain B needs to upgrade its light client for chain A:

• For a static bridge, chain B needs to also hard fork. Such an upgrade path would mean the bridge is trust-minimized as there is no multisig or committee involved.
• For a dynamic bridge, a committee (e.g. a DAO) controlled by chain A could upgrade the light client on chain B. This would be a trusted bridge.
• For a dynamic bridge, a committee (e.g. a DAO) controlled by chain B could upgrade the light client on chain B. If chain B is a settlement layer, this puts the onus on the settlement layer to implement upgrades, which may be desirable if the settlement layer has governance specialized for this, or has high economic security. This would also be a trusted bridge.

Why sovereign?

At their core, rollups are simply blockchains, and rollup bridges are simply light clients for those blockchains. The current status quo for rollups popularized by Ethereum aims for non-upgradeable rollups with an enshrined settlement layer. This is equivalent to running a client for a blockchain that can never be upgraded, whose blocks are only valid if accepted by one enshrined on-chain instance of a light client for the rollup. As we have shown above, this is only a small subset of the design space for rollups.

At Celestia Labs, we're interested in sovereign rollups without an enshrined settlement layer, because we believe that the most important layer in blockchains is social consensus. In particular, blockchains are a tool to allow communities to socially coordinate in a sovereign way, without being burdened by the status quo. This means treating hard forks as a feature, not a bug, as hard forks give sovereign communities the ability to enforce social consensus. This is especially important as a social recourse mechanism when things go wrong, such as when Ethereum forked after the DAO hack.

Sovereign rollups will be a powerful way for sovereign communities to have community computers to track and enforce socio-economic value and agreements, without the overhead of having to bootstrap or maintain their own consensus layers and validator sets, and without being subordinate to the social consensus of an enshrined settlement layer which they may or may not align with.

Sovereign rollups also give developers more flexibility over their execution environment, as they are not bound to the limitations of an enshrined settlement layer that must process fraud or ZK proofs for their rollups, as in many cases there are fraud or ZK proofs that certain settlement layers may not be able to process trivially or efficiently.

Keep an eye out for a future post where we will go into more depth in laying out the case for why sovereignty matters in blockchains.