Interpreting the whole process of L2 transaction implementation: what is the security performance of each stage?

Author: Nic@ imToken Labs

When can I be sure that an L2 transaction will be included in a block? When can I be sure that revenue from an L2 transaction will not be discarded because of Re-org?

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

Prerequisites:

• The entire process of L1 (Layer 1) transactions
• Causes and effects of Re-org
• Understand Ethereum’s current role in the PBS architecture and how it works
• Understand the differences between Optimistic Rollups and Validity (ZK) Rollups

Learn about L1 transactions

TRANSACTION PROCESS

Diagram of the L1 transaction flow

Re-org is still possible after the transaction income Block, and it is necessary to wait until the re-org is unlikely to occur to be confident that the transaction has been finalized.

The probability and cost of Re-org will vary depending on the Consensus Algorithm of a chain and the Market Cap of the asset, and the calculation of Re-org cost will not be introduced here.

Learn about L2 transactions

TRANSACTION PROCESS

After the L2 user generates and signs the transaction, it is usually sent directly to the Sequencer responsible for sorting the transaction, and the Sequencer collects his transaction into the L2 Block. Then, when Sequencer writes L2 Block data back to L1 through an L1 transaction, the user can see that their transaction is included in the latest L2 Block.

However, it should be noted that because the L2 Block data is uploaded to L1 through L1 transactions, it is still possible to encounter a situation where L1 Re-org occurs, resulting in the L2 Block not being written into the history of the Blockchain in the end, that is, equivalent to L2 Re-org, so the user still has to wait for the probability of L1 Re-org to be low enough to be sure that his transaction will be written into the history of the Blockchain.

Diagram of the L2 transaction flow

The user first waits for the transaction to be included in the L2 Block, then waits for the L2 Block to be uploaded to L1 through an L1 transaction, and finally waits for the L1 transaction to be finalized.

Although compared with L1 transactions, L2 transactions have an additional period of time to wait for L2 transactions to be included in L2 blocks by Sequencer, but in fact, when the L2 block size is large enough and the block production speed is fast enough, this waiting time will not take much time, because the waiting time will mainly spend L1 transactions on the recognition of revenue, so overall, the experience of L1 transactions and L2 transactions is similar.

But if the user is willing to make some sacrifices, can it be exchanged for a better experience?

Pre-Confirmation/Fast Confirmation/Soft Confirmation

The user should see the L2 Block (containing L2 transactions) being included in the L1 Block, and even wait until the probability of Re-org occurrence is low enough to believe that his L2 transaction has been earned.

But what if the user is willing to trust Sequencer? Maybe Sequencer is run by the L2 development team, run by a reputable organization, and if Sequencer assures the user that his transaction will be paid immediately, at the Xth Block, then this guarantee is sufficient for the user who is willing to trust Sequencer. Just like if a user trusts the Wallet he is using, he will not suspiciously go to Etherscan to double-check after the Wallet has alerted him that the transaction has been paid.

The Transaction Income Guarantee provided by this Sequencer is called Pre-Confirmation, Fast Confirmation, or Soft Confirmation, which can be understood as an “early” or “soft” transaction revenue guarantee. It does not need to wait for L2 transactions to be included in the L1 block, but it is only a verbal promise given by Sequencer, and Sequencer may forget the original promise due to bugs or malicious Sequencer will directly violate the promise, which can waste user time or be “Double Spend Attack”.

Next, we’ll look at some of the different ways in which the revenue status of L2 transactions is presented.

Transaction revenue status of Arbitrum/Optimism

At present, users who send a transaction on Arbitrum or Optimism can almost immediately get a Transaction Receipt, which will be the result of the transaction execution. This means that Sequencer has already sequenced and simulated the execution of the transactions locally, and this transaction receipt is the pre-confirmation for the user.

To learn more about Arbitrum, a more detailed description of the transaction lifecycle can be copied to the following link to the browser reference official document:

For a more detailed introduction to the transaction lifecycle of Optimism, please copy the following link to the browser reference official document:

Check Transaction Revenue Status on Arbitrum

