Interpreting the Full Process of L2 Transactions: How Secure are the Different Stages?

When can one be sure that an L2 (Layer 2) transaction will be included in a block? When can one be certain that earnings from an L2 transaction won’t be discarded due to a Re-org?

This article will introduce readers to the entire process of L2 transaction implementation and analyze the security performance at each stage of the transaction process.

Prerequisite knowledge:

1. The entire process of L1 (Layer 1) transactions

2. The causes and impacts of Re-orgs

3. Understanding the roles and operating methods in Ethereum’s current PBS architecture

4. Understanding the differences between Optimistic Rollup and Validity (ZK) Rollup

Understanding L1 Transactions

Transaction Process

After a user issues and signs a transaction, it is sent to the peer-to-peer network and waits for a Miner under the PoW consensus mechanism or a Proposer under the PoS consensus mechanism to include it in a block. When a user finds that their transaction has been included in the latest block, they cannot be 100% sure that the transaction will be permanently recorded in that blockchain’s history. This is due to the possibility of a blockchain event known as a “Re-org.” Users must wait until the probability of a Re-org occurring in a certain block is sufficiently low to be confident that their transaction will be recorded in the blockchain’s history.

L1 Transaction Process Illustration

Even after a transaction is included in a block, a Re-org might still occur. One must wait until a Re-org is unlikely to happen to be confident that the transaction has been Finalized.

The probability and cost of a Re-org vary depending on a chain’s consensus algorithm and the market value of its assets. The method for calculating the cost of a Re-org will not be discussed in detail here.

Understanding L2 Transactions

Transaction Process

After an L2 user generates and signs a transaction, it is typically sent directly to a Sequencer responsible for ordering transactions. The Sequencer then includes this transaction in an L2 block. Subsequently, when the Sequencer writes the L2 block data back to L1 through an L1 transaction, users can see their transaction included in the latest L2 block. However, it is important to note that since L2 block data is uploaded to L1 through an L1 transaction, there is still a possibility of encountering an L1 Re-org. This scenario could lead to the L2 block not being included in the blockchain history, effectively resulting in an L2 Re-org. Therefore, users must wait until the likelihood of an L1 Re-org is sufficiently low before they can be confident that their transaction will be recorded in the blockchain history.

L2 Transaction Process Illustration

Users first wait for their transaction to be included in an L2 block, then wait for the L2 block to be uploaded to L1 via an L1 transaction, and finally wait for the L1 transaction to be finalized. Although waiting for an L2 transaction to be included in an L2 block by a Sequencer adds a step compared to L1 transactions, this waiting period is generally not significant if the L2 block capacity is large and the block generation speed is fast. Most of the waiting time is actually spent on confirming the L1 transaction. Thus, overall, the user experience for L1 and L2 transactions is similar. But can users trade some concessions for a better experience?

Pre-Confirmation/Fast Confirmation/Soft Confirmation

Users should ideally witness their L2 transactions (included in L2 blocks) being included in L1 blocks, and even wait until the likelihood of a Re-org is sufficiently low, before trusting that their L2 transactions have been included. But what if users are willing to trust the Sequencer? Suppose the Sequencer is operated by the L2 development team or a reputable institution. If the Sequencer assures users upon receiving their transactions that they will be included immediately or in the Xth block, this assurance might be sufficient for those willing to trust the Sequencer. This is akin to a user who trusts their wallet app not repeatedly checking Etherscan for transaction confirmation after the wallet has notified them of the inclusion.

This assurance provided by the Sequencer is referred to as Pre-Confirmation, Fast Confirmation, or Soft Confirmation. These can be understood as “premature” or “soft” transaction inclusion assurances. They don’t require waiting for the L2 transaction to be included in an L1 block, but they are merely verbal commitments from the Sequencer. The Sequencer might forget their promise due to a bug or a malicious Sequencer might break their promise, resulting in wasted time for the user or, in the worst case, exposure to a “double-spend attack.”

Next, we will introduce several different ways to present the status of L2 transaction inclusion.

Transaction Inclusion Status on Arbitrum/Optimism

