Basics of Rollups

Sequencer

The sequencer is a single, semi-privileged party that plays a critical role in rollup systems, specifically in the process of generating transactions. The sequencer is started by the creator of the system and there is only one sequencer at a time within the system.

It can be hosted in a cloud or as a consensus blockchain node. Its primary responsibility is to check the validity of transactions. When a user of the rollup needs to perform a transaction, it is the role of the sequencer to confirm it, update the state, construct L2 blocks and submit to L1.

The presence of a sequencer in an optimistic Ethereum blockchain is mandatory; it is responsible for assigning order to L2 transactions, similar to L1 miners.

The sequencer determines the ordering of transactions in the CanonicalTransactionChain. To do so, the sequencer must process transactions instantly, without delay. This process must follow the constraints imposed by appendSequencerBatch(). Also, the sequencer must add transactions from the CTC queue during the so-called "Force On Period".

The sequencer flow is thus:

• The sequencer receives new transactions from blockchain users.

• It must check, without delay, that the transactions are valid, sort them, and apply them to the local state as a pending block.

• It periodically submits them to the CanonicalTransactionChain contract.

• As a result, a confirmation message is sent to the user, resulting in an orderly execution of L2 transactions. For the end user, this process takes about a few seconds and indicates that the transaction will be included in the next rollup batch. This gives instant confirmation, therefore it has weaker security compared to L1 transactions. But compared to 0-conf L1 transactions, the security is higher. If the batch of sequencer transactions is confirmed at L1, the security level remains the same.

If the sequencer is unavailable or has become malicious, L2 users can directly post transactions to the CanonicalTransactionChain contract.

Resistance to censorship

In the event that a malicious sequencer censors the user's transactions, the user can enqueue() transactions directly into the L1 queue. This will force the sequencer to include transactions in the L2 queue within the FORCE_INCLUSION_PERIOD transaction. If any transaction in the queue is older than FORCE_INCLUSION_PERIOD blocks, that transaction must be added to the chain before the protocol allows the sequencer to add other transactions. If the sequencer stops sending transactions completely, the protocol allows users to add transactions to the CTC by calling appendQueueBatch().

Therefore, even if the sequencer is actively censoring a user, the user can always continue to send transactions on the network.

Fault proofs

In any Optimistic Rollups, state commitments are published to Ethereum without any direct proof of their validity. Instead, there is a "challenge window" to ensure that the commitment proofs are valid. At first, all commitments are considered pending for a certain period of time. If nobody challenges the commitment during the challenge window, it becomes final. If a commitment is challenged, it is considered invalidated through a “fault proof” process and is removed from the StateCommitmentChain.

The sequencer periodically posts transactions to the CanonicalTransactionChain contract, where all Optimistic Rollup blocks are stored. At the next stage, the sequencer reads the batch of the user-published transactions in the CanonicalTransactionChain contract to process them and produce a State Batch. Then, it appends the generated Merkle root: it is an important part of the process as verifiers (other smart contracts) can use Merkle tree proofs it to verify the validity of the batch that occurred recently.

Proposers & Verifiers

Note that the proposer role is expected to change in the future, but currently it works identically to the sequencer.

These two roles are necessary to evaluate and commit transactions. The evaluation happens in the Canonical Transaction Chain, and then the resulting state is committed by writing it to the State Commit Chain. Proposers must pay a bond to obtain privilege for this role.

Verifiers perform the same functions as proposers, but some differences must be considered. A verifier evaluates transactions in the Canonical Transaction Chain to determine the resulting state root after each transaction.

If the verifier detects an incorrect proposed state root, it will be considered a case of fraud. As a result, a reward is earned, which is deducted from the proposed state root. In such a verification model, multiple accounts can contribute to the fraud protection process and increase the overall security of the process. In this way, these accounts can earn rewards.

Verifiers read transactions from the Canonical Transaction Chain. They process transactions and verify that the state roots in the state commit chain are correct. If the state root is invalid, the verifier initiates and completes a fraud-proof task. There is a convenient cross-chain communication contract L1CrossDomainMessenger , which can verify these proofs on behalf of other contracts.