Rollup transactions have three stages, and they are ultimately irreversible. By separating the transaction sorting and execution process, it achieves sorting finality, allowing anyone to determine the database status. Users can quickly withdraw funds, and executors can flexibly wait for transactions to accumulate before settling. Several Rollup implementations have achieved sorting finality, including Arbitrum, Optimism, Scroll, Polygon Hermez, and ZkSync, which is very useful for optimizing transaction execution delays.
A Rollup transaction goes through three stages as it gradually becomes settled, final, and irreversible. We explore an interesting question in the context of Rollup: transaction finality – when is a Rollup transaction considered final and irreversible? In Rollup, transaction finality is very different from the final consistency of proof-of-work blockchains (waiting for X confirmations) or Ethereum’s proof-of-stake protocol (finalizing transactions after two consecutive supermajority votes (epochs)). In Rollup, the pursuit of transaction finality has three stages: the sequencer’s commitment, sorting finality, and execution settlement. We focus on these three stages and how transactions pass through each stage. Before we dive deeper, it is important to note that transaction finality is the same for Optimistic and Validity Rollups, or at least both types of Rollups can leverage it.
The sequencer is the only party aware of the pending state of the off-chain database, as they have the authority to decide/provide the sequencing of pending transactions. At a high level, the lifecycle of a transaction begins with the user authorizing the transaction with a digital signature and then transmitting the transaction to the sequencer. The sequencer can respond with the predicted execution of their transaction, commitment to the execution when the transaction is finally settled. This commitment is possible because the sequencer is the only party with a list of all pending transactions. They have the authority to decide on the sequencing of transactions and then transmit them. Therefore, only the sequencer is aware of the pending state of the off-chain database. We refer to it as a commitment because the sequencer can decide to return an invalid response to the user and ignore the transaction. Rollups have two methods to help prevent malicious and lying sequencers: signed receipts and forced inclusion. The bridge smart contract decides the final sequencing of transactions and authorizes anyone to compute the off-chain database’s copy.
The bridge smart contract and the underlying blockchain fulfill the role of a data availability layer, providing a single guarantee: data availability – data items are published at a certain point in time, and all online parties can obtain it. In the case of Rollups, publishing a batch of transactions to the bridge smart contract allows all honest users, executors, and other sequencers to obtain the transaction list. A new batch of transactions should be appended to the Rollup’s canonical transaction chain. Any party can execute new transactions on their local database copy and calculate the new state of the off-chain database. This is a deterministic process, and all parties should arrive at the same state. As we will see later, as long as you trust an honest party to step up and execute the settlement, it is possible to build a protocol that relies solely on sorting finality on top of the bridge.
The ultimate goal is to convince the smart contract about the execution of the sorted transactions. The sole purpose of execution settlement is to convince the smart contract, not external parties or consensus protocols, about the final execution of all sorted transactions. After all, at this point, the bridge has sorted all transactions to be executed, and anyone, including users, can calculate the expected database copy. The only party not aware of the current database state is the bridge smart contract because it lacks the resources to replay and process all pending transactions. It is up to the executor to prove and propose the new database state and provide proof that the proof is correct. The execution settlement only authorizes the bridge contract to perform side effects, including transferring funds from the off-chain system to the L1 smart contract or sending messages. Side effects can only be executed when the bridge is confident in the execution of the relevant transactions.
This leads to one of the most interesting aspects of Rollup: it separates the process of transaction sorting and calculating the expected execution. Separating these processes allows anyone to deterministically calculate the database state before settling with the bridge smart contract. The time delay between sorting and execution may be significant. For example, at the time of writing this article, Arbitrum and Optimism send transaction batches to the bridge smart contract approximately every 30 seconds. Therefore, sorting finality can be determined in less than 10 minutes, but execution settlement may take at least two weeks. This brings us to the key point of this article: transacting after sorting and before settlement. As long as you can trust an honest party to step up and force the final execution and settlement with the bridge smart contract, agents can act on the unsettled database state after sorting finality.
In conclusion, any Rollup that directly publishes transaction data to the bridge smart contract can achieve sorting finality. We have mentioned that Arbitrum and Optimism support sorting finality, but we also know that Scroll, Polygon Hermez, and potentially ZkSync have implemented this. Most discussions focus on how Optimistic Rollups use sorting finality to bypass execution settlement delays (~2 weeks). However, this is equally useful for Validity Rollups, as users can assume their finality when sorted transactions are executed. This provides flexibility for executors to accumulate sorted transactions and then generate a validity proof and settle the execution.
