Ecosystem Explorer — Exploring Finality Risks of Ethereum L2 From a CEX Perspective

Written by c4lvin, Research Analyst of ChainLight

Summary

In this article, we analyze how the transactions of Ethereum Layer 2 chains get finalized and observe the approaches of various Cryptocurrency Exchanges (CEXs) in dealing with finality. Furthermore, we discuss the ideal direction for L2 ↔ L2 deposit/withdrawal confirmation from the perspective of CEX.

Background

Blockchain’s trustworthiness partly stems from its immutability, a characteristic ensured by the concept of “finality.” Finality is the irreversible confirmation of transactions through the blockchain’s consensus mechanism. If a block fails to finalize as a result of the consensus mechanism, the transactions included in the block will revert. The approach to achieving finality varies with each blockchain’s design — some prioritize scalability and quick finality, while others emphasize security, necessitating more extensive consensus processes. In this article, we focus on Arbitrum and Optimism, which are both Layer 2 chains based on Ethereum. Due to the distinct nature of Layer 2 chains, they have unique finality mechanisms.

Finality in CEX perspective

From the exchange’s perspective, the relationship between deposit/withdrawal processes and transaction finality is critical. If a transaction fails to finalize and reverts after the exchange’s confirmation on a deposit or withdrawal, it can result in financial losses for participating entities.

• Deposit (External wallet → CEX wallet): If the transaction reverts after the confirmation of deposit, exchanges may lose their assets. The actual deposit transactions revert in the chain, but the CEX may handle user assets as deposited, allowing double-spend behaviors.
• Withdrawal (CEX wallet → External wallet): If the transaction reverts after the confirmation of withdrawal, users may lose their assets. The actual withdrawal transactions revert in the chain, but the CEX server may handle user assets as withdrawn, requiring manual processes on user asset recovery.

Therefore, exchanges should wait for the finalization of deposit/withdrawal transactions to be confirmed in order to prevent unintended loss of both exchanges and users. Most exchanges set this pending interval with the number of generated blocks of the base network (Ethereum in the cases of Arbitrum and Optimism) after the transaction. The pending interval of transactions is named “confirmation.”

In order to understand the finality of Arbitrum and Optimism, explanations of the transaction process should be preceded. We discuss how transactions are processed on these chains, with some possibilities where the finality of transactions can be affected.

1. Arbitrum

Transaction Processing

Arbitrum employs two methods for transaction submission:

• Submission through the sequencer
• Submission of calldata to the “Delayed Inbox” contract in Ethereum

Transaction flow of Arbitrum.

Scenario 1: Submission via Sequencer

A centralized entity called “Sequencer,” operated by Offchain Labs, processes Arbitrum transactions. The sequencer arranges and simulates the transactions, publishes them into the Arbitrum chain, and uploads the proof into Ethereum. Normally, transactions are submitted to the sequencer. Transaction flow via the sequencer is as follows:

1. The user submits a signed transaction through the Arbitrum Node, and the transaction is forwarded to the sequencer.
2. The sequencer stores the transaction in its off-chain inbox, arranges it into a list, and locally executes the Arbitrum Nitro VM for each transaction in sequence.
3. Upon successful execution, the sequencer publishes the transactions into the Arbitrum chain, producing a new block. Any invalid transactions will be filtered out in this phase.
4. The sequencer uploads the receipt of transactions into the Sequencer Feed, indicating “Soft Finality.” In this stage, users can find their transaction submitted through Arbitrum explorers, with the transaction tagged as “Sequencer Confirmed.” This indicates the transaction is included in an Arbitrum block, making changes to Arbitrum’s state.
5. The sequencer then compresses these transactions into a batch and submits it to Ethereum’s Sequencer Inbox contract. So far, it takes about 3–4 seconds.
6. Once the transaction submitted to the batch is finalized on Ethereum, the transactions in the batch achieve “Ethereum-equivalent finality.” According to Vitalik’s previous article, Ethereum blocks take about 12.8 minutes to finalize, covering 64 to 95 slots.
7. Arbitrum’s state is further validated through a challenge process overseen by Arbitrum validators. Validators are whitelisted entities elected by Arbitrum DAO, who have a duty to monitor and confirm the validity of the value submitted into the Sequencer Inbox contract. Validators can claim a “challenge” to the batch within 7 days after submission against the validator who is tasked to validate the batch. If a challenge arises, two validators cross-check Arbitrum’s state in a top-down manner, examining from the block level to the opcode level. Once the challenge is resolved or if no challenge arises within 7 days, the transaction gets finalized, and no further objections can be made afterward.

