# Rollups are Sovereign Chains By [Content Hub - LuckyResearch Labs](https://paragraph.com/@luckyresearch) · 2025-04-04 --- ![](https://storage.googleapis.com/papyrus_images/982b6b27c3f3f13a7f73017f07244f76165591b588fa5068f91a45f26cb3f1b4.webp) Most applications using Celestia as their consensus and data availability layer will be stored on _rollups_. As a new layer 2 solution first proposed to increase transaction throughput, rollups are likely the future home of most 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 held in the rollup chain as a settlement layer, effectively making Ethereum rollups a ‘child chain’ to Ethereum, where the exact rollup chain is determined by a smart contract on Ethereum. This is also comparable to the Polkadot parachain model, where the relay chain is considered the settlement layer for the parachain. Rollups are responsible for executing and validating their own transactions. This means they have their own rules and mechanisms to ensure that all transactions are valid and that all nodes agree on the aggregated state. To ensure that data is correct, rollups use fraud proofs and validity. **What is a Rollup?** --------------------- Rollups are blockchains that post their blocks to another blockchain and inherit that blockchain's consensus and data availability (known as the "consensus and data availability layer"). Rollups are typically maintained by three main parties: **ordering servers** , **aggregating full nodes** , **lightweight aggregating clients** . All aggregates have a _state_, for example, it could be all of a user's account addresses and token balances totaled at a point in time. **Sorters** are nodes that receive new aggregate 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, among other things, a cryptographic promise about the state of the chain—usually a Merkle root. **Full aggregators** are nodes that download all aggregate block headers and transaction data, process and verify all transactions to calculate the aggregate state, and check that all transactions are valid. If a full node encounters an invalid transaction in an aggregate block, it rejects and skips that block. As a result, chainers cannot create valid blocks with invalid transactions, as nodes will reject them from their view. **Aggregator clients** only download aggregate block headers and do not download or process any transaction data, and thus cannot compute the latest state or verify the validity of the aggregate state themselves. Instead, they can learn about the latest state commitment from the latest aggregate block header and ask full aggregator nodes for parts of the state. They also check the validity of aggregate transactions indirectly, using techniques such as [**fraud proof**](https://arxiv.org/abs/1809.09044) or [**validity proof**](https://ethereum.org/en/developers/docs/scaling/zk-rollups/). As rollup nodes synchronize the rollup chain, they use the order imposed on the rollup blocks by the consensus layer and data availability. They finalize the rollup block if it is the first valid block at its height in the total to be published on the data availability layer—whether the validity is checked directly (full node) or indirectly (light client). **Rollups on Ethereum (recorded payments)** ------------------------------------------- ![](https://storage.googleapis.com/papyrus_images/98abf4b79e64e728492410695b53ffe1ae5d2b0d58a3ce63e44948b2ff66e448.webp) Current rollups on Ethereum post their blocks directly to an EVM-based smart contract, also known as a bridge contract. This contract effectively deploys an on-chain light client for rolling, receiving block headers, and processing fraud or validity proofs. In this model, there is a hardcoded, secure bridge, reducing trust to the Ethereum main chain. By using a bridge contract, users can deposit and withdraw assets between the aggregate chain and the execution chain where the bridge contract exists in a trust-minimized manner, as the contract will not accept invalid blocks from the chain arranger, due to fraud or validity proofs. The Ethereum chain, acting as a consensus and data availability layer, only records and finalizes valid blocks according to the bridging contract. Therefore, aggregating full nodes and light clients (outside the smart contract) consider the light client on the Ethereum chain to be the source of truth about what the (correct) _standard_ aggregate chain is. In this model, we consider Ethereum to be _considered_ a hybrid settlement layer for aggregation, where aggregation is a 'child chain' to Ethereum rather than an independent chain in its own right. **Rollups on Celestia (sovereign)** ----------------------------------- ![](https://storage.googleapis.com/papyrus_images/e7ca9365ee7a52279ceb50d4e57a399c72f49c9018a8aa499968fc461aa42e42.webp) Sovereign rollups on Celestia do not post their blocks to a smart contract, but directly to the chain as raw data. The Celestia consensus and data availability layer does not interpret or perform any computations on aggregated blocks, nor does it run an on-chain light client for aggregation. Instead, aggregation works effectively like a layer-1 blockchain: full nodes and light clients download aggregated blocks directly from the aggregation's own peer-to-peer network. The key difference is that they also verify that aggregated block data has been included and arranged on the Celestia data availability layer via Merkle proofs. Thus, similar to a layer-1 blockchain, the canonical chain is determined by nodes that locally verify the aggregation's branch selection rules and transactions, rather than a light client hosted on-chain. Fraud proofs and validity also work similarly to how they work in layer 1 blockchains. Fraud proofs are transmitted directly to clients via the peer-to-peer network, and validity proofs are simply included in the block header (see for example the Mina Protocol). Because the network synchronization latency in a peer-to-peer network can be significantly lower than the latency of including fraud proofs on-chain, this means that the challenge period for peer-to-peer fraud proofs can be much longer, resulting in a faster termination for lightweight clients. In this model, there is no fixed bridge between the aggregate and any settlement layer, because aggregated blocks are simply posted directly to the data availability layer rather than a smart contract. This is consistent with the Cosmos design philosophy, where the bridge to the Cosmos Hub is not mandated for Cosmos regions but is optional and can be added while still allowing regions to retain their sovereignty. Aggregates can still connect to other aggregates in a trust-minimizing way—we will discuss this in the next section. ![](https://storage.googleapis.com/papyrus_images/458592640388cc5675b565a9829878f45a63044c58a64f26b41072d39f4133a2.webp) The aggregate chain is sovereign if it does not maintain a settlement layer to determine the aggregate’s standard chain and transaction validation rules. Instead, the aggregate’s standard chain is determined by the nodes in the aggregate’s peer network (provided that blocks are available on the data availability layer). This means that the settlement layer cannot force transactions to be included in the aggregate list. “No settlement layer custody” is primarily a social distinction rather than a technical one, meaning that there is a social contract among the aggregator community that the transaction validity rules of the aggregator are determined by the community rather than an immutable L1 contract. In practice, this means that bridges to the non-storage aggregator must be mutable in order to have an upgrade path that acknowledges hard forks on the sovereign aggregator (discussed in the next section). This therefore means that the aggregator community can upgrade the chain with a hard fork without hard forking the settlement layer or the data availability layer or embedding governance on the chain to defeat the trustless nature of the chain. This is especially relevant if there are assets that are natively created on the sovereign aggregator chain, rather than all assets being bridged from other chains. Sovereign aggregators can also use Ethereum only as a data availability layer without holding Ethereum for settlement, however this adds overhead compared to using a “pure” data availability layer like Celestia, as aggregator nodes need to care about the validity of all transactions in the Ethereum settlement layer, to run a node for the Ethereum data availability layer. It is also possible to build a [“payment aggregator” on Celestia](https://forum.celestia.org/t/an-open-modular-stack-for-evm-based-applications-using-celestia-evmos-and-cosmos/89) , a type of sovereign aggregator. A settlement aggregator can have non-sovereign aggregators using it as a regulated settlement layer. However, the payment layer is sovereign in the same way that Ethereum L1 is sovereign because its community regularly upgrades it with hard forks through social consensus. Celestia's design mitigates the effects of reorganizations through consensus mechanisms and data availability sampling. Once data is included in a final block, it is reliably available and does not need to be reorganized. **Data Availability Problem** For full nodes to produce proofs, they must download and execute all transactions. However, if a block producer withholds some of the transactions used to build a block—a tactic known as a "data withholding attack"—there will be problems. Full nodes will notice this attack, but lightweight nodes will not and will unintentionally fork away from full nodes. The only way to confirm the absence of a transaction is to download all transactions. But lightweight nodes, limited by their resources, cannot do this, leading to centralization. **Data Availability Sampling** ![](https://storage.googleapis.com/papyrus_images/bd7753570120e70d3726ba9291c4ecb05facbadf29e9e3365ababc59dffbff23.webp) Celestia has found a solution to this problem through a process called Data Availability Sampling. While we won’t go into the details of Celestia’s implementation here, Data Availability Sampling is a mechanism that allows light nodes to verify data without downloading the entire block data. Light nodes perform multiple rounds of randomly sampling small portions of the block data. As they complete more rounds of sampling, their confidence in the data’s availability increases, until a specified threshold is reached. Once that threshold is reached, that block data is considered available. The more light nodes that participate in sampling, the more data the network can process, increasing the block size without increasing the cost of chain verification. **Builder Flexibility and Ease of Rollup Deployment** ===================================================== ![](https://storage.googleapis.com/papyrus_images/8380bc152043bdfc0333fbd71249a22c2cdd78732e3882d9253fc1e4e892d76e.jpg) When builders deploy to a monolithic blockchain, they are limited to the rules and settings of that blockchain with little flexibility. With Celestia, builders building rollups have much more flexibility in their execution settings. This can foster creativity, optimizing execution for a variety of applications. We can see builders experimenting with different emerging VMs and potentially creating a competitive market for VM research on scalable execution. Another issue that has been pointed out with monolithic blockchains is the cost of bootstrapping a secure validator. Tools like [Rollkit](https://rollkit.dev/reference/about#why-rollkit) help builders deploy rollups on Celestia in record time while also letting these rollups inherit security from the data availability layer by publishing blocks to it. --- *Originally published on [Content Hub - LuckyResearch Labs](https://paragraph.com/@luckyresearch/rollups-are-sovereign-chains)*