Bridging and Finality: Optimism and Arbitrum

We touched upon Ethereum’s consensus in our latest post and the trade-offs faced in reversion risk and latency. Given that foundation, we’ll investigate how optimistic rollups build upon those finality guarantees, especially in the context of cross-chain bridging. Optimistic rollups are an essential component of the L2 scaling roadmap for Ethereum, which has maintained a rollup-centric perspective by actively focusing on research directions in data availability and danksharding. The two main optimistic rollups are Arbitrum and Optimism, and the transaction lifecycle throughout both of these chains is almost equivalent, with a few differences in naming and timing.

In this article, we’ll step through each aspect of the rollup protocol and explain what assurances the user has over their transaction’s finality at every point.

Preliminaries

Currently, both Arbitrum and Optimism operate with a single centralized Sequencer that is in charge of ordering all the transactions it receives and is assumed to work honestly in a first-come, first-serve manner. There are plans to decentralize the sequencing role with whitelisted or community-voted L2 nodes, but the roadmap for this effort is still unclear.

Soft Finality

First, the Sequencer receives a transaction from the sender in one of two ways. Usually, when operating within the L2 environment, users connect their wallet to an L2 node and directly send a signed transaction off-chain to the Sequencer. In other instances, a user can send a transaction to the Sequencer by publishing an L1 transaction in the rollup’s contract on Ethereum; this is usually done for L1 actions that require an L2 message, i.e. depositing assets with a bridge on the rollup chain (escrowing on L1 and minting on L2).

After receiving a transaction, the Sequencer then orders the transaction off-chain and gives an instant transaction receipt to the user as “soft finality” within 1-2 seconds. This real-time transaction receipt doesn’t require any additional on-chain confirmations and is announced via a live feed, which anyone can observe and independently run a deterministic State Transition Function (STF) to deduce the outcome of that transaction right away.

If the transaction was sent to L1, the Sequencer in Arbitrum will emit an L2 receipt 10 minutes before reaching the Sequencer to ensure that short-term reorgs on L1 don’t occur and revert the inclusion of transactions on the rollup chain. In Optimism Bedrock (coming in 2023), transactions to L1 are expected to confirm within 3 minutes.

Furthermore, Optimism Bedrock's L2 block interval will be 2 seconds (previously sporadic). In Arbitrum Nitro, L2 block intervals are variable, posted 3-4 times per second.

Trust Assumption

The user’s acceptance of finality completely depends on trusting the Sequencer; a censoring or offline Sequencer could differ between the ordering denoted in this instant receipt and the ordering ultimately published in a batch. The worst that the Sequencer can do is reorder or delay transactions, as it is impossible for it to forge a transaction from the user or propose an invalid state update.

In Arbitrum, to prevent censorship by the Sequencer, a user can force-include a transaction into the next L2 block to bypass the Sequencer if it’s been delayed for over 24 hours — transactions are then included in a FIFO manner. The reason behind the 24-hour threshold is to disincentivize forced inclusion under normal conditions, as this affects the state for any unbatched L2 transaction and invalidates instant receipts.

In Optimism, transactions submitted to L1 are automatically included in an L2 block as soon as possible; the first L2 block in a roll-up epoch must include all the deposited transactions in the first L1 block (each L1 block defines a rollup epoch, and there can be many L2 blocks per epoch).

Reversion Risk

If the transaction was sent to L2 directly and the L1 chain faced a reorg before that transaction became batched and finalized on L1, then the L2s could theoretically continue building their blocks and batch all those transactions that did not make it through the reorg. There is no documentation on this for either L2, though.

In the case that the transaction was sent to L1, Arbitrum doesn’t have anything in place to deal with an L1 reorg. This isn’t terrible though, since post-merge there is an L1 finality delay of 12.8 minutes anyways, so the delay isn’t too far off from the expected 10 minutes. In Optimism, because L2 follows L1 more tightly within a window of 3 minutes, it will handle L1 re-orgs by reorging L2 if needed, but it is unspecified how it does so.

In these scenarios, the rollups offer no assurances. The transactions may never appear on-chain, and the procedure for inclusion post-reorg isn’t well-detailed.

Hard Finality

Next, the Sequencer compresses and posts L2 transactions in a batch as Ethereum calldata every 1-3 minutes on Arbitrum and 30 sec - 1 minute on Optimism. Calldata is the non-modifiable portion of a smart contract that basically functions like memory and persists on-chain as part of the blockchain’s history logs but not as part of its state, allowing it to be more cost-effective for on-chain data storage.

In Solidity, the calldata keyword is used to pass arguments to a specified smart contract function. In this scenario,  the sequencer uses calldata to call the L1 rollup contract function and pass compressed transaction data as input to the function. The L2 transaction now has the same finality as the L1 block that included it in a batch, and we achieve “hard finality.”

The L2 state, which consists of accounts, balances, contracts, etc., is structured as a Merkle tree, called a “state tree.” The root of this state tree is the L2 state root and defines the rollup’s latest state, which is hashed and stored in the L1 rollup contract. A sequencer needs to submit old (state prior to the batched transactions) and new (state after the batched transactions are executed) state roots when posting batches, which are necessary to prove the correctness of state changes.

Once the sequencer submits the batch, the contract verifies that the pre-state root matches the existing state root. If the two match, the contract discards the old state root and stores the new state root proposed by the sequencer.

Trust Assumption