Scenario 2: Submission via Delayed Inbox in Ethereum

In the context of exchanges dealing with deposits and withdrawals, it is unlikely they would need to directly submit transactions to Ethereum’s Delayed Inbox. Suppose exchanges do not trust the sequencer’s operations and consequently submit transactions to the Ethereum contract every time. In that case, they will inevitably end up offering higher fees with poor user experience. Therefore, it is advisable for exchanges to periodically check the Sequencer Feed. If they detect any halt in operations, they should promptly suspend deposits and withdrawals to mitigate potential issues.

However, understanding how transactions submitted to the Delayed Inbox are processed is also vital. The process is as follows:

1. Users send their Arbitrum transactions to Ethereum’s Delayed Inbox contract in the form of calldata.
2. Every 10 minutes, the sequencer checks the calldata submitted to the Delayed Inbox contract and brings it into its Off-chain Inbox.
3. The following steps are the same as those outlined in Scenario 1.

Potential Issues

Case 1: Sequencer’s Batch Submission Faces Reorgs

If the sequencer’s batch submission to the Sequencer Inbox gets reorged and left unfinalized, users’ deposits and withdrawals won’t achieve Ethereum-equivalent finality until the batch is resubmitted. In this situation, Arbitrum will naively produce a sequence of unfinalized blocks and later submit another batch, including transactions that could not meet finality through the reorg. However, Arbitrum cannot guarantee its stability if the reorg is prolonged. In May 2023, Ethereum suffered 139 slots of finalization failure due to the Casper FFG stall.

To guarantee the finality of batch submission, exchanges typically wait for a certain number of Ethereum block productions after the batch submission to obtain the Ethereum-equivalent finality.

Unfortunately, official documentation does not describe well how the reorged batches are handled.

Case 2: Malicious Sequencer

The sequencer can arbitrarily rearrange transactions or delay submitting batches to Ethereum. In the extreme case of the sequencer not submitting a batch for over 24 hours, users can force-include their transactions directly to Arbitrum Core Inbox, using Sequencer Inbox’s forceInclusion method to bypass the sequencer. In this case, the transactions are included in a first-come first-served manner, which can lead to extreme instability in Arbitrum. Therefore, monitoring batch submissions at certain intervals is needed. Fortunately, the sequencer cannot revise submitted transactions since users send transactions signed with their private key.

Case 3: Sequencer Stalls

Since Arbitrum’s launch, its sequencer has halted three times. The first was due to a bug in the sequencer’s batch submission mechanism, which lasted about 7 hours. The second was due to the lack of the Ethereum gas fee of the sequencer and was resolved after an hour. The third is still under investigation in current state (Dec.16 2023, 5PM GMT). Arbitrum claims it is due to the significant surge in network traffic.

Arbitrum sequencer outage in Dec. 16, 2023

In those kind of cases, block production in Arbitrum ceases. Once the issue is resolved, Sequencer will resume and process transactions in order. However, in CEX scenarios, prompt action is crucial as a massive amount of budget can be left as pending transactions in a relatively long term. Exchanges should monitor the Sequencer Feed updates to detect any malfunctions and decide whether the transaction can be submitted or not.

Case 4: Impact of Transactions Submitted in Delayed Inbox

When the sequencer operates normally, transactions stored in the Delayed Inbox are periodically retrieved into the sequencer’s Off-chain Inbox. These transactions in the Delayed Inbox are appended to the end of the transaction list in the Off-chain Inbox, thereby not affecting the transactions of the exchange or user. The interval for moving these transactions is based on the time for Ethereum finality as considered by Sequencer. According to the official documentation, the sequencer moves transactions from the Delayed Inbox to its Off-chain Inbox every ~10 minutes. Therefore, Ethereum’s short-term reorg is not a concern in this scenario unless the Arbitrum Sequencer has set an unusually short finality time for Ethereum.

