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

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

Preliminary Knowledge:

• The entire process of L1 (Layer 1) transactions
• Reasons and impacts of Re-org occurrences
• Understanding the roles and operation methods in the current Ethereum PBS architecture
• 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 p2p network, awaiting inclusion in a block by either a Miner under the Proof of Work (PoW) consensus mechanism or a Proposer under the Proof of Stake (PoS) consensus mechanism. When a user notices their transaction has been included in the latest block, it is not yet certain that the transaction will be permanently recorded in the blockchain’s history. This uncertainty is due to the possibility of a “Re-org” (reorganization) occurring on the blockchain. Users must wait until the likelihood of a Re-org happening is sufficiently low to be confident that their transaction will be permanently recorded in the blockchain’s history.

L1 Transaction Process Illustrated

Even after a transaction is included in a block, a Re-org can still occur, meaning confirmation can only be assured once the probability of a Re-org becomes unlikely.

The likelihood and cost of a Re-org vary with each blockchain’s consensus algorithm and the market value of its assets. This document will not delve into the calculation methods for Re-org costs.

Understanding L2 Transactions

Transaction Process

L2 users generate and sign transactions, usually sending them directly to a Sequencer, who then includes these transactions in an L2 block. Subsequently, when the Sequencer posts the L2 block data back to L1 through an L1 transaction, users can see their transactions included in the latest L2 block.

However, it is important to note that since L2 block data is posted to L1 via an L1 transaction, it is still possible for an L1 Re-org to occur, potentially resulting in the L2 block not being permanently recorded in the blockchain’s history. This scenario is akin to an L2 Re-org, thus users must wait until the probability of an L1 Re-org is sufficiently low to be confident their transaction will be permanently recorded in the blockchain’s history.

L2 Transaction Process Illustrated

Users must first wait for their transaction to be included in an L2 block, then for the L2 block to be posted to L1 via an L1 transaction, and finally for the L1 transaction to be finalized.

Although L2 transactions involve an additional wait time for inclusion in an L2 block by the Sequencer compared to L1 transactions, this wait is generally short if the L2 block capacity is large and block generation is fast, as the main waiting period is for the L1 transaction to be confirmed. Thus, the overall user experience of L1 and L2 transactions is similar.

Pre-Confirmation/Fast Confirmation/Soft Confirmation

Users should personally verify that their L2 transactions, along with the L2 block, have been included in an L1 block, and even wait until the probability of a Re-org is sufficiently low to trust that their L2 transaction has been included.

But what if users are willing to trust the Sequencer? The Sequencer could be operated by the L2 development team or a reputable institution. If the Sequencer assures users immediately upon receiving their transactions that they will be included in a specific block, this guarantee may suffice for those willing to trust the Sequencer. It is similar to a user trusting their wallet application and not obsessively checking Etherscan for confirmation after being notified of a transaction inclusion.

Such guarantees provided by the Sequencer are referred to as Pre-Confirmation, Fast Confirmation, or Soft Confirmation. These are considered “preliminary” or “soft” assurances of transaction inclusion, not requiring the L2 transaction to be included in an L1 block. However, these are merely verbal commitments from the Sequencer, which may be forgotten due to a bug or deliberately broken by a malicious Sequencer, at worst resulting in a double-spend attack.

Subsequently, we will introduce various ways L2 transaction inclusion statuses are presented.

Arbitrum/Optimism Transaction Inclusion Status

Currently, users on Arbitrum or Optimism can almost immediately receive a transaction receipt after sending a transaction, indicating the result of the transaction execution. This signifies that the Sequencer has already locally sequenced and simulated the transaction, providing users with a Pre-Confirmation.

Learn More

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

For more detailed information on the Optimism transaction lifecycle, refer to the official documentation: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Trading Income Status for Arbitrum/Optimism

Currently, after users send a transaction on Arbitrum or Optimism, they can almost immediately get a transaction receipt (Transaction Receipt), which will contain the results of the transaction execution. This means that the Sequencer has sequenced the transaction locally and simulated it once. This transaction receipt is the Pre-Confirmation given to the user.

learn more

