Most applications that use Celestia as their consensus and data availability layer will be hosted on Rollup. As a new Layer 2 solution, originally proposed to increase transaction throughput, Rollup could be the future home of almost any blockchain application, whether using Celestia, Ethereum, or other platforms 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.
In the current Ethereum Rollup, the Ethereum chain is enshrined as the settlement layer of the Rollup, making the Rollup effectively a “baby chain” of Ethereum, where the Rollup chain is defined by smart contracts on Ethereum. This is also comparable to the Polkadot parachain model, where the relay chain is enshrined as the parachain’s settlement layer.
In Celestia, however, we envision a new type of rollup: the sovereign rollup chain. These are independent sovereign chains, where the Rollup chain is defined by the Rollup sub-network itself, similar to an independent L1, and can optionally have trusted or trust-minimized bridges with other chains or settlement layers.
Table of contents
- What is Rollup?
- Rollup (settlement layer) on Ethereum
- Rollup on Celestia (Sovereign)
- Sovereign Cross-Rollup Communication
- Why sovereign?
What is Rollup?
A rollup is a blockchain that publishes its blocks to another blockchain and inherits that blockchain’s consensus and data availability (called a “consensus and data availability layer”).
A typical Rollup is maintained by three main parties: sequencers, Rollup full nodes, and Rollup light clients . All Rollups have a state, which may be, for example, all account addresses and token balances of a Rollup user at a certain point in time.
Sequencers are nodes that receive new Rollup transactions from users, combine the transactions into a block, and publish that block to the consensus and data availability layers. A block consists of two parts: the block header and the actual transaction data. Among other things, block headers contain cryptographic commitments to the state of the chain – usually the Merkle root.
A Rollup full node is a node that downloads all Rollup block headers and transaction data, processes and validates all transactions, calculates the status of the Rollup and checks that all transactions are valid. If a full node encounters an invalid transaction in an aggregated block, it rejects and ignores the block. Therefore, Sequencers cannot create valid blocks with invalid transactions because nodes would reject them from their view.
The Rollup light client only downloads the rollup block header, and does not download and process any transaction data, so it cannot calculate the latest state or verify the validity of the state of the rollup itself. Instead, they can learn the latest state commitment from the latest Rollup block header and ask the Rollup full nodes for the partial state. They also indirectly check the validity of Rollup transactions using techniques such as fraud proofs or validity proofs.
When Rollup nodes synchronize the Rollup chain, they use the ordering imposed on the Rollup blocks by the consensus and data availability layers. If it’s the first valid block at its height to be published on the data availability layer in a Rollup, they will confirm the rollup block’s top priority – either a direct check for validity (full node) or an indirect check Effectiveness (light client).
For a more detailed and technical explanation of Rollup, we refer the reader to the article on Rollup on the Celestia forum .
Rollup on Ethereum (enshrined settlement)
The current Rollup on Ethereum publishes its blocks directly to EVM-based smart contracts, also known as bridge contracts. This contract effectively implements an on-chain light client for Rollup that receives block headers and handles fraud or validity proofs. In this model, the Ethereum main chain has a sacred, hard-coded, trust-minimized bridge.
Using bridge contracts, users can deposit and withdraw assets in a trust-minimized manner between the Rollup and the execution chain where the bridge contract resides, as the contract will not accept invalid blocks from Sequencers due to fraud or proof of validity.
The Ethereum chain acts as a consensus and data availability layer, only recording and finalizing blocks that are valid according to the bridge contract. As such, Rollup full nodes and light clients (outside of smart contracts) see on-chain light clients on Ethereum as a fundamental source of truth about what is the canonical (correct) Rollup chain. In this model, we consider Ethereum to be enshrined as a coupled settlement layer for Rollup, where Rollup is Ethereum’s “baby chain” rather than an independent chain with its own rights.
Rollup (Sovereign) on Celestia
Sovereign Rollups on Celestia do not publish their blocks to smart contracts, but directly to the chain as raw data. The Celestia consensus and data availability layer does not interpret or perform any computations on Rollup blocks, nor does it run an on-chain light client for Rollup.
Instead, Rollup operates efficiently like a layer-1 blockchain: full nodes and light clients download Rollup’s blocks directly from Rollup’s own peer-to-peer network. The main difference is that they also verified that the Rollup block data was included and ordered on the Celestia data availability layer via Merkle proofs. Thus, similar to layer 1 blockchains, this canonical chain is determined locally by nodes that validate fork choice rules and Rollup transactions, rather than by on-chain light clients.
Fraud and Proof of Validity also work similarly to how they work in layer 1 blockchains. Fraud proofs are delivered directly to clients via a peer-to-peer network, and validity proofs are simply included in block headers (see, for example, the Mina protocol). Because the network synchronization latency in a peer-to-peer network is likely to be much smaller than the latency of obtaining a fraud proof contained on-chain, this means that the challenge period for a peer-to-peer fraud proof is likely to be much shorter, resulting in faster finalization for light clients sex.
In this model, there is no bridge between the rollup and any settlement layer, because the rollup block is just published directly to the data availability layer, not the smart contract. This is in line with the Cosmos design philosophy, where bridges to the Cosmos Hub are not built-in deterministic, but optional and can be added while still allowing zones to retain their sovereignty. Rollups can still connect to other Rollups in a trust-minimized way – we’ll discuss this in the next section.
A Rollup chain is sovereign if it does not specify a settlement layer that determines the rules of transaction validity for the canonical chain and the Rollup. Instead, Rollup’s canonical chain is determined by nodes in Rollup’s peer-to-peer network (provided the blocks are available at the data availability layer). This means that the settlement layer cannot force transactions to be included in a Rollup.
“No settlement layer” is mainly a social distinction rather than a technical distinction, which means that there is a social contract between Rollup’s communities, that is, Rollup’s transaction validity rules are defined by the community, not an immutable L1 contract. In practice, this means that the bridge to the rollup (which is not written) must be mutable in order to have an upgrade path to confirm a hard fork on the sovereign rollup (discussed in the next section).
Therefore, this means that the Rollup community can upgrade the chain via a hard fork without having to hard fork the settlement layer or data availability layer, and without embedding on-chain governance that disrupts the trust-minimizing nature of the chain. This is especially important if there are assets that are minted locally on the sovereign Rollup chain, rather than all being bridged from other chains.
Sovereign Rollups can also use Ethereum only as a data availability layer, without using Ethereum for settlement, but this adds more overhead compared to using a “pure” data availability layer such as Celestia because Rollup nodes All transactions in the Ethereum settlement layer need to be interested in the validity of the data 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 sovereign rollup. A settlement rollup can have a non-sovereign rollup that uses it as a settlement layer. However, the settlement layer is sovereign, just like Ethereum L1 is sovereign because its community often upgrades it with hard forks through social consensus.
Sovereign Cross-Rollup Communication
As mentioned above, Celestia Rollup does not have a set-up bridge between Rollup and any settlement layer. Rollup’s settlement layer and execution layer are thus decoupled and modularized. So how do Celestia Rollups connect to other chains? Because there is no settlement layer, this allows us to have a wider design space for cross-chain bridges. We explore the design space and various options below.
Let’s assume some sovereign Rollup chain A wants to bridge with another chain B – we’ll assume it’s also a Rollup.
Peer-to-peer vs. on-chain settlement
Chains A and B can directly embed a light client in each other in the light clients of the two chains. For example, both chains will run a light client for chains A and B. Light clients will therefore receive block headers and any associated fraud or validity proofs directly over the peer-to-peer network. We call this peer-to-peer settlement.
A bridge contract exists on both chains, which will allow assets to be withdrawn and deposited into either chain (e.g. through a lock and mint mechanism ) and monitored by sequencers or validators of each chain (either directly or indirectly through relayers) ) to perform the transfer.
On the other hand, light clients can also be implemented as on-chain smart contracts, submitting block headers and fraud/ZK proofs to on-chain smart contracts. This is the current state of Ethereum Rollup. We call this on-chain settlement.
Hub-and-spoke vs. point-to-point bridging
Currently, Rollup is expected to connect to a single settlement layer, such as Ethereum (hub-spoke bridge), that acts as a settlement center. If both Rollup Chains A and B are connected to the same hub (hub), they can use the hub as an intermediary for settlement to connect assets to each other.
However, just like IBC, Rollups also have the option of bridging each other directly instead of using an intermediate Hub chain (point-to-point bridging).
Dynamic and Static Bridging
Depending on the execution environment of the Rollup chain, a chain upgrade or hard fork may be required to bridge the new chain. This is because chains A and B must support each other’s execution environments in order to support each other’s fraud or ZK proofs.
Let’s assume that the state machine of Optimistic Rollup chain A is written directly in Golang (eg using the Cosmos SDK) instead of a smart contract environment like EVM or CosmWasm. In order to bridge with Chain B, Chain B needs to upgrade its node software to use Chain A’s state machine as a library to verify Chain A’s fraud proofs. This is because chain B cannot automatically add chain A’s state machine code, as it could be malicious or non-deterministic, posing a security risk. Therefore, social consensus or governance is required to increase such bridges. This is also required in the case of a valid Rollup using a ZK proof structure that chain B does not understand. We call this static bridging because the bridging has to be added explicitly via a chain upgrade. Such a bridge can be implemented as an IBC light client .
On the other hand, if Optimistic Rollup Chain A is written in a sandbox smart contract environment like EVM or CosmWasm, then Chain B can allow Chain A’s state machine code to be added directly to Chain B’s state machine without any necessity For social consensus or governance, such as using smart contracts. Likewise, if chain A is a ZK rollup, it can be dynamically bridged to chain B, as long as chain B can understand chain A’s ZK proofs. We call this dynamic bridging.
Non-enshrined and enshrined settlement layers
If a Rollup chain publishes its blocks and proofs to a settlement layer that acts as a settlement center (like Ethereum), we say that a settlement layer is enshrined (holy or perfect) if the canonical chain and its transaction validity rules are determined by the settlement layer of.
On the other hand, if Rollup publishes its blocks and proofs to the settlement layer, but the canonical chain of the Rollup is ultimately determined by the Rollup network itself, we say that the settlement layer is non-enshrined. In order for a non-enshrined SL to make sense, it should have a way to upgrade Rollup that doesn’t require a hard fork of the SL.
Committee-Based vs Proof-Based Bridges
To minimize trust in a cross-chain bridge between two Rollup chains, the Rollup chains must verify each other’s fraud or ZK proofs, which means they must know each other’s state machines (proof-based bridges).
However, committee-based bridges also exist (such as today’s IBC bridge), which do not rely on proofs of state validity, but instead rely on committees to prove the validity of blocks. Such bridges do not minimize trust, as the committee can steal funds. However, such a bridge may be of lower complexity, as the destination chain does not need to have the capability to handle fraud or ZK proofs of the source chain.
In the current IBC bridge, the committee is the set of validators for the source chain. However, one can imagine a world where committees are run by specialized cross-chain bridge providers that certify multiple chains. This can be thought of as interchain security for bridges only, not block production. In such a setup, the bridge committee is decoupled from the validator set of the source chain.
Upgradable and non-upgradable cross-chain bridges
The ultimate goal of current Ethereum Rollups is that Rollups should not be upgraded by multi-signature or committees, because if they could, they would not be trust-minimized, as funds could be stolen through the upgrade. In this model, Rollups can only be upgraded by hard forking L1, because the canonical chain is defined by L1’s settlement layer, which means that Rollups have no sovereignty.
However, in order for a sovereign rollup to be practical, there should be an upgrade path that recognizes the rollup as a sovereign rather than a sacred settlement layer. There are several approaches to consider that affect whether the bridge minimizes trust. Suppose a Rollup chain A is a hard fork, and chain B needs to upgrade its light client for chain A:
- For static bridges, chain B also needs a hard fork. Such an upgrade path would imply trust minimization for the bridge, as no multisig or committees are involved.
- For dynamic bridges, a committee controlled by chain A (such as the DAO) can upgrade light clients on chain B. This will be a credible bridge.
- For dynamic bridges, a committee controlled by Chain B (eg DAO) can upgrade light clients on Chain B. If chain B is the settlement layer, this puts the responsibility on the settlement layer to implement upgrades, which may be desirable if the settlement layer has dedicated governance, or has high economic security. It will also be a trustworthy bridge.
“Sovereignty isn’t just a meme. It’s the ability to hard fork. It’s a realization: The most important layer in blockchains and society is social consensus.
It’s the encoding of people > tokens. People > Validation People. People > Governance.”
At the core of Rollup are simple blockchains, and Rollup bridges are just light clients for these blockchains. The current status quo of Rollup popularized by Ethereum aims to have non-upgradable rollups with a sacred settlement layer. This is equivalent to running a client for a blockchain that can never be upgraded, and whose blocks are only valid when accepted for Rollup by a sacred on-chain instance of the light client. As shown above, this is only a small part of the Rollup design space.
At Celestia Labs, we are interested in sovereign rollups without a fixed settlement layer because we believe the most important layer in a blockchain is social consensus. In particular, blockchain is a tool that allows communities to socially coordinate in a sovereign manner without being burdened by the status quo. This means treating hard forks as a feature, not a bug, because 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 an efficient way for sovereign communities to have community computers to track and enforce socio-economic values and agreements, without the overhead of bootstrapping or maintaining their own consensus layers and validator sets, and without the need to submit to a sacred one they support or not. Social consensus at the settlement layer.
Sovereign Rollups also give developers more flexibility in their execution environment, as they are not constrained by the divine settlement layer that must handle fraud or ZK proofs for their Rollups, as in many cases some settlement layers exist Fraud or ZK proofs may not be handled easily or efficiently.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/how-is-rollup-used-as-a-sovereign-chain-on-celestia/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.