Tiers of Transaction Finality for Rollups
Tiers of Transaction Finality for Rollups
When does a transaction become final and irreversible?
We explore an interesting question in the context of rollups:
Transaction Finality → When is a rollup transaction considered final and irreversible?
Finality in a rollup is very different compared to a proof of work blockchain’s eventual consistency that waits on X confirmations or Ethereum’s proof of stake protocol that will finalise a transaction after two consecutive supermajority votes (epochs).
In a rollup, the pursuit of transaction finality has three stages:
Sequencer’s Promise → Sequencer promises the user that the transaction will be ordered and executed as expected.
Order Finality → The user’s transaction has a final ordering relative to all other transactions.
Execution Settlement → The bridge smart contract is convinced about the final execution of a user’s transaction.
Our article focuses on the above three stages and how a transaction progresses through each stage. Before diving in further, the finality of transactions is the same for both Optimistic and Validity Rollups, or at least both type of rollups can take advantage of it :)
Sequencer’s Promise
At a high level, a transaction’s lifecycle starts with the user authorising it with a digital signature before passing the transaction to the Sequencer.
The Sequencer can respond with:
The predicted execution of their transaction,
A promise that this execution will hold when the transaction is settled as final.
This promise is possible as the Sequencer is the only party who has the list of all pending transactions. They have the authority to decide how the transactions will be ordered before passing it on. As a result, only the Sequencer is privy to the off-chain database’s pending state.
We call it a promise as the Sequencer can decide to return an invalid response to the user and ignore the transaction.
There are two ways that rollups can help fend against a malicious and lying Sequencer:
Signed receipts. A Sequencer may have to return a receipt with their digital signature which can be later used to slash/punish them for lying to the user.
Forced inclusion. A user can bypass the Sequencer and submit their transaction to the bridge smart contract.
While it is the Sequencer’s role to offer a fast path for deciding final order of transaction execution, it is not their sole discretion to do so. It is ultimately up to the bridge smart contract to decide the final ordering of all pending transactions.
Saying that, the bridge will prioritise the batch of transactions proposed by the Sequencer as long as it is published in a timely manner (~24 hours for Arbitrum).
Transaction Order Finality
The bridge smart contract, and the underlying blockchain, fulfills the role of a a data availability layer which provides a single guarantee:
Data Availability: A data item was published at a point in time and it was available for all online parties to fetch it.
In the case of rollups, the act of posting a batch of transactions to the bridge smart contract enables all honest users, executors, and other Sequencers, to fetch the list of transactions.
The new batch of transactions should be appended to the rollup’s canonical chain of transactions. Any party can execute the new transactions against their local copy of the database and compute the new state for the off-chain database. It is a deterministic process and all parties should derive the same state.
As we will see later — as long as you can trust that one honest party will step up and enforce execution settlement — then it is possible to build protocols on top of the bridge that only relies on order finality.
Note, some rollups bypass this stage as the Sequencer sends the transactions directly to the Executors, there are pros/cons to doing so which we will not discuss here.
Execution settlement
The only purpose for execution settlement is to convince the smart contract, not external parties or a consensus protocol, about the final execution of all ordered transactions.
After all, at this point in time:
Bridge has ordered all transactions for execution,
Anyone, including users, can compute a copy of the expected database.
The only party who does not know the current state of the database is the bridge smart contract as it lacks the computational resources to replay and process all pending transactions.
It is up to the Executors to attest and propose the new database state alongside convincing evidence that the attestation is correct. An Executor can decide to process one or more batches of transactions with the only constraint being that the execution must respect the final ordering of transactions. The evidence can be a fraud proof or a validity proof.
The only reason for execution settlement is to empower the bridge contract to perform a side-effect including transferring funds or sending messages from the off-chain system to an L1 smart contract. A side-effect can only be performed by the bridge once it is convinced about the execution of the relevant transactions
Put another way, the bridge will only release funds as long as it is convinced that all transactions are valid and executed correctly.
Tiers of Finality Summary
This brings us to one of the most interesting aspects of a rollup.
It separates the process of ordering transactions and computing its intended execution:
Ordering First. All parties can determine the same list of transactions and locally compute the new state for the off-chain database.
Delayed Execution. The entire process is focused on convincing the bridge smart contract about the new state of the database after the ordered transactions are executed.
Separating the processes allows anyone to deterministically compute what the database state will be before the execution is settled with the bridge smart contract.
The time delay between ordering and execution can be drastic. For example, if we consider how frequent transaction batches are sent to the bridge smart contract, then at the time of writing it is every 30 seconds on Arbitrum and Optimism.
So, order finality can be determined fairly quickly <10 minutes, but execution settlement may take at least 2 weeks.
This brings us to the key takeaway for the article:
Transact after ordering & before settlement. As long as you can trust that one honest party will step up and enforce eventual execution settlement with the bridge smart contract, then agents can act upon the unsettled database state once the ordering is final.
Let’s consider a user who wants to quickly withdraw funds from a rollup to Ethereum which has three steps:
User sends funds + fee. A user can pick a liquidity provider (LP) and issue a transaction that transfers funds to the LP. This transaction is confirmed on the rollup and it will sends the funds to a special arbitration contract on Ethereum.
LP waits for order finality. The LP will wait for the rollup transaction to have achieve order finality before deciding to send the user funds on Ethereum.
LP or user gets the funds. The user’s funds will reach the arbitrum contract when the execution is settled. The Arbitrum contract will send the LP the funds if they have already paid the user or it will simply refund the user their funds on L1 if the LP failed to fulfil their duty.
In the above example, the user can optimistically receive the funds from the LP in <10 minutes and the LP will have confidence that they will be repaid the funds in ~2 weeks. If there is an issue and the LP does not fulfil their duty, then the user is repaid their funds after ~2 weeks. How exciting is that?!
To conclude, order finality is available for ANY rollup that posts transaction data directly to the bridge smart contract.
We have already mentioned that Arbitrum and Optimism support order finality, but I am also aware that Scroll, Polygon Hermez, and potentially ZkSync have implemented it too.
Most discussion focuses on how Optimistic Rollups can leverage order finality to bypass the execution settlement delay (~2 weeks).
However, it is just as useful for validity rollups, as users can assume the transactions are final as soon as it is ordered for execution. This provides wiggle-room for executors to wait for ordered transactions to pile up before putting together the validity proof and settling the execution.
up only my frens :)