The user can now use whichever finality standard for regular L1 transactions (explored in the previous post) towards the L2 transaction that is now included in an L1 block. Execution on optimistic rollups is fully deterministic; a current chain state and new input data are sufficient to compute the new chain state through the STF. The moment this input data is available when the Sequencer posts a batch, the L2 chain's new state can be computed and the transactions’ ordering is determined by the L1; the Sequencer has no more input. The data in the batch posted on L1 is available and sufficient for any node to reconstruct and validate the state of the L2 chain.

Any user uneasy with the trust assumptions of the Sequencer in “soft finality” can just wait for the Sequencer to post their transaction in a batch, as it offers the same guarantees as L1 finality.

Reversion Risk

Batches go through a reorg only if Ethereum itself goes through a reorg. This becomes less and less likely as the batch submission is followed by more confirmations. Since these batches are submitted as Ethereum calldata, there is no way to modify or censor them after the transaction is included in a block that has enough attestations; this is how L2s inherit the security guarantees of Ethereum. Arbitrum and Optimism transactions that undergo “hard finality” are therefore secure against large block reorganizations as long as the Ethereum consensus mechanism is.

Challenge Period and Withdrawal

On Arbitrum, validators (currently whitelisted) read transaction batches from L1, process them one at a time using a deterministic STF and can contest the L2 state root posted in the batch. The L1 rollup contract accepts new state roots immediately after they are posted, so state commitments can be published to Ethereum without any proof of their correctness (optimistically hoped to be correct, hence the name of the rollups).

If a proposed state commitment goes unchallenged for the duration of the challenge period, then it is considered final, after which smart contracts on Ethereum can safely accept withdrawal proofs about the state of the L2 based on that commitment. If a state commitment is challenged successfully, the invalid batch and those published afterward will be reverted, restoring the rollup to its old state root. The rollup protocol will then need to re-execute the transactions and update the rollup's state accordingly.

Any other validator can challenge the state root within the challenge period of one week, which includes a multi-round interactive fraud proof game that will be eventually settled by L1. As long as there is at least one honest validator, the correct L2 state root is guaranteed to be published to L1. Fraud proofs used to challenge state commitments are currently not implemented on Optimism.

After the challenge period is over, withdrawals are finally allowed. Withdrawals are cross-domain transactions that are initiated on L2 and finalized by a transaction executed on L1, such as to transfer tokens from an L2 account to an L1 account. A user just needs to provide a Merkle proof (using calldata) to the rollup contract that proves their transaction was included in the rollup’s state root.

Trust Assumption

If any validator tries to deviate from the valid L2 state, an honest validator will be able to challenge this. We only need one honest validator for this to occur, so we know that the valid state will ultimately win out. One honest node is all that’s needed to advance the chain correctly by posting valid assertions or disputing invalid assertions.

Reversion Risk

A state commitment (the result of running the transactions) can be invalidated through a successful fraud proof and removed to eventually be replaced by another proposed commitment. But a successful challenge does not reorg the L2 or affect the finality of the transaction - it is still included on L1. It just means that the calculation of the result of this transaction on the state of the chain is incorrect and will be recomputed. The ordering of transactions and the state of the L2 is unchanged by a fault-proof challenge.

Bridging Implication

We’ve developed a framework that bridges can follow and the types of finality that would offer sufficient guarantees in different use cases. Like the previous post on Ethereum, we will also operate under the assumption that the bridges are running full nodes on Arbitrum/Optimism and validating all rollup transactions. This way, the bridge does not rely on state commitments or fraud proofs (so it is fine that the fraud proof implementation has not been implemented yet in Optimism). Even when fraud proofs are implemented, bridges don’t need to wait the 1-week challenge period, giving users access to their assets sooner. We believe that using the “hard finality” batched calldata is sufficient, and token withdrawals can be implemented across bridges to rely on hard finality (two epochs) instead of the challenge period (one week).

In certain scenarios, bridges speed up the process even more by enabling the ability for protocols to operate on “soft finality” commitments, up to the client’s specification. All transactions are viewed by each of the validator(s) for the bridge by directly connecting to their independently operated nodes. Instead of only validating messages that reach finality on the original chain, which is two epochs in this case, bridges offer optionality where an integrator can specify for faster messaging, such as immediately based on instant transaction receipts (publishing the transaction as soon as it receives it) up to the original two epoch threshold, and even longer if desired.

In certain use cases, just observing the Sequencer log can be considered “safe” enough; for example, if oracles wanted to emit from Ethereum, only the validity of messages matters, not so much the messages reaching consensus. As long as the bridge runs full nodes, the validity of the messages is guaranteed, and faster messaging could be a viable option.

Trust Assumption

For regular messages, the Sequencer does not need to be trusted by the bridge for liveness since users can also submit transactions directly to the L1 (although at a higher gas cost) and does not need to be trusted for safety since transactions are finalized on the L1.

For custom, faster messages, the Sequencer is trusted since there is no mechanism preventing the Sequencer from deviating from its expected first-come, first-serve transaction ordering and the ordering it actually posts to the L1. This risk is completely taken upon by the sender who specifies to have their message relayed instantly instead of waiting for L1 finality. Thus, a token bridge should continue to rely on the 2-epoch cutoff, while order-insensitive messages can be verified before finality if so desired.

Conclusion

In this post, we explored the trust assumptions at each phase of the optimistic rollup protocol and the reversion risk associated with them. We then tied these varying levels of finality to the design decisions that generic bridging protocols consider so that users and cross-chain applications have confidence in understanding the assurances that they specify for their transactions.