Celestia Fellows Analyze Rollup (II): 4 New Rollup Solutions

Introduction:This article is consolidated by Celestia researcher NashQ’s scattered statements about Rollup model analysis, including 4 new Rollup variants. Previously, in the article “ Celestia Researcher Analyzes 6 Rollup Variants: Sequencer=Aggregator+Header Generator “, he listed 6 different Rollup models, and this article is a new abstraction of 4 types of Rollup models on the basis of this article.

Previously, NashQ split the sequencer Sequencer into two modules, Aggregator + Header Producer, and cut through the lifecycle of transactional instructions to explain how the Celestia Sovereign Rollup works, exploring the censorship resistance and activity of the different Rollup variants, as well as the minimum configuration for a user to be trust-minimized (that is, to be Trustless, what are the minimum types of nodes a Rollup user should run).

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

In this Rollup variant, the Rollup network user posts the transaction data directly to the DA layer block, and then the Header Producer is responsible for the transaction ordering and the MEV is extracted by it. 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 post their transactions directly to the DA layer), but the transaction sorting is different from Based Rollup in that the DA layer nodes are not in charge of the sorting, which is handled by the HP (Header Producer).

Let’s assume that there are three HPs that are in competition with each other and follow a MEV allocation protocol called “highest Protocol MEV”. This protocol is proposed by the Cosmos eco-system’s Skip Protocol, which differs from the Ether PBS scheme in that Block Builders pay an additional “tip” to the blockchain network’s Validators, and the blocks constructed by the most tipped Builders are adopted by the Validators. The blocks constructed by the most tipped Builders will be adopted by the Validators. At the same time, SKIP Protocol puts forward the concept of “Sovereign MEV”, which intends to let all Validators and the community of the public chain network have the autonomy of MEV allocation, and solve the problem of increasing centralization of builders due to the flywheel effect in Ethernet PBS (but this is not the core of this article). ).

In the Rollup variant presented in this paper, different Header Producers need to declare the tip amount in the Batch Header they create, and the Batch Header posted by the HP that tips the most is automatically accepted by the nodes of Rollup (automatically via a ledger fork selection algorithm written in the node’s code).

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

If there is an error in the Header published by HP, such as the transaction execution result Stateroot is incorrect, or it does not contain a particular transaction in the Batch (lost transaction), the honest Rollup full node broadcasts the fraud proof Fraud proof to the light node.However, usually (optimistically), the light node can accept the Header published by HP and believe that it has no Problems.

Censorship Resistance Analysis: 2 points exist in this Rollup where transaction censorship is possible. The first one exists at the DA layer, where it can review the transaction content and reject the inclusion of certain users’ transactions. The second place is still in the DA layer, it can review the Header submitted by HP and refuse to include a certain Header, so that it can conspire with the Header to monopolize the MEV through censorship attack.

At the same time, the transaction sequencing is handled by HP, and due to the existence of fraud proofs (which can be used against the case of HP dropping transactions), HP itself tends not to launch censorship attacks, but it can bribe DA layer nodes to do so (or run some DA layer nodes itself). The solution to this is to extend the window period during which the Rollup transaction sequence is finalized, so that the Header rejected by the malicious DA layer node can be included in the chain by the honest DA layer node in time before the end of the window period, which in turn increases the difficulty of the DA layer node’s censorship attack.

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

If the DA layer has an active fault, then Rollup will also have an active fault. On this basis, Rollup will have an active fault only if all HPs have an active fault.

Variant 8: ZK Rollup with Shared Aggregator + Decentralized Prover

Variant 8 uses the Shared Aggregator (SA) for transaction inclusion + ordering, where the SA publishes the transaction sequence Batch onto the DA layer, and the transaction order theoretically does not change after the transaction sequence is sent to the DA layer.

And 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 the SA Header to the light node, except that at this time, the Batch that is not 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 thing as the Batch Header published by HP. the SA Header contains cryptographic proofs to ensure that the Batch that the Rollup node reads from the DA layer was indeed generated by the SA, and not forged by it.

Prover reads the transaction batch Batch from the DA layer (and also synchronizes directly to the shared aggregator), generates a ZK Proof+Batch Header, and publishes it to the DA layer. Obviously Prover acts as the HP.

For the light node of Rollup, after receiving ZKProof, the sequence of transactions contained in this Batch will be finalized. Of course, the Prover can also broadcast ZKP through the Rollup p2p network under the DA layer chain, so that it can be received by the light nodes faster, but at this time, ZKP has not yet been sent to the DA layer, and does not have the “finality”.