Additionally, if the sequencer stops, transactions in the Delayed Inbox cannot be delivered to the Off-chain Inbox. If this situation lasts longer than 24 hours, the transactions in Delayed Inbox are forcibly incorporated into Arbitrum by any address. For CEX, in such cases, blocking deposits and withdrawals is recommended. Sequencer Feed should be regularly checked to verify its normal operation, as the Arbitrum chain itself can become extremely unstable after 24 hours. Certainly, this scenario is highly exceptional with a low possibility.

2. Optimism

The mechanism handling L2 → L2 transactions in Optimism is relatively straightforward compared to Arbitrum.

Transaction Processing

Similar to Arbitrum, Optimism has two forms of transaction process.

• Transaction submission through the sequencer
• Submission to an Ethereum contract

Scenario 1: Submission via Sequencer

Optimism transactions are also processed by a centralized entity named “Sequencer.” The sequencer arranges the transactions, publishes them into the Optimism chain, and periodically uploads the proof into Ethereum. Normally, transactions are submitted to the sequencer. Transaction flow via the sequencer is as follows:

1. Users send transactions to the Optimism node, and the transactions are forwarded to the sequencer.
2. Forwarded transactions enter the sequencer’s private mempool and are executed based on their base and priority fee.
3. After the execution, the sequencer, as the Batcher, sends the transaction batch to Ethereum’s batch inbox.
4. The sequencer, as a state root proposer, submits Optimism’s Merkle root to Ethereum every hour.
5. Optimism verifier can challenge the current state of Optimism through a “fraud-proof” mechanism within 7 days of the window. Currently, Optimism’s challenge system is suspended due to major updates, with a new system under development.

Scenario 2. Submission to an Ethereum Contract

Users can initiate Optimism transactions by sending transactions to an Ethereum contract, which are named “deposited transactions.” The processing mechanism of those transactions is as follows:

1. Users send a deposited transaction to the L1CrossDomainMessenger contract in Ethereum in the form of calldata.
2. L1CrossDomainMessenger contract sends the calldata to the OptimismPortal contract, calling depositTransaction function. This runs a few sanity checks and triggers the TransactionDeposited event.
3. The Optimism node continuously observes events from OptimismPortal contract in Ethereum, parses the events, and converts them into Optimism transactions.
4. The Optimism node submits the parsed transactions that call the destination address. Therefore, the user’s transaction gets included in the Optimism network.

In Optimism’s block generation, the concept of “epoch” is used. This means a set of Optimism blocks is linked to a set of Ethereum blocks. M Optimism blocks are correlated to N Ethereum blocks. In an epoch, the timestamp of the oldest Optimism block of the epoch should be later than the latest Ethereum block. According to the Optimism docs, 3600 Ethereum blocks are included in an epoch, with each range overlapping.

Potential Issues

Case 1: Sequencer Malfunctions or Stalls

Since its launch, Optimism block creation stopped once for 18 minutes on April 15, 2023, due to the bug that blocked the sequencer’s block creation requests. Optimism’s reliance on the sequencer is quite heavy, so bugs or halts of the sequencer will cease the block production of the Optimism network for a considerable period of time.

In CEX scenarios, the deposit/withdrawal should be promptly blocked for these cases. Since Optimism’s block generation is rapid, which is about 1–2 seconds, exchanges can figure out the malfunction of the sequencer, which periodically checks through the public API.

Case 2: Ethereum Finality Issues

Historically, three times of performance degradations happened in Optimism due to the issue within syncing Optimism blocks with Ethereum, which lasted from 30 minutes to an hour. Those issues are related to the sequencing epoch mechanism of Optimism block generation, as the Optimism block should forerun a certain amount of time compared to the Ethereum block. In those cases, transactions would be normally submitted but with less availability. From the CEX perspective, transactions should be confirmed after they are finalized, so the time for the confirmation should be elongated.

In the current state, Optimism transactions are operated only with the sequencer-confirmed state as the fraud-proof mechanism is absent. Therefore, Optimism now has a simple finality mechanism, and no Optimism transactions seem to be reverted after the Ethereum finality is guaranteed.

Current State of CEX Confirmations

For this article, we signed into each CEX and identified the block number required for confirmation of L2 → L2 deposit transactions. The targeted CEXs were selected based on trading volume rankings from CoinMarketCap as of December 5, 2023.