Currently, after users send a transaction on Arbitrum or Optimism, they can almost Currently, when users execute transactions on Arbitrum or Optimism, they almost immediately receive a transaction receipt, which includes the result of the transaction execution. This indicates that the Sequencer has already ordered and simulated the execution of the transaction locally, and the transaction receipt serves as a Pre-Confirmation for the user.

For more information on the detailed transaction lifecycle on Arbitrum, you can refer to the official document at: https://docs.arbitrum.io/tx-lifecycle

For a more detailed explanation of the transaction lifecycle on Optimism, refer to the official document at: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Checking Transaction Inclusion Status on Arbitrum

Transactions displayed on the Arbitrum Explorer include those with Pre-Confirmation, i.e., transactions not yet uploaded to L1. As shown in the following image, a transaction with Block Number 145353000 is marked as “Confirmed by Sequencer,” indicating that it has been confirmed by the Sequencer but not yet uploaded to L1:

[Image shows a transaction confirmed by Sequencer but not uploaded to L1]

In contrast, the next image shows a transaction that has already been uploaded to L1, with a status of “69 L1 Block Confirmations.” This means that the L1 block containing this transaction data has 69 blocks following it, which indicates a higher level of security:

[Image shows a transaction on L1 with 69 block confirmations]

Another example is a transaction with 6174 L1 block confirmations, as shown below, which is considered very secure.

However, it would be better if the L1 Finality information were integrated into this display. Simply telling users the number of L1 Block Confirmations is of limited help, as they have to understand and calculate what level of security this number represents. Since Layer 1 (Ethereum) has a Finality mechanism like Casper FFG, the Explorer could directly display whether the Layer 1 block has been Finalized. Currently, Optimism’s Explorer has implemented this feature.

Checking Transaction Inclusion Status on Optimism

Transactions displayed on the Optimism Explorer also include those with Pre-Confirmation, i.e., transactions not yet uploaded to L1. As shown in the following image, a transaction with Block Number 111526300 is marked as “Confirmed by Sequencer”:

[Image shows a transaction only confirmed by Sequencer but not uploaded to L1]

However, the Explorer does not clearly define the meaning of “Confirmed by Sequencer.” It states, “Sequencer confirmations are equivalent to a few block confirmations on L1,” suggesting that a transaction marked as “Confirmed by Sequencer” has been uploaded to L1 and has several blocks following it:

[Image shows recent transactions marked as “Confirmed by Sequencer”]

Transactions from several days ago, even those past the challenge period, still display the status “Confirmed by Sequencer”:

[Image shows transactions from days ago still marked as “Confirmed by Sequencer”]

Note: The Explorer might display different statuses in different places: “Confirmed By Sequencer” next to the Block Number indicates that the block has been confirmed by the Sequencer. To check the status after being uploaded to L1, users need to look for other information, such as the “L1 State Batch” mentioned below.

As shown in the next screenshot, a transaction already uploaded to L1 includes additional information: “L1 State Batch Index” and “L1 State Root Submission Tx Hash.” These details indicate which State Batch the L2 transaction is included in and which L1 transaction uploaded this State Batch to L1:

[Image shows a transaction with L1 State Batch information]

Clicking on State Batch “3480” reveals its status as Finalized. This Finalized status corresponds to Ethereum’s mainnet and indicates a very secure state, having successfully accumulated two epochs of validator votes.

[Image shows State Batch 3480 finalized in L1 Block 18457449]

Source: https://etherscan.io/block/18457449

If a Batch has been uploaded but not yet Finalized on L1, it will be displayed as Unfinalized:

[Image shows a State Batch uploaded to L1 but not yet finalized]

Compared to the Arbitrum Explorer, the Optimism Explorer provides more information (State Batch) and directly integrates L1 Finality information into the L2 Explorer, letting users know whether the L1 block has been Finalized without having to interpret the number of Block Confirmations for security.

StarkNet Transaction Revenue Status

Currently, when users send transactions on StarkNet, they can quickly access the transaction receipt. However, the status often displayed in the receipt is RECEIVED, indicating that the node has received and validated the transaction as error-free. It will then await inclusion and execution in an L2 block by the Sequencer. Transactions in RECEIVED status do not yet have any execution results. Users can monitor the progress of their transactions through the status displayed on the StarkNet Explorer.

