Most applications will be deployed on rollup, and they use Celestia as the consensus layer and data availability layer. As the first two-layer solution to increase transaction capacity, rollup will be the home for most blockchain applications, whether they use Celestia, Ethereum, or other platforms for the consensus layer and data availability layer.
In this article, we will discuss what rollups are, how they currently work on Ethereum, and how they will work on Celestia.
For the existing rollup of the ether chain, the ether chain is the upper settlement layer, and the ether chain rollup is exactly like the ‘baby chain’ of the ether chain, because the correct rollup chain is defined by the contract on the ether chain. In contrast, the Polkadot parachain model is the same, and the relay chain is also the settlement layer above the parachain.
For Celestia, on the other hand, we recognize a new type of rollup: a sovereign rollup chain. They are independent, and they have the right to define their own correctness as the subnet itself, just like an independent layer chain, and can connect to other chains or settlement layers through trusted or trustless bridges.
Table of contents:
- What is a rollup?
- A rollup on the Ethereum chain (the settlement layer above)
- rollup (sovereign) on Celestia
- Sovereign cross-rollup communications
- Why do we need sovereignty?
What is a rollup?
A rollup is a blockchain that sends their blocks to another chain, and inherits the consensus and data availability of the other chain (that chain is therefore called the ‘consensus layer and data availability layer’).
A typical rollup is jointly maintained by three parties: the orderer, the full node of the rollup, and the light node of the rollup. All rollups have their own state, such as the user’s account address and token balance at a certain point in time.
Sorter: It is a node that collects the transactions sent by the users of the rollup, packages the transactions into blocks, and publishes the blocks to the consensus layer and the data availability layer. A block consists of two parts: the block header and the actual transaction data. Block headers include, but are not limited to, the chain’s cryptographic state confirmation – usually a Merkle tree.
Rollup’s full node: it downloads all the block headers and transaction data of the rollup, processes and verifies all the transactions, calculates the status of the rollup, and verifies the validity of all the transactions. If a full node finds an invalid transaction in a rollup block, it will reject and ignore the block. In this way, the orderer cannot pack invalid transactions into valid blocks, because other nodes will reject problematic blocks at their own discretion.
Rollup light node: only downloads the block header of the rollup, but does not download or process any transaction information, so it cannot calculate the latest state or verify the validity of the rollup state by itself. Instead, they can get the latest confirmation status through the latest block header of the rollup. They also verify the validity of the transaction indirectly, through things such as fraud proofs or validity proofs.
When the rollup nodes synchronize the data of the rollup chain, they can only be ordered according to the consensus layer and the data availability layer. For each block height, they will accept the first valid rollup block published to the data availability layer – either directly (full nodes) or indirectly (light nodes) to verify validity.
For more details and a technical explanation of rollup, we recommend reading this thread on the Celestia forums.
A rollup on the Ethereum chain (the settlement layer above)
Current rollups on ethereum send their blocks to EVM-based smart contracts, which are called ‘bridge contracts’. This contract effectively implements a rollup light node on the main chain that receives block headers and processes fraud proofs or validity proofs. In this model, there is a high-level, hard-coded bridge to the ethereum main chain that requires only minimal trust.
Through the bridge contract, users can mortgage or redeem assets between the rollup and the execution chain where the bridge is located, in a way that requires only minimal trust. Because with the help of fraud proof or validity proof, the contract will not accept invalid blocks provided by the orderer.
The ether chain acts as the consensus layer and the data availability layer. It is only responsible for recording and determining valid blocks according to the rules defined by the bridge contract. Therefore, rollup full nodes and light nodes (unrelated to smart contracts) regard the light nodes on the ether chain as the fundamental source of trust, which is a typical (correct) rollup chain (Translator’s Note: That is, chain that can achieve final consensus). In this model, we regard the ether chain as the settlement layer that is high above and paired with rollup. At the same time, rollup is like a ‘baby chain’ to the ether chain, rather than an independent chain with autonomy.
rollup (sovereign) on Celestia
On Celestia, sovereign rollups do not need to submit their blocks to smart contracts at all, but instead submit them directly to the chain as raw data. Celestia’s consensus layer and data availability layer do not translate or execute the calculation logic in the rollup block at all, and of course do not need the light node of the rollup that runs on the main chain.
Instead, rollup operates exactly like a one-layer chain: full and light nodes download blocks directly from rollup’s peer-to-peer network. The main difference is that they also verify that the rollup’s block data is included and correctly ordered in Celestia’s data availability layer, in a Merkle proof manner. Therefore, similar to the one-layer chain, the canonical chain is determined by nodes that locally verify fork selection rules and rollup transactions, rather than a high-level, light node on the main chain.
Fraud Proofs and Validity Proofs also work in a similar way to how they work on a one-tier chain. Fraud proofs, through a peer-to-peer network, are propagated directly to nodes. And if it is a proof of validity, it can be included directly in the block header (see, for example, the Mina protocol). Because, when the network is synchronized, the delay of the peer-to-peer network is significantly smaller than the delay of obtaining the fraud proof from the main chain. This means that the challenge period for peer-to-peer networks is likely to be much shorter, and for light nodes, finalizing the chain state will be much faster.
In this model, there is no high-level bridge between the rollup and the settlement layer, because the rollup simply publishes the block directly to the data availability layer, not a contract. This is consistent with the design philosophy of Cosmos, because the Cosmos connector is not high-level for the Cosmos field, but optional, and can be added under the conditions that allow each field to maintain sovereignty and independence. Between rollup and rollup, there may still be some bridges that require minimal trust – we’ll discuss that in the next subsection.
A rollup is sovereign independent if it does not rely on the settlement layer above it to choose forks and validate transactions. Further, a rollup’s canonical chain is determined by the nodes on the rollup’s peer-to-peer network (this network is in the data availability layer, which also ensures that blocks are available). This means that it is impossible for the settlement layer to impose a transaction on a rollup.
‘There is no need for a high-level settlement layer’, which is more of a public choice than technology-based, which means that there is a public agreement among the rollup communities, which requires the verification rules of rollup transactions to be determined by the community, not a Immutable one-layer contracts. In practice, this means that the bridge to the rollup, which cannot be elevated, must be mutable so that there is a way to upgrade so that a hard fork on a sovereign rollup can be confirmed (discussed in detail in the next section) .
Therefore, this means that the community of rollup can update the chain through a hard fork without causing the settlement layer or data availability layer, or a layer of on-chain supervision, to destroy the minimum trust nature of the chain. This is important for natively minted assets on a sovereign rollup without requiring all assets to be transferred from other chains.
A sovereign rollup could also just use the ether chain as a data availability layer instead of a high-level settlement layer, but this would be more troublesome than using a ‘pure’ data availability layer such as Celestia. Because the nodes of the rollup need to pay attention to the validity of all transactions on the settlement layer of the ether chain, they can run the nodes of the data availability layer on the ether chain. part).
It is also possible to construct a ‘settlement rollup’ on Celestia, which is also a sovereign rollup. A sovereign rollup can be used as a settlement layer by some non-sovereign independent rollups. However, the sovereignty of this settlement layer is similar to the sovereignty of the Ethereum layer chain, and its community often updates the chain through hard forks with public consensus. Fork implementation update).
Sovereign cross-rollup communications
As mentioned earlier, the rollup on Celestia does not require a high bridge to connect any settlement layer at all. The settlement layer and execution layer of rollup are thus decoupled and modularized. So, how does Celestia’s roullup bridge to other chains? Unrestricted by the high settlement layer, we have a wider space for designing cross-chain bridges. We explore the design space and options below.
Let’s assume that the sovereign rollup chain A wants to bridge to another chain B – presumably also a rollup.
Peer-to-peer settlement vs. on-chain settlement
A and B can directly embed light nodes in each other. For example, both chains run light nodes of A and B. In this way, light nodes can receive corresponding fraud proofs or availability proofs directly through the peer-to-peer network. We call this ‘peer-to-peer settlement’.
There can be bridging contracts on both chains, which allow assets to be staked or redeemed back to either chain (such as through a ‘lock and mint’ mechanism), and be supervised by each other’s orderers and validators who execute transactions (whether directly or indirectly).
On the other hand, light nodes can also be implemented as on-chain smart contracts, and block headers and fraud proofs or zero-knowledge proofs can be submitted to on-chain smart contracts. This is the case with rollups on the ether chain. We call this ‘on-chain settlement’.
Connectors and Centralized Networks vs. Peer-to-Peer Bridging Currently, rollups are expected to connect to a single settlement layer that acts like a settlement connector, such as Ethereum (connectors and centrally located networks). If both A and B are connected to the same connector at the same time, they can transfer assets to each other through the bridge and see the connector as a settlement intermediary.
However, just like IBC, rollups can choose to connect directly to each other and use an intermediary chain of connections (point-to-point bridging).
Dynamic Bridging vs. Static Bridging
Depending on the rollup’s execution environment, chain updates or hard forks may require bridging to the new chain. This is because A and B must mutually support each other’s execution environment so that each other’s fraud proofs or zero-knowledge proofs can work.
Let’s assume that the state machine of an optimistic rollup chain A is written directly in Golang (eg, using the Cosmos SDK), rather than a smart contract environment such as EVM or CosmosWasm. In order to bridge to link B, B needs to update the software on their nodes to include A’s state machine in the form of a library of functions in order to verify A’s fraud proofs. This is because B cannot automatically add A’s state machine opcodes, as these could be malicious or non-deterministic, which would be a security risk. Therefore, public consensus or oversight of these bridges is necessary. This is similar to the case where an efficient rollup constructed with zero-knowledge proofs cannot be understood by B. We call this ‘static bridging’ because the bridge must be added in the clear when the chain is updated. Such bridges can be implemented as IBC light nodes.
On the other hand, if an optimistic rollup chain A is written in a sandbox smart contract environment such as EVM or CosmWasm, then chain B can allow A’s state machine opcodes to be added directly to B’s state machine, while No need for public consensus or oversight, such as through a smart contract. In contrast, if A is a zero-knowledge proof rollup, it can be dynamically bridged to B, as long as B is compatible with understanding A’s zero-knowledge proof. we call it ‘dynamic bridging’
A non-superior settlement layer vs. a superlative settlement layer If a rollup chain publishes its blocks and proofs to a settlement layer that works like a connector, like the Ethereum chain. We say that this settlement layer is ‘overall’ if the canonical chain and its transaction validation are determined by the settlement layer.
On the other hand, if a rollup publishes its blocks and proofs to the settlement layer, but the canonical chain of the rollup is entirely determined by the rollup’s own network, we say that the settlement layer is ‘not superior’. In order for a non-superior SL to make sense, there needs to be some way to update the rollup without requiring a SL hard fork.
Committee-Based Bridge vs. Proof-Based Bridge
In order for a bridge between two rollups to require minimal trust, the rollup chains must mutually verify fraud proofs or zero-knowledge proofs. This means that they must be able to understand each other’s state machine (‘proof-based bridge’).
However, ‘committee-based bridges’ also exist (such as the current IBC bridge). Rather than relying on state validity proofs, these bridges rely on a committee to validate blocks. Such bridges are not trust-minimum because of the potential for asset theft for members. However, the complexity of such bridges may be lower, because the chain on which the bridge is deployed does not need, like the source chain, to handle fraud proofs or zero-knowledge proofs.
Upgradable Bridge vs. Non-Upgradable Bridge
The current rollup on the Ethereum chain actually requires that the rollup cannot be multisig or committee upgrades, because if they can, they are not the least trusted ones, and assets can be stolen during the upgrade process. In this model, the rollup can only be upgraded through a hard fork of a chain, because the canonical chain is determined by a settlement layer, which means that the rollup has no sovereignty.
To make a sovereign rollup practical, there should be some way of upgrading to confirm the rollup’s sovereignty, rather than using a high-level settlement layer. To achieve this, there are several ways to consider, based on whether the bridge is minimal trust. Suppose that chain A is about to hard fork, and chain B needs to upgrade the light node of A on it.
For static bridges, B also needs a hard fork. This upgrade path means that the bridge is trust-minimum, since no multi-signature or committee involvement is required.
For dynamic bridges, a committee controlled by chain A (such as the DAO) can update light nodes on B. This requires the bridge to be trusted.
For dynamic bridges, a committee controlled by chain B (such as the DAO) can update the light nodes on B. If B is the settlement layer, this brings an upgrade burden to the settlement layer, which may be expected, if the settlement layer has professional regulatory needs, or has high financial security needs. This also requires the bridge to be trusted.
Why do we need sovereignty?
At its core, rollups are simple blockchains, and rollup bridges are simple light nodes for these blockchains. The goal of the rollup currently driven by the ether chain is a rollup that cannot be upgraded, and at the same time has a high settlement layer. This is equivalent to running a blockchain node that can never be upgraded. Its blocks are only valid when accepted by the light nodes of the rollup. As we said above, this is only a tiny subset of the rollup design space.
At Celestia’s lab, we’re more interested in sovereign rollups that don’t require a high-level settlement layer. Because we believe the most important layer in a blockchain is public consensus. In fact, blockchain is a tool that allows communities to achieve collective leadership based on sovereignty, without being held back by the status quo. This means that a hard fork is a feature, not a bug, because a hard fork strengthens the ability of a sovereign community to achieve public consensus. This is especially important in the case of a problem with a public resource, such as when the Ethereum chain forks due to the destruction of the DAO.
Sovereign rollups will be a powerful way for sovereign communities to leverage the community’s computing facilities to track and enforce socioeconomic values and protocols without the need to initiate and maintain their own consensus layers and validator sets , pay extra. And there is no need to belong to a superior settlement layer in public consensus, no matter whether this settlement layer is suitable for you or not.
Sovereign rollups provide developers with greater flexibility in the execution environment because they are not limited to a certain high-level settlement layer that needs to handle fraud proofs or zero-knowledge proofs for their rollups. Especially in many cases, these settlement layers cannot handle certain fraud proofs and zero-knowledge proofs conveniently and efficiently.
Stay tuned for our follow-up articles where we’ll cite further examples of why sovereignty is particularly important to blockchains.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/rollup-will-be-the-sovereign-chain/
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.