Celestia Researcher: Interpretation of 4 New Rollup Schemes

Author: NashQ, Celestia; Compiler: Link, "Geek web3"

Introduction: This article is composed of the scattered speeches of Celestia researcher NashQ on the analysis of the Rollup model, including 4 new Rollup variants. Previously, in the article "Analysis of Rollup from the Perspective of Celestia: Censorship Resistance and Activity of 6 Variations", he listed 6 different Rollup models, and this article is his newly abstracted 4 categories based on this Rollup model.

Previously, NashQ divided the Sequencer into two modules: aggregator + Header Producer. Starting from the life cycle of transaction instructions, it explained the operation principle of Celestia's sovereign Rollup, discussed the anti-censorship and activity of different Rollup variants, and the user experience. The minimum configuration under the premise of minimizing trust (that is, to achieve Trustless, which types of nodes Rollup users must run at least).

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

In this Rollup variant, Rollup network users directly publish transaction data to DA layer blocks, and then Header Producer is responsible for transaction sorting, and MEV is extracted by it. Obviously, the transaction aggregation/inclusion process of Rollup Variant 7 is the same as the previously introduced Based Rollup, which is the responsibility of the DA layer (users directly send transactions to the DA layer), but the transaction ordering is different from the Based Rollup, and the DA layer nodes are not responsible Sorting is the responsibility of HP (Header Producer).

The following assumes that there are three HPs that compete with each other and abide by the MEV allocation protocol named "highest Protocol MEV". This protocol was proposed by the Skip Protocol of the Cosmos ecosystem. Unlike the Ethereum PBS scheme, the Block Builder needs to pay an additional "tip" to the blockchain network Validator, and the block built by the Builder with the most tip will be adopted by the Validators. . At the same time, SKIP Protocol proposed the concept of "sovereign MEV", intending to allow all Validators and communities in the public chain network to have the autonomy to allocate MEV, and to solve the problem that Builders in Ethereum PBS are becoming more and more centralized due to the flywheel effect (but this is not the core of this article).

In the Rollup variant introduced in this article, different Header Producers need to declare the tip amount in the Batch Header created by themselves, and the Batch Header issued by the HP that pays the most tips is automatically accepted by the Rollup nodes (through the ledger written in the node code The fork selection algorithm is done automatically).

In addition, the Batch Header released by HP must be able to correspond to the complete transaction batch Batch on the DA layer.

If there is an error in the Header issued by HP, for example, the transaction execution result Stateroot is incorrect, or a transaction in the batch is not included (lost transaction), the honest Rollup full node will broadcast Fraud proof to the light node. But usually (optimistically), light nodes can accept the Header issued by HP and believe that there is no problem with it.

Resistance to censorship analysis: There are 2 points in this Rollup that can conduct transaction review. The first exists at the DA layer, which can censor transaction content and reject transactions involving certain users. The second place still exists in the DA layer, which can review the header submitted by HP and refuse to include a certain header, so that it can conspire with the header to monopolize MEV through review attacks.

At the same time, HP is responsible for the ordering of transactions. Due to the existence of fraud proofs (it can be targeted at the situation where HP loses transactions), HP itself often does not launch censorship attacks, but it can bribe the nodes of the DA layer to do so (or run some DA layers by itself) node). The solution to this is to extend the window period for the Rollup transaction sequence to be finalized, so that the Header rejected by malicious DA layer nodes can be included in the chain by honest DA layer nodes before the end of the window period, thereby increasing the DA layer node review The difficulty of the attack.

**Activity:**L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

If the DA layer has a liveness failure, the Rollup will also have a liveness failure. Based on this, Rollup will fail liveness only when all HPs fail liveness.

Variant 8: ZK Rollup of Shared Aggregator + Decentralized Prover

Variant 8 uses the shared aggregator Shared Aggregator (SA) for transaction inclusion + sorting. SA publishes the transaction sequence Batch to the DA layer. After the transaction sequence is sent to the DA layer, the transaction order will not change theoretically.

Before the Batch is sent to the DA layer, the shared aggregator SA can first broadcast the Batch+ SA Header to the full node and the Prover, and broadcast the SA Header to the light node, but the Batch that is not on the DA layer is still unstable at this time and may be blocked at any time. replace.

It should be noted that the header issued by the shared aggregator SA is not the same as the batch header issued by HP. The SA Header contains cryptographic proofs to ensure that the Batch read by the Rollup node from the DA layer is indeed generated by SA, not forged by others.

Prover reads the transaction batch Batch from the DA layer (it can also be directly synchronized to the shared aggregator), generates a ZK Proof+Batch Header, and publishes it to the DA layer. Obviously Prover played the role of HP.