Note: If the Sequencer processes transactions quickly enough, it might skip the RECEIVED status and move directly to a processed state. For a more detailed introduction to StarkNet’s transaction process, refer to the official document at https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

On Starkscan, a StarkNet Explorer, transactions including Pre-Confirmation are displayed. For instance, a transaction shown as “Accepted on L2” indicates it has been sequenced into an L2 block:

“Accepted on L2” means the transaction has been sequenced into an L2 block but not yet uploaded to L1.

The two preceding statuses, Received and Pending, represent “transaction received and validated” and “transaction being processed by the Sequencer.” After processing, the status changes to Accepted on L2.

Transaction received and verified

Transaction is being processed by Sequencer

After the transaction data is uploaded to L1, the status will change to Accepted on L1, as shown in the figure below for this transaction:

Transaction data has been uploaded to L1

Although StarkNet transactions have a richer set of statuses, enabling users to know the progress of their transactions, uploading to L1 can take several hours, mainly due to the time needed to generate zero-knowledge proofs. Therefore, users rely on Sequencer’s Pre-Confirmation during this period.

StarkNet Explorer only shows Accepted on L1 status without accompanying information on L1 Finality or Block Confirmation. Users need to check whether enough blocks have been added after their transaction on L1 or if it has been Finalized.

Due to StarkNet’s performance limitations, long reliance on Pre-Confirmation, and lack of support for L1 Finality information in Explorer, the user experience for transaction inclusion confirmation on StarkNet needs improvement.

zkSync Transaction Inclusion Status

Similar to StarkNet, zkSync also has a PENDING status, which indicates that the node has received and verified the transaction without any issues. The transaction will then wait to be included and executed in an L2 block by the Sequencer. Transactions in PENDING status do not yet have any execution results.

Users can track the progress of their transactions through the status displayed on the zkSync Explorer.

Reading Tip: If the Sequencer processes transactions quickly enough, it might bypass the PENDING status and move directly to a state where the transaction has already been processed.

For a more detailed introduction to zkSync’s transaction process, follow this link: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

Transactions viewed on the zkSync Explorer also include Pre-Confirmation transactions, such as the one in the screenshot below. The Status is currently “zkSync Era Processed,” indicating that it has been arranged into an L2 block by the Sequencer:

The transaction has been arranged into an L2 block by the Sequencer and is currently waiting to be uploaded to L1 (Ethereum Sending).

After the Sequencer completes an L2 block, the block and its transactions go through three stages: Committed, Proven, and Executed. These respectively indicate “the block is uploaded to L1,” “the block’s validity is proven,” and “the L2 state post-execution of transactions within the block is updated to L1.” Below are examples of blocks and transactions in these different stages:

Batch 292700 has been uploaded to L1 and entered the Committed stage. Source: https://explorer.zksync.io/batch/292700

The status of transactions in Batch 292700 changes from Ethereum Sending to Ethereum Validating, indicating they are awaiting zero-knowledge proof validation of their validity.

Moving the arrow over the Ethereum Validating icon will also show the different stages, and the transaction link for the previous stage (Sending) will also be attached:

This transaction has entered the “Validating” stage. The transaction link for uploading Batch to L1 in the previous stage (Sending) can also be seen directly here.

Batch 292000 has had its validity proven, so it enters the Proven stage:

After a batch is proven, it enters the Proven state, with a link to the transaction executing the Prove action.

Transactions then move from “Validating” to “Executing,” which means they are waiting to be executed.

After a Batch is proven, there’s a waiting period (about 21 hours according to official documentation) before executing the transactions within it and updating the L2 state recorded on L1. This is a protective measure in the Alpha phase to ensure ample reaction time in case of bugs. Once the Batch is executed, it enters the final Executed stage:

After execution, the Batch enters the final Executed state, with a link to the transaction executing the Execute action.

The status of transactions within the Batch is also updated to “Executed.”