For a more detailed introduction to the transaction life cycle of Arbitrum, you can copy the link below to the browser to refer to the official document:

https://docs.arbitrum.io/tx-lifecycle

For a more detailed introduction to the transaction life cycle of Optimism, you can copy the link below to the browser and refer to the official document:

https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Check transaction income status on Arbitrum

The transactions seen on Arbitrum Explorer will include Pre-Confirmation transactions, that is, transactions that have not been uploaded to L1. For this transaction as shown in the figure below, you can see a Confirmed by Sequencer mark next to Block Number 145353000:

The picture above shows transactions that have only been confirmed by Sequencer but have not yet been uploaded to L1.

If it is a transaction that has been uploaded to L1 as shown in the figure below, its status has changed to 69 L1 Block Confirmations, which means that it has been uploaded to L1 and the Layer1 block containing the transaction data has been There are 69 blocks following it:

The L1 block containing this transaction data already has 69 blocks following it. The more blocks following it, the more secure it is.

Or for this transaction as shown in the screenshot below, the L1 block containing this transaction data already has 6174 blocks following it, which is already very safe.

But in fact, what can be done better here is to present it in combination with the Finality information of L1.

Simply telling the user how many L1 Block Confirmations there are is of limited help to the user, because the user has to understand and calculate the level of security represented by such a number of Block Confirmations. And since Layer1 (that is, Ethereum) already has a Finality mechanism like Casper FFG, Explorer can actually directly display whether the Layer1 block has been Finalized in Layer1. Currently, Optimism’s Explorer has implemented such a function.

Checking Transaction Receipt Status on Optimism

Transactions viewed on the Optimism Explorer may include those marked as Pre-Confirmation, indicating they have not yet been posted to Layer 1 (L1). As illustrated below, the transaction with Block Number 111526300 is tagged as “Confirmed by Sequencer”:

Transactions only confirmed by the Sequencer but not yet posted to L1

Currently, the Explorer seems to lack a clear definition for “Confirmed by Sequencer,” suggesting that “Sequencer confirmations are equivalent to a few block confirmations on L1.” This implies that being “Confirmed by Sequencer” means the transaction has been posted to L1 and has several blocks following it:

However, newly appearing transactions are also displayed as “Confirmed by Sequencer,” and even transactions from many days ago, which have passed the challenge period, remain in the “Confirmed by Sequencer” status:

Transactions from days ago still in the “Confirmed by Sequencer” status

Reading note: This situation might also be due to the Explorer presenting different status indicators in various places: “Confirmed By Sequencer” next to the Block Number informs users that the block has been confirmed by the Sequencer. To verify the post-L1 status, users must refer to other information, such as the “L1 State Batch” details discussed below.

Moreover, as shown in the screenshot below, a transaction that has been posted to L1 includes two additional pieces of information: “L1 State Batch Index” and “L1 State Root Submission Tx Hash.” These details represent which State Batch the L2 transaction is included in and through which L1 transaction this State Batch was posted to L1:

Clicking on “State Batch 3480,” its status is shown as Finalized, corresponding to the Finalized status on L1 (i.e., the Ethereum mainnet), which is a highly secure status achieved after accumulating votes from validators over two epochs.

△ State Batch 3480 is included in L1 Block 18457449, and Block 18457449 has been Finalized.

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

If a Batch has been posted but not yet Finalized on L1, it will display as Unfinalized:

State Batch 3494, though posted to L1, is included in an L1 Block that has not been Finalized：

Compared to the Arbitrum Explorer, the Optimism Explorer provides more detailed information (State Batch) and directly links L1 Finality information to the L2 Explorer, allowing users to know whether an L1 block has been Finalized, rather than making their own judgment based on the number of Block Confirmations for security level.

StarkNet Transaction Revenue Status

Currently, when users send transactions on StarkNet, they can quickly query the transaction receipt. However, the receipt often shows the transaction status as RECEIVED. This status indicates that the node has received the transaction and, after verification, found no issues. The transaction is waiting to be included in an L2 block by the Sequencer and executed. Transactions in the RECEIVED status will not yet have any results from execution. Users can check the progress of their transactions by viewing the transaction status displayed on the StarkNet Explorer.