The transactions you see on the Arbitrum Explorer will contain Pre-Confirmation transactions, that is, transactions that have not yet been uploaded to L1, as shown in the following figure, you can see that there is a Confirmed by Sequencer indicator next to the Block Number 145353000:

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

If the transaction 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 contains the transaction data Block and there are 69 Block behind it:

The L1 Block containing this transaction data already has 69 Blocks behind it, and the more Blocks that follow it, the more secure it is.

Or the transaction shown in the screenshot below, the L1 Block containing this transaction data has 6174 Blocks behind it, which is already very secure.

But what can be done better here is to combine the L1 finality information.

Simply telling the user how many L1 Block Confirmations there are is is limited help to the user, because the user has to understand and calculate the security level represented by such a number of Block Confirmations. And since Layer 1 (i.e. Ethereum) already has a finality mechanism such as Casper FFG, the Explorer can actually directly show whether the Layer 1 Block is currently finalized in Layer 1. Currently, Optimism’s Explorer has implemented such a feature.

Check Transaction Earnings Status on Optimism

The transactions we see on the Optimism Explorer will also include Pre-Confirmation transactions, that is, transactions that have not yet been uploaded to L1, as shown in the following figure, we can see that there is a Confirmed by Sequencer symbol next to the Block Number 111526300:

Transactions that have only been confirmed by Sequencer but have not yet been uploaded to L1

However, the Explorer doesn’t seem to have a clear specification of what Confirmed by Sequencer means, saying “Sequencer confirmations are equivalent to a few block confirmations on L1.”, indicating that Confirmed by Sequencer represents a number of Block that have been uploaded to L1 and have been followed by several :

But in fact, the latest transaction is also shown as Confirmed by Sequencer, and even dozens of days ago, the status of the transaction that has passed the challenge period is still Confirmed by Sequencer:

Dozens of days ago, the transaction status was still stuck at “Confirmed by Sequencer”

Reading tip: The above situation may also be that the explorer marks different states in different places: the Confirmed By Sequencer after the Block Number tells the user that the Block has been confirmed by the Sequencer, and the user has to confirm the state after uploading to L1 through other information, such as the “L1 State Batch” information mentioned below.

In addition, the transaction that has been uploaded to L1 as shown in the screenshot below has two additional 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 was included and the L1 transaction through which the State Batch was uploaded to L1:

Click on the “3480” State Batch, you can see that its state is Finalized, which corresponds to the Finalized state of L1 (that is, the Ethereum Mainnet), which is a very secure state that has successfully accumulated the votes of two Epoch validators.

△ State Batch 3480 has been acquired in L1 Block 18457449, and Block 18457449 has been finalized.

Source:

If the batch has been uploaded but has not been finalized in L1, it will be displayed as Unfinalized:

Although the State Batch 3494 has been uploaded to L1, the L1 block that is included in the batch has not yet been finalized.

Compared with the Arbitrum Explorer, the Optimism Explorer provides more information (State Batch) for transactions, and it will directly string the L1 Finality information to the L2 Explorer, so that the user can directly know whether the L1 Block has been finalized, rather than judging the security degree corresponding to the number of Block Confirmations.

StarkNet’s Trading Earnings Status

At present, after the user sends a transaction on StarkNet, although the receipt of the transaction can be queried quickly, the transaction status displayed in the receipt will usually be in the RECEIVED state, which means that the Node has received the transaction and there is no problem after the transaction is verified, and will wait for the transaction to be received by Sequencer L2 Block and executed, while the transaction in the RECEIVED state will not have any transaction execution result. Users can check the progress of their transactions through the transaction status displayed on StarkNet Explorer.

Reading tip: If Sequencer processes fast enough, it’s possible to skip the RECEIVED state and go to the state where the transaction has already been processed. For a more detailed introduction to StarkNet’s trading process, you can copy the link below to view the official documents in your browser.

Official Documents: _and_concepts/Network_Architecture/transaction-life-cycle/

The transactions seen on Starkscan, the StarkNet Explorer, will also include Pre-Confirmation transactions, as shown in the following figure, you can see that the Status is currently Accepted on L2, which means that it has been ranked into the L2 Block by Sequencer:

