Celestia researchers analyze Rollup (II): 4 new Rollup solutions

Original Author: NashQ, Celestia

Compiled by: Link, "Geek Web3"

Introduction: This article is a compilation of scattered remarks by Celestia researcher NashQ regarding the analysis of Rollup models, including four new Rollup variants. Previously, in the article "Celestia Researcher Analyzes 6 Rollup Variants: Sequencer = Aggregator + Header Producer," he listed six different Rollup models, and this article presents four new abstracted Rollup models based on that foundation.

Previously, NashQ divided the Sequencer into two main modules: Aggregator + Header Producer. He explained the operational principles of Celestia's sovereign Rollup from the perspective of the transaction instruction lifecycle, discussing the censorship resistance and liveness of different Rollup variants, as well as the minimum configuration for users under the premise of trust minimization (to achieve Trustless, what types of nodes must Rollup users run at a minimum).

Variant 7: Based Rollup + Multiple Header Producers + "Highest Protocol MEV"

In this Rollup variant, Rollup network users directly publish transaction data to the DA layer block, and then the Header Producer is responsible for transaction ordering, with MEV extracted by it. Clearly, the transaction aggregation/inclusion process of Rollup variant 7 is handled by the DA layer (users directly send transactions to the DA layer), similar to the previously introduced Based Rollup, but the transaction ordering differs; the DA layer nodes are not responsible for ordering, which is handled by the HP (Header Producer).

Assuming there are three HPs that compete with each other and adhere to the MEV distribution protocol called "Highest Protocol MEV." This protocol was proposed by the Cosmos ecosystem's Skip Protocol. Unlike Ethereum's PBS scheme, Block Builders need to pay an additional "tip" to the blockchain network Validators; the block built by the Builder that pays the most tips will be accepted by the Validators. At the same time, the SKIP Protocol introduced the concept of "sovereign MEV," aiming to give all Validators and the community of the public chain network autonomy over MEV distribution, addressing the issue of increasing centralization of Builders due to the flywheel effect in Ethereum's PBS (but this is not the core topic of this article).

In the Rollup variant introduced in this article, different Header Producers need to declare the tip amount in the Batch Header they create, and the Batch Header published by the HP that pays the most tips is automatically accepted by the Rollup nodes (completed automatically through the ledger fork selection algorithm coded into the node).

Additionally, the Batch Header published by the HP must correspond to the complete transaction batch on the DA layer.

If the Header published by the HP contains errors, such as an incorrect transaction execution result Stateroot, or fails to include a transaction from the Batch (lost transaction), honest Rollup full nodes will broadcast a Fraud Proof to light nodes. However, usually (in an optimistic scenario), light nodes can accept the Header published by the HP and trust that it is correct.

Censorship Resistance Analysis: This Rollup has two points where transaction censorship can occur. The first point exists in the DA layer, which can censor transaction content and refuse to include transactions from certain users. The second point also exists in the DA layer, which can censor the Header submitted by the HP and refuse to include a certain Header, thus colluding with the Header to monopolize MEV through censorship attacks.

At the same time, since transaction ordering is handled by the HP, and due to the existence of fraud proofs (which can address the situation where the HP loses transactions), the HP itself often will not engage in censorship attacks, but it can bribe nodes in the DA layer to do so (or run some nodes in the DA layer itself). The solution to this is to extend the window period during which the Rollup transaction sequence is finalized, allowing Headers rejected by malicious DA layer nodes to be included on-chain by honest DA layer nodes before the window period ends, thereby increasing the difficulty of censorship attacks by DA layer nodes.

Liveness: L = Lda && (Lhp1 || Lhp2 || Lhp3)

If the DA layer experiences a liveness failure, the Rollup will also experience a liveness failure. On this basis, the Rollup will only experience a liveness failure if all HPs experience liveness failures.

Variant 8: Shared Aggregator + Decentralized Prover's ZK Rollup

Variant 8 uses a Shared Aggregator (SA) for transaction inclusion + ordering, with the SA publishing the transaction sequence Batch to the DA layer. Once the transaction sequence is sent to the DA layer, the transaction order theoretically no longer changes.

Before the Batch is sent to the DA layer, the Shared Aggregator SA can first broadcast the Batch + SA Header to full nodes and Provers and broadcast the SA Header to light nodes; however, at this time, the Batch not yet on the DA layer is still unstable and may be replaced at any time.

It is important to note that the Header published by the Shared Aggregator SA is not the same as the Batch Header published by the HP. The SA Header contains cryptographic proofs to ensure that the Batch read by Rollup nodes from the DA layer is indeed generated by the SA and not forged by others.

The Prover reads the transaction batch from the DA layer (or can synchronize directly with the Shared Aggregator), generates a ZK Proof + Batch Header, and publishes it to the DA layer. Clearly, the Prover acts as the HP.

For light nodes in the Rollup, upon receiving the ZKP proof, the transaction sequence contained in this Batch is considered finally confirmed. Of course, the Prover can also broadcast the ZKP through the off-chain Rollup p2p network to make it received faster by light nodes, but at this time, the ZKP has not yet been sent to the DA layer and does not possess "finality."

Censorship Resistance: In Variant 8, the DA layer cannot conduct censorship attacks on specific transactions; it can only conduct censorship attacks on the entire transaction batch Batch submitted by the Shared Aggregator. At the same time, the Shared Aggregator can refuse to package transactions from certain users.

Liveness: L = Lda && Lsa && L_pm. In this variant, if any part experiences a liveness failure, the Rollup will also experience a liveness failure. If the Prover fails, then light nodes will not be able to effectively synchronize the Rollup ledger progress. However, since full nodes have synchronized all transaction sequences Batch, they can keep up with the ledger progress. At this time, full nodes are unaffected, while all light nodes fail, which is equivalent to the situation previously described using a Shared Aggregator in Based Rollup.

Minimum Configuration for Trust Minimization: DA layer light nodes + Shared Aggregator network light nodes + Rollup light nodes

Variant 9: Shared Aggregator + Decentralized Prover + Multiple DA ZK-Rollups

Variant 9 is essentially an expansion of the above Variant 8, with the difference that there is more than one DA layer, which can effectively improve the liveness of the Rollup. In Variant 9, the Shared Aggregator SA can publish the transaction sequence Batch to any DA layer, allowing it to choose different DA layers to publish data based on its needs, thus dynamically optimizing relevant parameters of the Rollup, such as: data cost, security, liveness, transaction latency, and finality.

According to the needs of the Rollup project party, it can customize the cheapest, safest, most active, and fastest settling Rollup, selecting the DA layer with the highest throughput. Generally, a Batch at a certain Rollup block height (e.g., the 10,000th) does not need to exist simultaneously across different DA layers, but if it does, their contents must be consistent. If two Batches with the same height but different contents appear on different DA layers, it indicates that the Shared Aggregator is intentionally causing ledger forks.

Here, we use the same decentralized Prover Market as in Variant 8, with the Prover acting as the Header Producer and publishing Batch Header and ZK Proof. At this time, the Prover needs to compete through the tip auction mechanism mentioned in Variant 7 (proposed by the SKIP Protocol).

The transaction settlement speed (final confirmation speed) of Variant 9 is influenced by the fastest DA layer it adopts.

Censorship Resistance: The Shared Aggregator can conduct censorship attacks, but with more optional DA layers, the possibility of censorship attacks related to the DA layer decreases.

Liveness: L = (Lda1 || Lda2) && Lsa && Lpm.

Compared to previous variants, Variant 9 has stronger liveness. As long as not all DA layer networks experience liveness failures, everything can proceed normally.

Minimum Configuration for Trust Minimization: Light nodes from different DA layers + Shared Aggregator network light nodes + Rollup light nodes.

Clearly, the more DA layers we adopt, the more light nodes we must run. However, the benefits of doing so may outweigh the costs.

Variant 10: Two ZK-Rollups + Decentralized Prover, with an On-Chain Light Node (Bridgeable) Between Them

Variant 10 is an extension of Variant 5, aimed at creating two ZK-Rollups that can bridge with each other. Compared to Variant 5 (Based Rollup + ZK P + Decentralized Prover), Variant 10 adds a Relayer role, which packages the Batch Header + ZK Proof into a single transaction. As long as this transaction is sent to the light nodes of Rollup 1 running Rollup 2, it can prove that a Batch at a certain height is valid. Of course, Rollup 2 also needs to run light nodes of the DA layer.

This is a prerequisite for maintaining trust minimization in cross-chain bridges. However, if it is a cross-chain from Ethereum Rollup (based on smart contracts SC Rollup) to Ethereum, there is no need to run the DA layer light nodes of the Rollup, as the DA layer is Ethereum itself. This is very different from Celestia's sovereign Rollup, where Rollups must run the light nodes of each other's DA layers when bridging.

When the Relayer sends a cross-chain transaction, it will be processed by the Aggregator 2 and HP 2 of Rollup 2. We add both to the diagram to understand how the nodes of Rollup 2 handle cross-Rollup transactions.

The Relayer of Rollup 2 will obtain the Batch Header and ZKP of Rollup 2 and send it back to Rollup 1. Rollup 1 also has a light node for Rollup 2 and a light node for the DA layer.

We can simplify the model further. Assuming both Rollups use the same Shared Aggregator and Header Producer, in other words, they use overlapping DA layers.

In this case, the Relayer can be eliminated. Since the Batch Header and ZK Proof have been published by the HP to the same DA layer, the Header and ZK P data of the other Rollup can be read directly from the DA layer, without needing to be sent through the Relayer to the Shared Aggregator.

Clearly, Rollups using the same DA layer do not need to rely on a Relayer (many cross-chain bridges depend on relay nodes). This can solve the security issues of cross-chain bridges (from this perspective, the cross-chain interactions between Ethereum's SC Rollups are more secure than those between different public chains).

At this point, the minimum configuration for trust minimization: DA layer light nodes + Rollup light nodes.