Reading Tip: If the Sequencer processes transactions quickly enough, it may bypass the RECEIVED status and move directly to a processed state. For a more detailed introduction to the transaction process on StarkNet, you can copy the link below into your browser to consult the official documents.

Official Documents: StarkNet Transaction Life Cycle

Transactions seen on Starkscan, a StarkNet Explorer, also include Pre-Confirmation transactions. As shown in the following transaction, the current Status is “Accepted on L2,” indicating that it has been queued by the Sequencer into an L2 block:

Accepted on L2” means that it has been queued by the Sequencer into an L2 block, but not yet uploaded to L1.

The two statuses before “Accepted on L2” are Received and Pending, representing “the transaction has been received and verified” and “the transaction is being processed by the Sequencer,” respectively. After the transaction processing execution is complete, it will move to the “Accepted on L2” status:

The transaction has been received and verified.

The transaction is being processed by the Sequencer.

Once the transaction data is uploaded to L1, the status will change to “Accepted on L1,” as shown in the following transaction:

The transaction data has been uploaded to L1.

Although StarkNet transactions have a richer set of statuses to inform users of the processing progress, uploading transactions to L1 might still require a wait of several hours (possibly because generating zero-knowledge proofs takes longer). During this time, users rely on the Sequencer’s Pre-Confirmation.

Furthermore, the Explorer only displays “Accepted on L1” for transactions uploaded to L1, without accompanying information on L1 Finality or Block Confirmation. This means users have to check themselves whether the L1 block has enough subsequent blocks or has been Finalized.

Overall, due to StarkNet’s performance bottlenecks, users need to rely on Pre-Confirmation for an extended period, and the Explorer does not support L1 Finality information, leading to a less satisfactory user experience for transaction revenue confirmation. This is an area where StarkNet needs to improve in the future.

zkSync transaction revenue status

Similar to StakrNet, zkSync also has a PENDING state, which means that the node has received the transaction and there are no problems after the transaction is verified. It will wait to be included in the L2 block by the Sequencer and executed. However, no transaction will be executed in the PENDING state. the result of.

Users can know the processing progress of their transactions through the transaction status displayed on zkSync Explorer.

Reading tips:If the Sequencer is processed fast enough, it may be possible to directly skip the PENDING state and enter the state where the transaction has been processed.

For a more detailed introduction to the transaction process of zkSync, you can copy the link below and view it in your browser: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

The transactions seen on zkSync Explorer will also include Pre-Confirmation transactions, such as the transaction in the screenshot below. You can see that the Status is currently zkSync Era Processed, indicating that it has been queued into the L2 block by the Sequencer:

This transaction has been queued into the L2 block by Sequencer and is currently waiting to be uploaded to L1 (Ethereum Sending)

After the Sequencer completes the L2 block, the block and the transactions in it will then go through the three stages of Committed, Proven and Executed, which respectively means “the block has been uploaded to L1” and “the validity of the block has been proven”. And “the L2 status is updated to L1 after the transaction in the block is executed.” The following shows three blocks and transactions at different stages:

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

The current status of the transactions in Batch 292700 has changed from Ethereum Sending to Ethereum Validating, indicating that it is waiting to be verified by zero-knowledge proof to verify its 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.

The effectiveness of Batch 292000 has been proven, so it enters the Proven stage:

After the Batch is proven, it enters the Proven state, and a transaction link for executing the Prove action is attached.

The transactions inside will also enter the “Executing” stage from “Validating”, which is waiting to be executed.

When the Batch is proven, it will then enter a waiting period (official documents say it is about 21 hours) before executing the transactions inside and updating the L2 status recorded on L1. This is mainly due to a protection measure that is still in the Alpha stage to ensure that there is sufficient time to react when any bugs occur. When the Batch is executed, it will enter the final Executed phase:

After the Batch is executed, it enters the final Executed state, and a transaction link for executing the Execute action is attached.