“Accepted on L2” means that it has been placed in an L2 block by Sequencer, but has not yet been uploaded to L1

The first two states of Accepted on L2 are Received and Pending, which means that “the transaction has been received and verified” and “the transaction is being processed by Sequencer”, and the transaction will enter the state of Accepted on L2 after the transaction is executed:

The transaction is received and verified

The 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 following figure:

Transactional data has been uploaded to L1

Although StarkNet’s transactions have a richer state that allows users to know the progress of the transaction, it may take four or five hours for the transaction to be uploaded to L1 (probably because it takes a long time to generate Zero-Knowledge Proof), so users during this time rely on Sequencer’s pre-confirmation.

In addition, Explorer only displays Accepted on L1 for transactions uploaded to L1, and does not have the information of Finality or Block Confirmation with L1, which means that users have to check whether there are enough Block in L1 Block or whether they have been finalized.

Overall, because of the performance bottleneck of StarkNet itself, users need to rely on Pre-Confirmation for a long time, and Explorer does not support L1 finality information, resulting in a poor experience of StarkNet transaction revenue recognition, which is where StarkNet needs to be improved in the future.

zkSync’s Transaction Revenue Status

Similar to StakrNet, zkSync also has a PENDING state, which means that Node has received the transaction and the transaction has been verified without problems, it will wait for the transaction to be Block and executed by Sequencer L2, while the transaction in the PENDING state will not have any transaction execution result.

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

Reading tip: If Sequencer processes fast enough, it’s possible to skip the PENDING state and go to the state where the transaction has already been processed.

For a more detailed introduction to the transaction process of zkSync, you can copy the following link to view it in your browser:

The transactions you see on the zkSync Explorer will also include the Pre-Confirmation transactions, such as the one in the screenshot below, you can see that the Status is currently zkSync Era Processed, which means that it has been ranked into the L2 Block by Sequencer:

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

After Sequencer has created an L2 Block, the Block and the transactions in it will go through three phases in sequence: Committed, Proven, and uted, indicating that “Block has been uploaded to L1”, “Block validity has been proven”, and “L2 status has been updated to L1 after the Block transaction has been executed”. Block and transaction at different stages are shown below:

Batch 292700 has been uploaded to L1 and is in the Committed phase. Source:

The current state of the transaction in Batch 292700 has changed from Ethereum Sending to Ethereum Validating, indicating that it is waiting to be verified by Zero-Knowledge Proof.

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

This transaction enters the “Validating” stage, and the link to the transaction that uploaded Batch to L1 in the previous stage (Sending) can also be seen here.

The effectiveness of Batch 292000 has been proven, so enter the Proven phase:

After the Batch is proven, it enters the Proven state with a link to the transaction that executes the Prove action.

The transaction will also move from “validating” to “uting”, that is, waiting to be executed.

When the batch is proven, it then goes into a waiting period (about 21 hours in official documents) before the transaction inside is executed and the L2 state recorded on L1 is updated. This is mainly due to a safeguard that has been added in the alpha phase to ensure that there is enough time to react to any bugs that arise. When the batch is executed, it enters the final uted phase:

After the batch is executed, it enters the final uted state with a transaction link that executes the ute action.

The transaction status in Batch has also been updated to “uted”

In contrast to StarkNet, where L2 to L1 transactions are completed in one step, zkSync’s process of moving L2 to L1 is broken down into three more detailed stages: Committed → Proven → uted.

While the entire transaction process is extended to about a day or so as a safeguard, the Committed state allows users to quickly know if a transaction has been earned (and is no longer just a pre-confirmation once the transaction enters Committed) without having to rely on trust in Sequencer on an ongoing basis.

In addition, zkSync Explorer provides rich and complete data display for different stages, so that anyone can grasp the latest status of transactions through the explorer, and even be able to personally verify the transaction execution of each stage transition (such as from Committed to Proven, from Proven to uted).

However, it should be noted that as a protection measure for the alpha phase, the history can be modified by zkSync Sequencer at this time.