As shown in the table below, each exchange goes through very different confirmation numbers.

1. Arbitrum

Arbitrum confirmation numbers for deposits in CEXs and trading volumes.

2. Optimism

Optimism confirmation numbers for deposits in CEXs and trading volumes.

Most CEXs agree that the finality of L2 follows the finality of ETH. However, the very different confirmation requirements between CEXs imply a varied awareness of the potential issues with Ethereum finality. Moreover, exchanges that set different confirmation requirements for Arbitrum and Optimism are not uncommon. This could be because they have implemented separate internal verification logics, or it might be due to the lack of fraud-proof in the Optimism network, necessitating a higher level of confirmation.

Additionally, when the trading volume of CEXs and the number of confirmation blocks are represented in a quadrant, the pattern observed is as follows. This is to observe if the low confirmation number, which is performance from the user perspective, follows the trading volume, or high confirmation, which is security from the CEX perspective, goes proportional to the size of the CEX.

• Trading volume here means the volume for each cryptocurrency, ARB and OP, on exchanges.
• Confirmation number here refers to the required count of Ethereum blocks to complete the unlocking of a user’s deposited assets. Once unlocked, these assets can then be withdrawn to external wallets.

No clear proportional relationship was observed. However, it was encouraging to note that exchanges with relatively lower confirmations, such as Crypto.com, actually had lower trading volumes.

Furthermore, Bitget and HTX, despite both dealing with the Ethereum L2 networks, Arbitrum and Optimism, demand very different confirmation requirements.

Exchanges must explain to their users why their confirmations are set at such levels. Some exchanges, like Binance, provide this information in the form of a notification during deposit/withdrawal processes, stating reasons such as “to align with Ethereum’s finality.”

Conclusion

Setting the appropriate number of confirmations is crucial for protecting both users and the assets of the exchanges themselves. This is particularly true for chains like Arbitrum and Optimism, which are L2 chains dependent on Ethereum, necessitating a unique approach to defining their finality compared to other chains. Exchanges must be fully aware of this and designate an appropriate number of confirmation blocks.

Additionally, there is a noticeable lack of information available to consumers regarding this. Exchanges should provide more comprehensive explanations about their confirmation numbers to alert and inform their consumers.

A Call for Discussion

Dear readers, what do you think about the appropriate number of confirmations for L2 → L2 deposit/withdrawal transactions from CEX's perspective? Would 10~12 ETH blocks be sufficient?

References

• https://docs.arbitrum.io/tx-lifecycle
• https://community.optimism.io/docs/protocol/txn-flow/#
• https://community.optimism.io/docs/protocol/2-rollup-protocol/#optimistic-rollups-tl-dr
• https://notes.ethereum.org/@vbuterin/single_slot_finality
• https://docs.arbitrum.foundation/state-of-progressive-decentralization#allowlisted-validators
• https://help.coinbase.com/en/coinbase/getting-started/crypto-education/glossary/confirmations
• https://developers.circle.com/stablecoins/docs/required-block-confirmations
• https://blog.trailofbits.com/2023/08/23/the-engineers-guide-to-blockchain-finality/
• https://jumpcrypto.com/writing/bridging-and-finality-ethereum/
• https://support.kraken.com/hc/en-us/articles/203325283-Cryptocurrency-deposit-processing-times
• https://support.nexo.com/s/article/processing-time-of-cryptocurrency-deposits-blockchain-confirmations?language=en_US
• https://www.bitstamp.net/faq/how-long-do-i-need-to-wait-for-my-cryptocurrency-deposit/
• https://jumpcrypto.com/writing/bridging-and-finality-op-and-arb/

About ChainLight

Patch Thursday is ChainLight’s weekly report introducing and analyzing vulnerabilities discovered and reported by our award-winning security researchers. With the mission to assist security researchers and developers in collectively learning, growing, and contributing to making Web3 a safer place, we release our report every week, free of charge.

To receive the latest research and reports conducted by award-winning experts:

👉 Subscribe to our newsletter

👉 Follow @ChainLight_io

Established in 2016, ChainLight’s award-winning experts provide tailored security solutions to fortify your smart contract and help you thrive on the blockchain.