Compared to StarkNet, where transactions move from L2 to L1 in one step, zkSync breaks down the process from L2 to L1 into three more detailed stages: Committed → Proven → Executed. Although as a protective measure, the entire transaction process takes about a day, the Committed status allows users to quickly know if their transaction has been included (post-Committed, it’s not just Pre-Confirmation) without solely relying on trust in the Sequencer. Additionally, zkSync Explorer provides comprehensive data for each stage, enabling anyone to track the latest status of transactions and even verify the transitions between stages (e.g., from Committed to Proven, from Proven to Executed).

However, it’s important to note that as a protective measure in the Alpha phase, the zkSync Sequencer can currently modify historical records. This means that even though transactions can quickly move out of Pre-Confirmation into the Committed stage, the Sequencer can still remove user transactions from the historical record until they reach the Executed stage. Therefore, users still need to trust the Sequencer for up to a day.

L1 Can Also Support Pre-Confirmation

If it’s possible to know in advance who is responsible for producing blocks, then L1 can also support Pre-Confirmation. Taking Ethereum as an example, the actual block producer is the Builder, who can offer Pre-Confirmation services, providing users with an assurance of transaction inclusion. However, since the Builder does not have the guaranteed right to produce a particular block but must bid for the right to produce each block, the effectiveness of this Pre-Confirmation is relatively weak. Additionally, the strength of the Builder must be considered; if a Builder lacks competitive strength, it will be difficult for them to win the right to produce blocks, diminishing the value of their Pre-Confirmation service.

A better solution to avoid these issues would be for the Proposer to offer Pre-Confirmation services, as it is usually predetermined and certain which Proposer will propose which block. However, in the current PBS (Proposer-Builder Separation) architecture, the Proposer is only responsible for proposing blocks, while the Builder decides the content of the block. Therefore, the Proposer cannot directly insert a transaction into a block or ask the Builder to do so. This situation might change with future modifications to the PBS architecture, like adding an Inclusion List or allowing Proposers to participate in block production, enabling Proposers to offer Pre-Confirmation services.

Reading tip: For more information about PBS, please copy the link below to your browser to read: https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Improving Pre-Confirmation

Pre-Confirmation is just a verbal promise from a Builder or L2 Sequencer, with no obligation to fulfill it and no punishment mechanism for non-compliance. Can this promise be made more reliable? Yes, because the content of the commitment (e.g., “include this transaction in block 1350000”) made by the person responsible for producing blocks can be written as a conditional check. Thus, we can use smart contracts to regulate Builders or Sequencers, asking them to deposit collateral in the smart contract when offering Pre-Confirmation services and to sign the content of the commitment. If users find that Builders or Sequencers have not kept their promises, they can submit the commitment and signature to the smart contract for verification.

Although the application of such contracts is still in the proof-of-concept stage, the following link to a presentation video showcases one example of contract application:

https://www.youtube.com/ watch?v=Uw5HxSYXwYo

Summary

After an L1 transaction is included in an L1 block, the probability of a Re-org gradually decreases, and users’ confidence in their transaction being included increases.

L2 transactions have an additional workflow compared to L1 transactions: the phase of “L2 transaction being included in an L2 block and waiting to be uploaded to L1.” During this phase, since the data is not yet uploaded to L1, there’s still a possibility of changes, and thus the only assurance users have about their transaction inclusion is the verbal commitment from the Sequencer, known as Pre-Confirmation, Fast Confirmation, or Soft Confirmation.

If the Sequencer is malicious or encounters a bug, their commitments might be broken, potentially leading to a lack of confirmation for the user’s L2 transaction.

Currently, most L2s display the transaction status in their Explorers, including the Pre-Confirmation status, like Arbitrum/Optimism’s “Confirmed by Sequencer” or StarkNet’s “Accepted on L2.” Users should be aware of the time validity of the transaction inclusion assurance provided by these statuses.

If users do not want to trust the Sequencer’s Pre-Confirmation, they will need to wait longer and validate through information provided by the L2 Explorer about the L2 data being uploaded to L1.

Pre-Confirmation can include an economic incentive mechanism, such as penalties through smart contracts for Sequencers who break their promises, offering clearer protection to users.

The table below shows the guarantees of transaction inclusion and corresponding risk scenarios for different stages of L1 and L2 transactions: [Please note the table is not provided in the translation.]

Disclaimer：

1. This article is reprinted from [imToken Labs]. All copyrights belong to the original author [Nic]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.