The transaction status in the batch is also updated to “Executed”. Unlike StarkNet transactions, which are completed from Layer 2 (L2) to Layer 1 (L1) in one step, zkSync breaks down the process of transactions from L2 to L1 into three more detailed stages: Committed → Proven → Executed. Although this prolongs the entire transaction process to about a day as a protective measure, the Committed status allows users to quickly know whether their transaction has been included (once a transaction enters the Committed stage, it is no longer merely Pre-Confirmation), without continuously relying on trust in the Sequencer. Moreover, the zkSync Explorer provides comprehensive and complete data displays for different stages, allowing anyone to grasp the latest status of transactions and even personally verify the execution of transactions at each stage transition (e.g., from Committed to Proven, from Proven to Executed). However, it is important to note that, as a protective measure in the Alpha stage, the zkSync Sequencer can modify historical records. This indicates that even though transactions can quickly move beyond Pre-Confirmation to enter the Committed stage, the Sequencer can still remove user transactions from the historical records until they reach the Executed stage. Therefore, users still need to trust the Sequencer for up to a day.

Layer 1 can also support Pre-Confirmation

If it is known 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, giving users a guarantee of transaction inclusion. However, since the Builder does not necessarily have the right to produce a certain block but must bid for the right to produce each block, the effectiveness of Pre-Confirmation can be weaker. Additionally, the Builder’s competitiveness must be considered; if a Builder is not competitive enough, it will be difficult for them to secure the right to produce blocks, thus significantly reducing the reliability of their Pre-Confirmation services. To avoid these issues, a better approach would be to allow Proposers to provide Pre-Confirmation services, as it is usually predetermined and certain which Proposer will propose which block. However, in the current PBS architecture, Proposers only propose blocks, and the actual block production and content decision-making are done by Builders, so Proposers cannot directly insert a transaction into a block or demand a Builder to do so. In the future, if the PBS architecture changes, for example, by adding an Inclusion List or allowing Proposers to participate in block production, Proposers might have the opportunity to offer Pre-Confirmation services. For more information on PBS, please visit the provided link.

Improving Pre-Confirmation:

Pre-Confirmation is merely a verbal commitment by Builders or L2 Sequencers, with no obligation to fulfill the promise and no penalty mechanism for non-fulfillment. However, it is possible to make this commitment more reliable by using smart contracts to standardize Builders or Sequencers. They could provide Pre-Confirmation services while also depositing a bond in the smart contract, and sign the content when making a transaction inclusion promise. If users find that Builders or Sequencers have not fulfilled their promises, they can submit the promise content and the signature to the smart contract, which can then verify whether the promise has been kept. Although the application scenario of the aforementioned contract is still in the proof-of-concept stage, the link below shows a presentation video of one such contract application example.

Summary:

After L1 transactions are included in L1 blocks, the probability of re-organization decreases, and users’ confidence in transaction inclusion gradually increases. L2 transactions have an additional workflow compared to L1 transactions: “L2 transactions are included in L2 blocks and await uploading to L1.” However, since the data has not been uploaded to L1 in this stage, there is still a possibility of variance, so the assurance users can get about transaction inclusion at this stage is the verbal commitment from the Sequencer, known as Pre-Confirmation or Fast Confirmation/Soft Confirmation. If the Sequencer is malicious or simply encounters a bug, their promise can be broken, leading to a lack of confirmation for the user’s L2 transaction. Currently, most L2s display transaction statuses in their Explorers that include Pre-Confirmation status, such as Arbitrum/Optimism’s Confirmed by Sequencer or StarkNet’s Accepted on L2. When seeing such information, it’s important to pay attention to the time effectiveness of the transaction inclusion assurance provided. If users do not want to rely on the Sequencer’s Pre-Confirmation, they will need to wait longer and verify through the L2 Explorer’s information on L2 data being uploaded to L1. Pre-Confirmation can incorporate an economic incentive mechanism, such as penalizing Sequencers through smart contracts when they break their promises, providing users with clearer protection. The table below shows the guarantees of transaction inclusion and corresponding risk scenarios provided by L1 and L2 transactions at different stages of the transaction process.

Disclaimer：

1. This article is reprinted from [aicoin]. All copyrights belong to the original author [Foresight News]. 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.