Censorship resistance: in variant 8, the DA layer cannot perform censorship attacks on some pen-specific transactions, but can only perform Batch censorship attacks on the entire batch of transactions submitted by the shared aggregator. At the same time, the shared aggregator can refuse to package certain users’ transactions.

Active: L = L_da && L_sa && L_pm. any part of this variant fails active then Rollup will fail active. If the Prover fails, then the light node will not be able to synchronize the Rollup ledger progress efficiently. But since the full node synchronizes all the transaction sequence Batch, it can keep up with the book progress. At this time, the full node is unaffected and all light nodes fail, which is equivalent to the previously described case of Based Rollup with shared aggregator.

Minimum configuration for trust minimization: DA tier 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 based on the above variant 8 unfolding, except that 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 the data according to its own needs, so that it can dynamically optimize the relevant parameters of Rollup, such as: data cost, security, activity, transaction delay and finality.

Depending on the needs of the Rollup projector, the cheapest, safest, most active, and fastest settling Rollup can be customized, and the DA layer with the highest throughput can be selected. Generally speaking, Batch of a certain Rollup block height (e.g. 10,000th) does not have to exist on different DA layers at the same time, but if they do, their contents must be the same. If two Batches with the same height and different contents are present on different DA layers, it means that the shared aggregator is intentionally engaging in a ledger fork.

Here, we choose the same decentralized Prover Market as in variant 8, where the Prover acts as Header Producer and publishes the Batch Header and ZKProof. at this point, the 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 fastest DA layer it employs out of blocks.

Censorship resistance: shared aggregators can engage in censorship attacks, but the number of optional DA layers becomes larger, and the likelihood of censorship attacks associated with DA layers decreases.

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

Variant 9 is more active compared to the previous variants. As long as there is not an activity failure in all DA layer networks, everything is able to proceed normally.

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

Obviously, the more DA layers we employ, the more light nodes we must run. But the benefits of this may override its costs.

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

Variant 10 is an extension of Variant 5 with the aim of creating 2 ZK-Rollups that can bridge to each other.Compared to Variant 5 (Based Rollup+ZKP+Decentralized Prover), Variant 10 has the additional role of a repeater Relayer, which wraps the Batch Header+ZK-Proof into a single transaction. Simply sending this transaction to the Rollup1 light node where Rollup2 is running proves that a Batch of a certain height is valid. Of course, Rollup2 also needs to run the light node of the DA layer.

This is a prerequisite to keep cross-chain bridge trust minimized. However, if one is crossing from an Ether Rollup (a smart contract-based SC Rollup) to Ether, there is no need to run the Rollup’s DA-layer light node anymore, as the DA-layer is Ether itself. This is extremely different from Celestia’s Sovereign Rollup, where Rollups must run each other’s DA layer light nodes to cross each other.

When Relayer sends a cross-chain transaction, it is processed by Rollup2’s aggregator 2 and HP2. We add both to the graph to understand how nodes in Rollup2 handle cross-Rollup transactions.

Rollup 2’s repeater Relayer will get Rollup 2’s Batch Header and ZKP 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 make the model more simplified. Suppose two Rollups use the same Shared Aggregator and Header Producer, in other words, they employ overlapping DA layers.

In this case, the Relayer can be outlawed directly. Since the Batch Header and ZK Proof have been published by HP to the same DA layer, the data such as 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 via Relayer.

Obviously, Rollups that use the same DA layer do not need to rely on Relayers (many cross-chain bridges rely on relay nodes). This can solve the security problem of cross-chain bridges (from this point of view, inter-spanning between SC Rollups in Ethernet is more secure than inter-spanning between different public chains).

At this point, the minimum configuration for trust minimization: a DA tier light node + a Rollup light node.

Statement:

1. This article is reprinted from [[Geek Web3](https://mp.weixin.qq.com/s/Wi4FPTCZli5g8UGVkYFnlw) ], the copyright belongs to the original author [NashQ, Celestia ], if you have any objections to the reprint, please contact the Gate Learn team, the team will be dealt with according to the relevant process as soon as possible.
2. Disclaimer: The views and opinions expressed in this article represent the author’s personal views and do not constitute any investment advice.
3. Articles in other languages are translated by the Gate Learn team and may not be reproduced, distributed or copied without reference to Gate.io.