This suggests that even though a transaction can quickly move out of pre-confirmation and into the committed phase, Sequencer can actually remove a user transaction from the history before the transaction enters the uted phase. Therefore, consumers still need to trust Sequencer for up to a day.

L1 can also support Pre-Confirmation

If you can know in advance who is responsible for producing blocks, then L1 can also support pre-confirmation.

Taking Ethereum as an example, the person who actually produces blocks is the Builder, and the Builder can provide Pre-Confirmation services to give users a transaction income guarantee. But because the Builder does not necessarily get the right to a certain output and a certain Block, but must bid for the right to each Block output, so the effectiveness of this Pre-Confirmation will be relatively poor, and the strength of the Builder must be considered, if the Builder is not competitive enough, then it is difficult for the Builder to obtain the right to produce Block, so the Pre-Confirmation provided by the Builder The service will be greatly compromised.

If you want to avoid the above problems, it is better to have Proposer provide the Pre-Confirmation service, because the “which Proposer will propose the first Block” is usually a pre-calculated, deterministic situation.

However, because in the current PBS architecture, Proposer only proposes the role of Block, and the role of actually making Block and determining the content of Block is Builder, so Proposer cannot directly stuff a transaction into a Block or ask Builder to stuff a transaction. When the PBS architecture changes in the future, such as adding an Inclusion List or allowing Proposers to participate in block production, Proposer will have the opportunity to provide Pre-Confirmation services.

Reading Tip: For more information about PBS, please copy the link below to read in your browser: _4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Improve Pre-Confirmation

Pre-Confirmation is just a verbal promise by the Builder or L2 Sequencer, and the other party has no obligation to fulfill the promise, and there is no penalty mechanism for non-fulfillment.

Is it possible to make this promise more assured? Actually, yes, because the person responsible for producing the Block and the content of his promise (e.g. “in the 1,350,000 Block the revenue transaction”) can be written as a condition check. Therefore, we can use the smart contract to regulate the Builder or Sequencer, ask them to provide Pre-Confirmation services when collateralizing the deposit in the Smart Contract, and sign the content when giving the promise of transaction income, when the user finds that the Builder or Sequencer has not fulfilled the commitment, the promised content and the other party’s signature can be sent to the Smart Contract, and the Smart Contract can check whether the commitment has been fulfilled (such as “in the first 1,350,000 Block Revenue for this transaction”).

Although the application scenario of the above contract is still in the proof-of-concept stage, the presentation video shown in the link below tells an example of one of the contract applications, please copy the link below to view the details in your browser:

Summary

• After L1 transactions are included in L1 blocks, the probability of Re-org will gradually drop, and users’ confidence in transaction revenue will gradually rise.
• One more transaction workflow for L2 transactions than L1 transactions is the stage where L2 transactions are included in L2 blocks and waiting to be uploaded to L1.
• However, in the transaction workflow where L2 transactions are more than L1 transactions, because the data has not yet been uploaded to L1 at this stage, there is still the possibility of variables, so the guarantee of transaction income that users can obtain at this stage is Sequencer’s verbal promise, which is called Pre-Confirmation or Fast Confirmation, Soft Confirmation.
• If Sequencer is malicious, or if there is a simple bug, then the promise made by Sequencer may be violated, resulting in no revenue recognition for the user’s L2 transactions.
• Currently, most L2 transaction statuses in their Explorer include a Pre-Confirmation status, such as Confirmed by Sequencer for Arbitrum/Optimism or Accepted on L2 for StarkNet. When you see such information, please pay attention to the time validity of the transaction revenue guarantee provided by this information.
• If you don’t want to trust the Pre-Confirmation provided by Sequencer, you will need to wait a little longer and verify with the information provided by the L2 Explorer about the L2 data being uploaded to L1.
• Pre-Confirmation can be coupled with the design of economic incentives, such as penalties through Smart Contract when Sequencer violates commitments, so that users can get clearer protection.

The table below illustrates the transaction revenue guarantee and the corresponding risk scenarios provided by L1 transactions and L2 transactions at different stages of the transaction process: