Introduction to the complete process of L2 transactions and analysis of the security performance of each stage of the transaction process.
Written by: Nic @ imToken Labs
When can one be sure that an L2 (Layer2) transaction will be included in a block? When can one be sure that income from an L2 transaction will not be discarded due to a Re-org?
This article will introduce readers to the complete process of L2 transactions and analyze the security performance of each stage of the transaction process.
Preparatory Knowledge:
- Complete process of L1 (Layer1) transactions
- Reasons for and impact of Re-org
- Understanding the roles and operation of the PBS architecture in Ethereum
- Understanding the differences between Optimistic Rollup and Validity (ZK) Rollup
Understanding L1 Transactions
Transaction Process
After a user initiates a transaction and signs it, it is sent to the p2p network and awaits inclusion in a block by a Miner under the PoW consensus mechanism or a Proposer under the PoS consensus mechanism. Even when a user discovers that their transaction has been included in the latest block, they cannot be completely certain that the transaction will definitely be recorded in the blockchain's history. This is because the blockchain may experience a situation known as "Re-org." Users must wait until the probability of a certain block undergoing Re-org is low enough to be confident that the transaction will be recorded in the blockchain's history.
Understanding L2 Transactions
Transaction Process
After an L2 user generates a transaction and signs it, it is typically directly submitted to the Sequencer responsible for ordering transactions, who then includes the transaction in an L2 block. Subsequently, when the Sequencer writes the L2 block data back to L1 through an L1 transaction, the user can see their transaction included in the latest L2 block.
However, it is important to note that because L2 block data is uploaded to L1 through an L1 transaction, there is still a possibility of an L1 Re-org causing the L2 block to ultimately not be recorded in the blockchain's history. This is equivalent to an L2 Re-org. Therefore, users must wait until the probability of an L1 Re-org is sufficiently low to be confident that their transaction will be recorded in the blockchain's history.
Users first wait for the transaction to be included in an L2 block, then wait for the L2 block to be uploaded to L1 through an L1 transaction, and finally wait for the L1 transaction to be finalized.
Although compared to L1 transactions, L2 transactions involve an additional waiting period for the transaction to be included in an L2 block by the Sequencer, in situations where the L2 block capacity is large and the block generation speed is fast, this waiting period does not consume much time. This is because the majority of the waiting time is spent on confirming the income through L1 transactions. Therefore, overall, the user experience of L1 transactions and L2 transactions is similar.
However, if users are willing to make some sacrifices, can they achieve a better experience?
Pre-Confirmation/Fast Confirmation/Soft Confirmation
Users should personally witness the inclusion of an L2 block (containing L2 transactions) in an L1 block, and even wait until the probability of a Re-org is sufficiently low before believing that their L2 transaction has been included.
But what if users are willing to trust the Sequencer? Perhaps the Sequencer is operated by the development team of L2 or by a reputable institution. If the Sequencer assures users that their transaction will be included immediately, or will be included in the Xth block upon receiving the transaction, then this assurance is sufficient for users who are willing to trust the Sequencer. Just like a user who trusts the wallet they are using, they will not repeatedly check Etherscan after the wallet has already notified them that the transaction has been included.
This assurance provided by the Sequencer for transaction inclusion is called Pre-Confirmation, Fast Confirmation, or Soft Confirmation. It does not require waiting for the L2 transaction to be included in an L1 block, but it is only a verbal commitment from the Sequencer. The Sequencer may forget the original commitment due to a bug, or a malicious Sequencer may directly violate the commitment, resulting in a waste of user time at best, and being vulnerable to a "double spend attack" at worst.
Next, we will introduce several different ways of presenting the status of L2 transaction inclusion.
Arbitrum/Optimism Transaction Inclusion Status
Currently, after users submit transactions on Arbitrum or Optimism, they can almost immediately receive a transaction receipt, which contains the result of the transaction execution. This indicates that the Sequencer has already locally ordered the transaction and simulated its execution, and this transaction receipt serves as Pre-Confirmation for users.
Learn More
For a more detailed introduction to the transaction lifecycle on Arbitrum, you can refer to the official documentation by copying the following link into your browser:
Arbitrum Transaction Lifecycle Documentation
For a more detailed introduction to the transaction lifecycle on Optimism, you can refer to the official documentation by copying the following link into your browser:
Checking Transaction Inclusion Status on Arbitrum
On Arbitrum Explorer, transactions that include Pre-Confirmation, i.e., transactions that have been confirmed by the Sequencer but have not yet been uploaded to L1, can be seen. The following image shows an example of such a transaction, with the "Confirmed by Sequencer" label next to Block Number 145353000:
If it is a transaction like the one shown in the image below, which has already been uploaded to L1, its status has changed to 69 L1 Block Confirmations, indicating that it has been uploaded to L1 and the Layer1 block containing the transaction data has had 69 blocks appended to it:
The Layer1 block containing the transaction data has had 69 blocks appended to it, and the more blocks appended, the more secure it is.
Or as shown in the screenshot below, this transaction has had 6174 blocks appended to the Layer1 block containing the transaction data, making it very secure.
However, a better approach here would be to combine the L1 Finality information to present the data.
Simply informing the user of the number of L1 Block Confirmations has limited utility for the user, as the user still needs to understand and calculate the level of security represented by this number of Block Confirmations. Since Layer1 (i.e., Ethereum) already has Finality mechanisms such as Casper FFG, the Explorer can directly display whether the Layer1 block has been Finalized on Layer1. Currently, the Optimism Explorer has implemented this functionality.
Checking Transaction Inclusion Status on Optimism
On the Optimism Explorer, transactions also include Pre-Confirmation, i.e., transactions that have been confirmed by the Sequencer but have not yet been uploaded to L1, as shown in the following image. We can see that next to Block Number 111526300, there is a "Confirmed by Sequencer" label:
A transaction confirmed by the Sequencer but not yet uploaded to L1
However, the Explorer currently does not seem to clearly define the meaning of "Confirmed by Sequencer." It states that "Sequencer confirmations are equivalent to a few block confirmations on L1," indicating that "Confirmed by Sequencer" means that it has been uploaded to L1 and has had several blocks appended to it:
However, even the most recently appeared transactions are also displayed as "Confirmed by Sequencer," and even transactions from several days ago, which have already passed the challenge period, still have the status of "Confirmed by Sequencer":
The status of transactions from several days ago still remains at "Confirmed by Sequencer"
Reading Tip: The above situation may also be due to the Explorer displaying different status indicators in different places: "Confirmed By Sequencer" after Block Number is to inform the user that the block has been confirmed by the Sequencer, and the user needs to confirm the status after being uploaded to L1 through other information, such as the "L1 State Batch" information mentioned below.
Additionally, as shown in the screenshot below, a transaction that has been uploaded to L1 includes two additional pieces of information: "L1 State Batch Index" and "L1 State Root Submission Tx Hash." These two pieces of information represent the State Batch in which the L2 transaction is included and the L1 transaction through which this State Batch was uploaded to L1:
Clicking on "3480" for this State Batch, it can be seen that its status is Finalized, which corresponds to the Finalized status on L1 (i.e., Ethereum mainnet), indicating that it has successfully accumulated votes from two epochs of validators and is very secure.
△ State Batch 3480 was included in L1 Block 18457449, and Block 18457449 has been Finalized.
Source: https://etherscan.io/block/18457449
If a Batch has been uploaded but has not been Finalized on L1, it will be displayed as Unfinalized:
State Batch 3494 has been uploaded to L1, but the L1 Block containing this Batch has not been Finalized yet.
Compared to the Arbitrum Explorer, the Optimism Explorer provides more information (State Batch) for transactions, and it directly integrates L1 Finality information into the L2 Explorer, allowing users to know directly whether the L1 block has been Finalized, instead of having to judge the level of security corresponding to the number of Block Confirmations.
Transaction Inclusion Status on StarkNet
Currently, after users submit transactions on StarkNet, although they can quickly query the transaction receipt, the status displayed in the receipt is usually "RECEIVED." This indicates that the node has received the transaction, and after verification, the transaction is awaiting inclusion in an L2 block and execution. Transactions in the "RECEIVED" status do not yet have any transaction execution results. Users can check the processing progress of their transactions through the transaction status displayed on the StarkNet Explorer.
Reading Tip: If the Sequencer processes fast enough, it is possible to skip the RECEIVED status and go directly to the status where the transaction has been processed. For a more detailed explanation of the transaction process on StarkNet, you can copy the link below and paste it into your browser to access the official documentation.
Official Documentation: https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/
On Starkscan, the StarkNet Explorer, transactions also include Pre-Confirmation transactions. As shown in the image below, the Status of this transaction is currently "Accepted on L2," indicating that it has been included in an L2 block by the Sequencer:
"Accepted on L2" indicates that the transaction has been included in an L2 block by the Sequencer, but has not yet been uploaded to L1
The two statuses before "Accepted on L2" are Received and Pending, representing "transaction received and verified" and "transaction being processed by the Sequencer," respectively. After the transaction processing is complete, it will enter the "Accepted on L2" status:
Transaction received and verified
Transaction 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:
Transaction data has been uploaded to L1
Although StarkNet transactions have more detailed statuses that allow users to track the processing progress of their transactions, the time it takes for transactions to be uploaded to L1 may still require a wait of four to five hours (possibly due to the time required for generating zero-knowledge proofs). Therefore, during this time, users rely on the Sequencer's Pre-Confirmation.
Additionally, the Explorer only displays "Accepted on L1" for transactions uploaded to L1, without providing L1 Finality or Block Confirmation information. This means that users have to check whether there are enough blocks appended to the L1 block or if it has been Finalized on L1 by themselves.
Overall, due to the performance bottleneck of StarkNet itself, which requires users to rely on Pre-Confirmation for a long time, and the lack of support for L1 Finality information in the Explorer, the user experience for confirming StarkNet transactions is not very good, and this is an area that StarkNet needs to improve in the future.
Transaction Inclusion Status on zkSync
Similar to StarkNet, zkSync also has a PENDING status, indicating that the node has received the transaction and verified it, and it is waiting to be included in an L2 block by the Sequencer for execution. Transactions in the PENDING status do not yet have any transaction execution results.
Users can track the processing progress of their transactions through the transaction status displayed on the zkSync Explorer.
Reading Tip: If the Sequencer processes fast enough, it is possible to skip the PENDING status and go directly to the status where the transaction has been processed.
For a more detailed explanation of the zkSync transaction process, you can copy the link below and paste it into your browser to access: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum
On the zkSync Explorer, transactions also include Pre-Confirmation transactions, such as the transaction shown in the screenshot below, where the Status is currently "zkSync Era Processed," indicating that it has been included in an L2 block by the Sequencer:
This transaction has been included in an L2 block by the Sequencer and is currently waiting to be uploaded to L1 (Ethereum Sending)
After the Sequencer creates the L2 block, the block and the transactions inside it will go through three stages in sequence: Committed, Proven, and Executed, representing "the block has been uploaded to L1," "the validity of the block has been proven," and "the L2 status of the transactions inside the block has been updated to L1 after execution." The following images show blocks and transactions at different stages:
Batch 292700 has been uploaded to L1 and is in the Committed stage. Source: https://explorer.zksync.io/batch/292700
The status of the transactions inside Batch 292700 has changed from Ethereum Sending to Ethereum Validating, indicating that they are waiting for validation through zero-knowledge proofs.
When hovering over the Ethereum Validating icon, different stages are displayed, and the link to the transaction that uploaded the Batch to L1 in the previous stage (Sending) is also provided:
This transaction has entered the "Validating" stage, and the link to the transaction that uploaded the Batch to L1 in the previous stage (Sending) can be directly accessed here.
The validity of Batch 292000 has been proven, so it has entered the Proven stage:
Batch enters the Proven status after being proven, and the link to the transaction that executed the Prove action is provided.
The transactions inside will also transition from "Validating" to "Executing" stage, indicating that they are waiting to be executed.
After a Batch is proven, there will be a waiting period (approximately 21 hours according to official documentation) before the transactions inside are executed and the L2 status recorded on L1 is updated. This is mainly due to a protective measure added during the current Alpha phase to ensure sufficient time to react in case of any bugs. Once the Batch is executed, it will enter the final Executed stage:
The Batch enters the final Executed status after being executed, and the link to the transaction that executed the Execute action is provided.
The status of the transactions inside the Batch is also updated to "Executed"
Compared to StarkNet, where the transition of transactions from L2 to L1 is completed in one step, zkSync breaks down the process of transitioning transactions from L2 to L1 into more detailed three stages: Committed → Proven → Executed.
Although as a protective measure, this extends the overall transaction process time to approximately a day, the Committed status allows users to quickly know if their transactions have been included (transactions are no longer just in Pre-Confirmation once they enter Committed), without the continuous reliance on trust in the Sequencer.
Furthermore, the zkSync Explorer provides rich and comprehensive data display for different stages, allowing anyone to track the latest status of transactions through the Explorer and even 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 phase, the zkSync Sequencer is currently able to modify historical records.
This means that even though transactions can quickly move out of Pre-Confirmation and enter the Committed stage, the Sequencer can remove user transactions from the historical records before the transactions enter the Executed stage. Therefore, users still need to trust the Sequencer for a period of about a day.
L1 Can Also Support Pre-Confirmation
If it is 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 provide Pre-Confirmation services to give users assurance of transaction inclusion. However, because the Builder does not always have the right to produce a specific block and must bid for the right to produce each block, the effectiveness of this Pre-Confirmation will be limited. Additionally, the strength of the Builder must also be considered. If the Builder's competitiveness is not strong enough, it will be difficult for the Builder to obtain the right to produce blocks, and therefore, the Pre-Confirmation service provided by this Builder will be discounted.
To avoid the above issues, a better approach would be to have the Proposer provide Pre-Confirmation services, as the "which Proposer proposes the nth block" is usually pre-calculated and deterministic.
However, in the current PBS architecture, the Proposer only proposes blocks, and the actual block production and determination of block content are the responsibilities of the Builder. Therefore, the Proposer cannot directly include a specific transaction in a block or request the Builder to include a specific transaction. In the future, if the PBS architecture changes, such as by introducing an Inclusion List or allowing the Proposer to participate in block production, then the Proposer will have the opportunity to provide Pre-Confirmation services.
Reading Tip: For more information about PBS, please copy the link below and paste it into your browser to read: https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.
Improving Pre-Confirmation
Pre-Confirmation is only a verbal commitment from the Builder or L2 Sequencer, and there is no obligation for them to fulfill the commitment, nor are there any punishment mechanisms for non-compliance.
Is it possible to make this commitment more secure? In fact, it is possible, because the person responsible for producing blocks and the content of their commitment (e.g., "include this transaction in block 1350000") can be written as conditional checks. Therefore, we can use smart contracts to regulate the Builder or Sequencer, requiring them to provide a deposit when offering Pre-Confirmation services, and to sign the content of the commitment. When users find that the Builder or Sequencer has not fulfilled the commitment, they can submit the commitment content and the counterparty's signature to the smart contract, which can then check whether the commitment has been fulfilled (e.g., "include this transaction in block 1350000").
Although the application of the above contract is still in the conceptual verification stage, the video in the link below discusses an example of one of the contract's applications. For more details, please copy the link below and paste it into your browser to watch: https://www.youtube.com/watch?v=Uw5HxSYXwYo
Conclusion
- The probability of Re-org occurring after L1 transactions are included in an L1 block will gradually decrease, and users' confidence in transaction inclusion will gradually increase.
- The additional transaction workflow for L2 transactions compared to L1 transactions is the stage of "L2 transactions being included in an L2 block and waiting to be uploaded to L1."
- However, in the additional transaction workflow for L2 transactions compared to L1 transactions, because the data has not yet been uploaded to L1 at this stage, there is still a possibility of variables changing. Therefore, the guarantee that users can obtain at this stage regarding transaction inclusion is the Sequencer's verbal commitment, known as Pre-Confirmation or Fast Confirmation, Soft Confirmation.
- If the Sequencer is malicious, or if there is simply a bug, the commitment made by the Sequencer may be violated, leading to the lack of confirmation of the user's L2 transactions.
- Currently, most L2s present transaction statuses in their Explorer that include the Pre-Confirmation status, such as "Confirmed by Sequencer" in Arbitrum/Optimism or "Accepted on L2" in StarkNet. When seeing such information, please pay attention to the temporal effectiveness of the transaction inclusion guarantee provided by this information.
- If you do not want to trust the Pre-Confirmation provided by the Sequencer, you will need to wait a little longer and verify the information provided by the L2 Explorer regarding the upload of L2 data to L1.
- Pre-Confirmation can be designed with economic incentive mechanisms, for example, in the event of the Sequencer violating the commitment, punishment can be carried out through a smart contract, providing users with clearer guarantees.
The table below shows the transaction inclusion guarantees provided by L1 and L2 transactions at different stages of the transaction process, along with the corresponding risk situations:
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