For Rollup's light nodes, after receiving ZKProof, the transaction sequence contained in this Batch is finally confirmed. Of course, Prover can also broadcast ZKP through the Rollup p2p network under the DA layer chain, so that it can be received by light nodes faster, but at this time ZKP has not been sent to the DA layer, and it does not have "finality".

• **Resistance to censorship: **In variant 8, the DA layer cannot conduct censorship attacks on certain specific transactions, but can only conduct review attacks on the entire batch of transactions submitted by the shared aggregator. At the same time, shared aggregators can refuse to package certain users' transactions.
• **Activity: **L = L_da && L_sa && L_pm. In this variant, if any part has a liveness failure, the Rollup will have a liveness failure. If the Prover fails, the light nodes will not be able to effectively synchronize the progress of the Rollup ledger. However, since the full node synchronizes all transaction sequence batches, it can keep up with the progress of the ledger. At this time, all nodes will not be affected, and all light nodes will fail, which is equivalent to the situation of Based Rollup using a shared aggregator introduced earlier.
• **Minimum configuration for trust minimization: **DA layer light node + shared aggregator network light node + Rollup light node

Variant 9: Shared aggregator + decentralized Prover + ZK-Rollup with multiple DAs

Variant 9 is actually based on the above variant 8, but it has more than one DA layer, which can effectively improve the activity of Rollup. In Variant 9, the shared aggregator SA can publish the transaction sequence Batch to any DA layer, and it can choose different DA layers to publish data according to its own needs, so that it can dynamically optimize the relevant parameters of Rollup, such as: data cost , security, liveness, transaction latency, and finality.

According to the needs of the Rollup project party, the cheapest, safest, most active, and settlement speed Rollup can be customized, and the DA layer with the highest throughput can be selected. Generally speaking, Batches of a certain Rollup block height (such as the 10,000th) do not need to exist on different DA layers at the same time, but if they exist, their contents must be consistent. If two batches with the same height and different content appear on different DA layers, it means that the shared aggregator intentionally forks the ledger.

Here, we choose the same decentralized Prover Market as Variant 8, where Prover acts as Header Producer and releases Batch Header and ZKProof. At this point, Prover needs to compete through the tip auction mechanism mentioned in Variant 7 (proposed by SKIP Protocol).

The transaction settlement speed (final confirmation speed) of Variant 9 is affected by the DA layer with the fastest block generation.

Resistance to censorship: Shared aggregators can engage in censorship attacks, but with more optional DA layers, the possibility of censorship attacks related to DA layers is reduced.

**活性：**L = ( L_da1 || L_da2) && L_sa && L_pm。

Variant 9 was more active than the previous variant. As long as not all DA-layer networks experience live failures, everything will work fine.

Minimum configuration for trust minimization: light nodes of different DA layers + shared aggregator network light nodes + Rollup light nodes.

Obviously, the more DA layers we adopt, the more light nodes we have to run. But the benefits of doing so may outweigh the costs.

Variant 10: Two ZK-Rollups+decentralized Prover, with an on-chain light node (bridgeable) between each other

Variant 10 is an extension of Variant 5 to create 2 ZK-Rollups that can bridge each other. Compared with Variant 5 (Based Rollup+ZKP+Decentralized Prover), Variant 10 has an additional relayer role, which wraps Batch Header+ZK-Proof into a transaction. As long as this transaction is sent to the Rollup1 light node running on Rollup2, it can prove that a certain height of Batch is valid. Of course, Rollup2 also requires light nodes running the DA layer.

This is a prerequisite for keeping trust across chain bridges to a minimum. But if it is cross-chain from Ethereum Rollup (smart contract-based SC Rollup) to Ethereum, there is no need to run Rollup’s DA layer light node, because the DA layer is Ethereum itself. This is very different from Celestia's sovereign Rollup, whose Rollups span each other and must run the light nodes of the other party's DA layer.

When Relayer sends a cross-chain transaction, it will be processed by Rollup2's Aggregator 2 and HP2. We add both to the graph to understand how Rollup2's nodes process transactions across Rollups.

The Relayer of Rollup2 will get the Batch Header and ZKP of Rollup 2 and send them back to Rollup1. Rollup 1 also has a Rollup 2 light node and a DA layer light node.

We can make the model more simplified. Assume that two Rollups use the same shared aggregator and Header Producer, in other words, the DA layers they use overlap.

In this case, the Relayer can be banned directly. Because the Batch Header and ZK Proof have been published by HP to the same DA layer, data such as the Header and ZKP of another Rollup can be read directly on the DA layer, and no longer need to be passed to the shared aggregator through the Relayer.

Obviously, Rollup using the same DA layer does not need to depend on Relayer (many cross-chain bridges rely on relay nodes). This can solve the security problem of the cross-chain bridge (from this point of view, the cross-span between SC Rollups of Ethereum is more secure than the cross-chain between different public chains).

At this time, **minimum configuration of trust minimization: **DA layer light node + Rollup light node.