Celestia researchers analyze 6 types of Rollup variants: Sequencer = Aggregator + Header Generator

Author: NashQ, Celestia Researcher
Original Title: Redefining Sequencers: Understanding the Aggregator and the Header Producer
Compiler: Faust, Geek Web3

Translator's Note: In order to make the Rollup model easier to understand and analyze, Celestia researcher NashQ divides the sequencer of Rollup into two logical entities—Aggregator and Header Producer. At the same time, he breaks down the transaction ordering process into three logical steps: inclusion, ordering, and execution.

Guided by this analytical approach, the six major variants of sovereign Rollup become clearer and more comprehensible. NashQ discusses the anti-censorship and liveness of different Rollup variants in detail and explores the minimum configuration of nodes for each Rollup variant under a trust-minimized state (which refers to the types of nodes that Rollup users must run to achieve a Trustless state).

Although this article analyzes Rollup from the perspective of Celestia, which differs from the Ethereum community's analysis of the Rollup model, it is still extremely worthwhile for Ethereum enthusiasts to read, considering the many interconnections between Ethereum Rollup and Celestia sovereign Rollup, as well as the latter's increasing influence.

What is Rollup?

Rollup is a blockchain that publishes its "transaction data" to another blockchain and inherits its consensus and data availability.

Why do I specifically use the term "transaction data" instead of "block"? This involves the distinction between Rollup blocks and Rollup data; the simplest Rollup only requires Rollup data as in the first variant below.

A Rollup block is a data structure that represents the blockchain ledger at a certain block height. A Rollup block consists of Rollup data and a Rollup header. Among them, Rollup data can be a batch of transactions or a batch of state changes between transactions.

Variant 1: Pessimistic Rollup / Based Rollup

