Celestia Researcher Interpreting 4 New Rollup Solutions

Celestia Researcher Interprets 4 New Rollup Solutions

Original author: NashQ, Celestia

Translation: Link, “Geek Web3”

Introduction: This article is a compilation of scattered speeches by Celestia researcher NashQ on the analysis of the Rollup model, including four new variants of Rollup. Previously, in the article “Analyzing Rollup from Celestia’s Perspective: Review Resistance and Liveness of Six Variants,” he listed six different Rollup models, and this article is based on those models to abstract four classes of Rollup models.

Previously, NashQ divided the Sequencer into two modules: Aggregator and Header Producer. Starting from the lifecycle of transaction instructions, he explained the operation principle of Celestia’s sovereign Rollup, discussed the anti-review resistance and liveness of different Rollup variants, and the minimum configuration of users under the premise of minimizing trust (that is, which types of nodes Rollup users need to run at least to achieve Trustless).

• Losses of over $50 million A comprehensive analysis of the cascade attack event caused by the programming language Vyper malfunction.
• Arthur Hayes In the future, humans will collaborate with AI through DAO.
• Opinion Block space is a commodity, and the growth trajectory of blockchain networks is similar to that of telecommunications networks.

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

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

Assuming there are three HPs, they compete with each other and follow the MEV distribution protocol called “highest Protocol MEV”. This protocol was proposed by the Skip Protocol in the Cosmos ecosystem. Unlike the Ethereum PBS solution, the Block Builder needs to pay an additional “tip” to the blockchain network validator, and blocks built by the Builder with the highest tip will be adopted by the validators. At the same time, the SKIP Protocol proposes the concept of “sovereign MEV”, intending to give all validators and communities in the public chain network the autonomy of MEV distribution, solving the problem of increasing centralization of builders in the Ethereum PBS due to the flywheel effect (but this is not the core issue discussed in this article).

In the Rollup variant introduced in this article, different Header Producers need to declare the amount of tips in the Batch Header they create. The Batch Header published by the HP with the highest tip will be automatically accepted by the Rollup nodes (automatically completed through the ledger fork selection algorithm written in the node code).

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

If there are errors in the Header published by the HP, such as incorrect transaction execution results (Stateroot) or missing transactions in the Batch (lost transactions), honest Rollup full nodes will broadcast Fraud proofs to lightweight nodes. However, in general (in optimistic cases), lightweight nodes can accept the Header published by the HP and trust that it is correct.

Censorship Resistance Analysis: There are two points in this Rollup where transactions can be censored. The first point is in the DA layer, where transactions can be inspected and certain users’ transactions can be rejected. The second point is also in the DA layer, where the Header submitted by the HP can be inspected and certain Headers can be rejected, allowing it to collude with the Header and monopolize MEV through censorship attacks.

In addition, transaction ordering is controlled by the HP. Due to the existence of fraud proofs (which can be used against the HP for dropping transactions), the HP itself is unlikely to engage in censorship attacks, but it can bribe DA layer nodes to do so (or run its own DA layer nodes). The solution to this is to extend the window period during which the Rollup transaction sequence is finalized, so that Headers rejected by malicious DA layer nodes can be included on-chain by honest DA layer nodes before the window period ends, thereby increasing the difficulty of DA layer node censorship attacks.

Liveness: L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

If there is a liveness failure in the DA layer, the Rollup will also experience a liveness failure. Furthermore, the Rollup will only experience a liveness failure when all HPs experience a liveness failure.

Variation 8: Shared Aggregator + Decentralized Prover ZK Rollup

Variation 8 uses a Shared Aggregator (SA) for transaction inclusion and ordering. The SA publishes the transaction sequence Batch to the DA layer, and once the transaction sequence is sent to the DA layer, the transaction order theoretically does not change.

However, 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. At this time, the Batch that has not yet been included in the DA layer is still unstable and can be replaced at any time.

It should be noted 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 Batch from the DA layer (or synchronizes directly with the Shared Aggregator), generates a ZK Proof+Batch Header, and publishes it to the DA layer. Clearly, the Prover plays the role of the HP.

For the light nodes of the Rollup, once they receive the ZK Proof, the transaction sequence contained in this Batch is finally confirmed. Of course, the Prover can also broadcast the ZKP through the Rollup p2p network off-chain, allowing it to be received by light nodes faster, but at this time the ZKP has not 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, but can only conduct censorship attacks on the entire batch of transactions submitted by the shared aggregator. At the same time, the shared aggregator can refuse to include transactions from certain users.
• Liveliness: L = L_da && L_sa && L_pm. In this variant, if any component experiences liveliness failure, the Rollup will also experience liveliness failure. If the Prover fails, the light nodes will not be able to effectively synchronize the Rollup’s ledger progress. However, since the full nodes synchronize all transaction sequences in batches, they can keep up with the ledger progress. In this case, full nodes are unaffected and all light nodes become ineffective, which is equivalent to the scenario described earlier with the use of a shared aggregator in Based Rollup.
• Trust-minimized Minimum Configuration: DA layer light nodes + shared aggregator network light nodes + Rollup light nodes.

Variant 9: Shared Aggregator + Decentralized Prover + ZK-Rollup with Multiple DAs

Variant 9 is actually an extension of Variant 8 mentioned above, but with multiple DA layers. This can effectively improve the liveliness of the Rollup. In Variant 9, the shared aggregator SA can publish the transaction sequence batch to any DA layer according to its own needs. This allows for dynamic optimization of Rollup’s relevant parameters, such as data cost, security, liveliness, transaction latency, and finality.

Based on the needs of the Rollup project, the cheapest, safest, most active, and fastest settlement speed Rollup can be customized by choosing the DA layer with the highest throughput. Generally speaking, the batch at a certain Rollup block height (e.g., the 10,000th batch) does not need to exist on different DA layers at the same time, 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 means that the shared aggregator deliberately forked the ledger.

Here, we have chosen the same decentralized Prover Market as in Variant 8, where the Prover acts as the Header Producer and publishes Batch Headers and ZKProofs. At this point, the Prover needs to compete using the fee auction mechanism mentioned in Variant 7 (proposed by the SKIP Protocol).

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

Censorship Resistance: The shared aggregator can conduct censorship attacks, but with more optional DA layers, the likelihood of censorship attacks related to the DA layer decreases.

Liveliness: L = (L_da1 || L_da2) && L_sa && L_pm.

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

Trust-minimized Minimum Configuration: Light nodes of different DA layers + light nodes of the shared aggregator network + Rollup light nodes.

Obviously, the more DA layers we use, the more light nodes we need to run. However, the benefits of doing so may outweigh the costs.

Variation 10: Two ZK-Rollups + Decentralized Prover with an On-Chain Light Node (Bridgeable)

Variation 10 is an extension of Variation 5, aiming to create two ZK-Rollups that can bridge with each other. Compared to Variation 5 (Based Rollup + ZKP + Decentralized Prover), Variation 10 adds a relayer role, which wraps the Batch Header + ZK-Proof into a transaction. By sending this transaction to the Rollup1 light node running Rollup2, it can prove the validity of a batch at a certain height. Of course, Rollup2 also needs to run a light node for the DA layer.

This is a prerequisite for minimizing trust in cross-chain bridges. However, if it is a cross-chain from an Ethereum Rollup (SC Rollup based on smart contracts) to Ethereum, there is no need to run a light node for the Rollup’s DA layer, because the DA layer is Ethereum itself. This is very different from Celestia’s sovereign Rollup, where the Rollups must run light nodes for each other’s DA layer.

When the relayer sends a cross-chain transaction, it will be processed by the aggregator 2 and HP2 of Rollup2. We have added both of them to the diagram to understand how the nodes of Rollup2 handle cross-Rollup transactions.

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

We can simplify the model even more. Assuming that the two Rollups use the same shared aggregator and Header Producer, in other words, they share the same DA layer.

In this case, the relayer can be eliminated directly. Because the Batch Header and ZK Proof have already been published to the same DA layer by the HP, the data of the Header and ZKP of the other Rollup can be directly read on the DA layer without being passed to the shared aggregator by the relayer.

Obviously, Rollups that use the same DA layer do not need to rely on a relayer (many cross-chain bridges rely on relays). This can solve the security issue of cross-chain bridges (in this regard, the cross-chain between Ethereum’s SC Rollups is more secure than cross-chain between different public chains).

At this point, the minimum configuration of trust minimization is: DA layer light node + Rollup light node.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!