The simplest way to construct a Rollup is to have users publish transactions to another blockchain, which we refer to as the consensus and data availability layer (DA - Layer), which I will abbreviate as DA layer (Translator's Note: similar to what the Ethereum community often refers to as Layer 1).

In the first Rollup variant I will introduce, the nodes of the Rollup network must re-execute the Rollup transactions included in the DA layer to check the final state of the ledger. This is the pessimistic Rollup!

Pessimistic Rollup is a type of Rollup that only supports full nodes, which need to re-execute all transactions included in the Rollup ledger to verify their validity.

But in this case, who acts as the sequencer of the Rollup? In fact, no entity other than the full nodes of the Rollup has executed the transactions included in the Rollup ledger. Generally speaking, the sequencer aggregates transaction data and generates a Rollup header. However, the aforementioned pessimistic Rollup does not have a Rollup header!

For convenience in discussion, we can split the sequencer into two logical entities: Aggregator and Header Producer. To generate a Rollup Header, transactions must first be executed, and the state transition must be completed before calculating the corresponding Header. However, for the aggregator, it can perform the aggregation step without completing the state transition.

Sequencing is the process of "aggregating + creating Rollup Header."

Aggregation is the step of batching transaction data into a batch. A batch generally contains many transactions (Translator's Note: Batch refers to the part of data in the Rollup block excluding the Header).

The Header generation step is the process of creating the Rollup Header. The Rollup Header contains metadata about the Rollup block and at least includes a commitment to the transaction data in that block (Translator's Note: the commitment here refers to the promise of the correctness of the transaction processing results).

From the above perspective, we can see who acts as the components of the Rollup. First, let's look at the Aggregator. The aforementioned pessimistic Rollup does not have a Header generation process; users publish transactions directly to the DA layer, which means that the DA layer network essentially acts as the aggregator.

Thus, pessimistic Rollup is a Rollup variant that delegates the aggregation step to the DA layer, and it has no sequencer. Sometimes this type of Rollup is referred to as "based rollup."

Based Rollup has the same anti-censorship and liveness as the DA layer (liveness measures the speed of system responses to user requests). If users of this type of Rollup want to achieve a trust-minimized (closest to Trustless) state, they must run at least a light node of the DA layer network and a full node of the Rollup network.

Variant 2: Pessimistic Aggregation Using Shared Aggregator

Let’s discuss the pessimistic aggregation using a shared aggregator. This concept was proposed by Evan Forbes in his forum post about shared sequencer design. Its key assumption is that the shared sequencer is the only legitimate way to order transactions. Evan explains the benefits of a shared sequencer:

"In order to achieve a user experience equivalent to Web2, the shared sequencer can provide quickly generated Soft Commitments (not very reliable guarantees). These Soft Commitments provide some assurance about the final transaction order (that is, the promise that the transaction order will not change) and allow the Rollup ledger state update steps to proceed in advance (but the final confirmation has not yet been completed).

Once the Rollup block data is confirmed and published to the Base Layer (referring to the DA layer here), the Rollup ledger state update is finalized."

The above Rollup variant still belongs to the category of pessimistic Rollup because there are only full nodes in this type of Rollup system, with no light nodes. Each Rollup node must execute all transactions to ensure the validity of the ledger state update. Since this type of Rollup has no light nodes, there is no need for a Rollup Header, and thus no need for a Header Producer. (Translator's Note: Generally, a light node of a blockchain does not need to synchronize the complete block, only receiving the block header.)

Since there is no Rollup Header generation step, the shared sequencer in the above Rollup can update the state without executing transactions (the prerequisite for generating the Header) and only includes the process of aggregating transaction data. Therefore, I prefer to refer to it as a shared aggregator.

In this variant, Rollup users in a trust-minimized state need to run at least

DA layer light node + shared aggregator network light node + Rollup full node.

At this point, it is necessary to verify the published aggregator header from the shared aggregator network (this does not refer to the Rollup Header). As mentioned above, the shared aggregator takes on the task of transaction ordering, and it includes a cryptographic commitment in the published aggregator header corresponding to the Batch it published on the DA layer.

In this way, Rollup node operators can confirm that the batch they received from the DA layer was created by the shared aggregator and not by anyone else.

(Because the content included above is relatively obscure, you may want to look at the diagram again)

Inclusion is the process of including transactions in the blockchain.

Ordering refers to the process of arranging transactions in a specific order in the blockchain.

Execution refers to the process of processing transactions in the blockchain and completing state updates.

Since the shared aggregator takes on the tasks of inclusion and ordering, the anti-censorship of the Rollup depends on it.

If we assume Lss is the liveness of the shared aggregator and Lda is the liveness of the DA layer, then the liveness of this Rollup model is L = Lda && Lss. In other words, if either of the two parts has a liveness failure, the Rollup will also have a liveness failure.

For simplicity, I will consider liveness as a boolean value. If the shared aggregator fails, the Rollup cannot continue to operate. If the DA layer network fails, the shared aggregator can still provide Soft Commitments for the Rollup block. However, at this point, the properties of the Rollup will entirely depend on the shared aggregator network, which often has far inferior properties compared to the original DA layer.

Let’s continue to explore the anti-censorship of the above Rollup scheme:

In this scheme, the DA layer cannot censor certain specific transactions (Translator's Note: transaction censorship often involves refusing to allow certain transactions to be included on-chain); it can only conduct transaction censorship on the entire batch of transactions submitted by the shared aggregator (refusing to allow a certain batch to be included in the DA layer).

However, according to the workflow of Rollup, the shared aggregator has already completed the transaction ordering when submitting the transaction batch to the DA layer, and the order between different batches has also been determined. Therefore, this type of transaction censorship by the DA layer serves no purpose other than delaying the finality confirmation of the Rollup ledger.

In summary, I believe the key to anti-censorship is to ensure that no single entity can control or manipulate the flow of information within the system, while liveness involves maintaining the functionality and availability of the system, even in the presence of network interruptions and adversarial actions. Although this conflicts with the current mainstream academic definitions, I will still use the concepts I have articulated.

Variant 3: Pessimistic Rollup Based on Based Rollup and Shared Aggregator

Although the shared aggregator brings benefits to users and the community, we should still avoid over-reliance on it and allow users to withdraw from the shared aggregator to the DA layer. We can combine the two previously introduced Rollup variants, allowing users to submit transactions directly to the DA layer while using a shared aggregator.

We assume that the final Rollup transaction sequence depends on the transaction sequence submitted by the shared aggregator and the Rollup transactions directly submitted by users in the DA layer block. We will refer to this as the Rollup's fork choice rule.

Aggregation is divided into two steps here. First, the shared aggregator plays a role in aggregating some transactions. Then, the DA layer can aggregate the batch submitted by the shared aggregator with the transactions directly submitted by users.

The anti-censorship analysis at this point becomes more complex. DA layer network nodes may censor the batch submitted by the shared aggregator before the next DA layer block is produced. Knowing the transaction data within the batch, DA layer nodes can extract MEV value, initiate front-running transactions using their accounts on the Rollup network, and include them in the DA layer block before including the batch submitted by the Rollup shared aggregator.

Clearly, the soft commitment guarantee of transaction order finality in the third type of Rollup variant is weaker than that of the second type of Rollup variant mentioned earlier. In this case, the shared aggregator hands over the MEV value to the DA layer nodes. I suggest readers watch research lectures on exploiting profitable censorship MEV.

Some design proposals have emerged to reduce the ability of DA layer network nodes to execute such MEV transactions, such as the "reorganization window" feature, which delays the execution of transactions directly submitted by Rollup network users to the DA layer. Sovereign Labs details this in its design proposal titled Based Sequencing with Soft Confirmations, which introduces the concept of "preferred sequencer."

Since the MEV issue depends on the aggregator scheme chosen by the Rollup and the Rollup fork choice rule, some schemes will not leak MEV to the DA layer, while others will leak part or all of the MEV to the DA layer, but that is another topic.

As for liveness, this Rollup scheme is more advantageous than the one that only allows the shared aggregator to submit transactions to the DA layer. If the shared aggregator experiences a liveness failure, users can still submit transactions to the DA layer.

Finally, let’s talk about the minimum configuration for Rollup users under trust minimization:

At least run DA layer light node + shared aggregator light node + Rollup full node.

At this point, it is still necessary to verify the aggregator header published by the shared aggregator, allowing the Rollup full node to distinguish transaction batches according to the fork choice rule.

Variant 4: Optimistic Based Rollup and Centralized Header Producer

Let’s discuss a variant known as Based Optimistic Rollup and a centralized Header producer. This scheme uses the DA layer to aggregate Rollup transactions but introduces a centralized Header producer to generate the Rollup Header, enabling Rollup light nodes.

Rollup light nodes can indirectly check the validity of Rollup transactions through single-round fraud proofs. Light nodes will have an optimistic attitude towards the Rollup Header generator and will perform final confirmation after the fraud proof window period ends. Another possibility is that it receives fraud proofs from honest full nodes, learning that the Header generator submitted erroneous data.

I do not intend to detail how single-round fraud proofs work here, as it is beyond the scope of this article. The benefit of single-round fraud proofs is that they can shorten the fraud proof window period from 7 days to a certain extent, with the specific value to be determined, but the order of magnitude is smaller than that of traditional optimistic Rollups. Light nodes can obtain fraud proofs through a P2P network composed of Rollup full nodes, without waiting for subsequent dispute processes, as all criteria are fully provided in a single fraud proof.

The above Rollup model uses the DA layer as an aggregator and inherits its anti-censorship properties. At this point, the DA layer is responsible for including and ordering transactions. The centralized Header producer will read the Rollup transaction sequence from the DA layer and construct the corresponding Rollup Header based on that. The Header producer will publish the Header and Stateroot to the DA layer. These Stateroots are necessary for creating fraud proofs. In short, the aggregator is responsible for including and ordering transactions, while the Header producer executes transactions to update the state and obtain Stateroot.

Assuming the DA layer (which also acts as the aggregator of the Rollup) is sufficiently decentralized and has good anti-censorship properties. Moreover, the Header producer cannot change the Rollup transaction sequence published by the aggregator. Now, if the Header producer is decentralized, the only benefit brought is better liveness, but the other properties of the Rollup remain the same as the first variant Based Rollup.

If the Header producer experiences a liveness failure, the Rollup will also experience a liveness failure. Light nodes will not be able to keep up with the progress of the Rollup ledger, but full nodes can. At this point, the Rollup described in Variant 4 degenerates into the Based Rollup described in Variant 1. Clearly, the minimum configuration for trust minimization described in Variant 4 is:

DA layer light node + Rollup light node.

Variant 5: Based ZK-Rollup and Decentralized Prover Market

We have discussed pessimistic Rollup (Based Rollup) and optimistic Rollup; now it is time to consider ZK-Rollup. Recently, Toghrul gave a talk on the separation of the aggregator (Sequencer) and Header producer (Prover) (Sequencer-Prover Separation in Zero-Knowledge Rollups). In this model, it is easier to handle transactions as Rollup data rather than State Diff, so I will focus on discussing the former. Variant 5 is a decentralized Prover Market based on zk-rollup.

So far, you should be relatively familiar with how Rollup works. Variant 5 delegates the role of the aggregator to DA layer nodes, which perform the work of including and ordering transactions. I will quote Sovereign-Labs' documentation, which provides a good explanation of the lifecycle of a transaction in Variant 5:

Users publish a new data block to the L1 chain (DA layer). Once these data blocks are finalized on the L1 chain, they logically possess finality (irreversibility). Once the blocks of the L1 chain enter the finalization phase (that is, non-reversible), the Rollup full nodes will scan these blocks, process all Rollup-related data blocks in order, and generate the latest Rollup state root Stateroot. At this point, from the perspective of the Rollup full nodes, these data blocks have completed finalization.

In this model, the Header producer is served by a decentralized Prover Market.

Prover nodes (full nodes running within the ZK VM) have a work process similar to ordinary Rollup full nodes—scanning the DA layer blockchain and processing all Rollup transaction batches in order—generating the corresponding zero-knowledge proofs and publishing them to the DA layer chain. (If the Rollup system wants to incentivize Prover nodes, it must ensure that the latter sends the generated ZK proofs to the DA layer chain; otherwise, it cannot determine which Prover submitted the ZK proof first.) Once a ZK proof corresponding to a transaction batch is published on the chain, that transaction batch is considered finalized in the eyes of all Rollup nodes (including light nodes).

(Because there are many concepts involved, you may want to look at the diagram again)

Variant 5 has the same anti-censorship properties as the DA layer. The decentralized Prover Market cannot censor Rollup transactions because the standard transaction order has already been established on the DA layer; it is only decentralized to obtain better liveness and create an incentive market for the Header producer (referring to Prover here).

Here, liveness is L = Lda && Lpm (liveness of Prover). If the incentives of the Prover Market are inconsistent or there is a liveness failure, Rollup light nodes will not be able to synchronize the blockchain progress, but Rollup full nodes can. For full nodes, this merely reverts to the Based Rollup/Pessimistic Rollup described in Variant 1. The minimum configuration for trust minimization here is the same as in the optimistic Rollup case, namely:

DA layer light node + Rollup light node.

Variant 6: Hybrid Based Rollup + Centralized Optimistic Header Producer + Decentralized Prover

We still let DA layer nodes act as the aggregator for the Rollup and delegate the work of including and ordering transactions to it.

As you can see from the diagram below, both ZK Rollup and optimistic Rollup use the same ordered transaction batches on the DA layer as the source of the Rollup ledger. This is why we can use two proof systems simultaneously: the ordered transaction batches on the DA layer are not affected by the proof system.

First, let’s talk about finality. From the perspective of Rollup full nodes, when the DA layer's own blocks are finalized, the Rollup transaction batches they contain are also finalized and unchangeable. However, we are more concerned about finality from the perspective of light nodes. Suppose the centralized Header producer has staked some assets and signed the generated Rollup Header, along with submitting the calculated Stateroot to the DA layer.

Similar to Variant 4, light nodes will optimistically trust the Header producer, believing that the Header it publishes is correct, and will wait for fraud proofs from the full node network. If the fraud proof window period ends and the full node network has not published fraud proofs, from the perspective of the Rollup light nodes, the Rollup block is considered finalized.

The key point is that if we can obtain a ZK proof, we no longer need to wait for the fraud proof window to end. In addition to single-round fraud proofs, we can replace fraud proofs with ZK proofs and discard erroneous Headers generated by malicious Header producers!

When light nodes receive the ZK proof corresponding to a Rollup transaction batch, that batch will be finalized.

Now we have fast Soft Commitments and rapid finality.

Variant 6 still possesses anti-censorship properties equivalent to the DA layer, because it is based on the DA layer. For liveness, we will have L = Lda && (Lop || L_pm), which means we have increased liveness guarantees. If either the centralized Header producer or the decentralized Prover Market experiences a liveness failure, we can revert to the other scheme.

In this variant, the minimum configuration for trust minimization is:

One DA layer light node + one Rollup light node.

Summary:

1. We split the key role of Rollup—the sequencer—into two logical components:

Aggregator and Header Producer.

2. We divide the work of the Sequencer into three logical processes: inclusion, ordering, and execution.

3. Pessimistic Rollup and Based Rollup are the same thing.

4. Depending on the needs, you can choose different aggregator and Header producer schemes.

5. Each Rollup variant introduced in this article follows the same design pattern:

Finally, I have some thoughts. Please consider:

How can classic Rollup (referring to Ethereum Rollup) be classified into the above variants?

In all variants, we only let the aggregator be responsible for inclusion + ordering, while the Header producer executes transactions. What if the aggregator is only responsible for including transactions, and the Header producer is responsible for ordering and executing transactions? Considering the introduction of on-chain auction steps, can we completely separate these three steps?

What is a shared Header producer/Header Producer Market?

Who captures the MEV value? Can users reclaim it?