Editor's note:

The Sequencer is an important component in the current Ethereum expansion plan Rollup. It is used to sequence transactions and perform related operations such as block creation, transaction acceptance, transaction sorting, transaction execution, and transaction data submission. Proposers ) is responsible for submitting state commitments to L1. Failure of these entities can lead to issues such as censorship or asset locking, and many current L2 solutions lack these critical capabilities, leaving a gap in failing to address potential failure issues.

At present, the two mechanisms of "self-ordering" to solve the problem of sequencer failure and "emergency exit" to solve the problem of proposer failure have not been fully prioritized in the design and implementation. shivam proposed implementation in the Celestia forum time intervals and having the proposer send scheduled messages to the smart contract at regular intervals to solve this problem.

TL;DR

In L2, sequencers and proposers play a crucial role. The sequencer is responsible for validating transactions and packaging them for transmission in L1, while the proposer submits state commitments to L1. Failure of these entities could lead to issues such as censorship or asset lockout, but there are few escape hatches available for any L2. This article will introduce solutions to solve this problem.

current situation

As of now, the L2 blockchain ecosystem faces potential challenges with orderer and proposer failures. The sequencer is responsible for validating and packaging transactions for L1 transmission, which may lead to risks such as censorship or shutdown. Likewise, the proposer is responsible for submitting state commitments to L1 and may face failures that cause asset locking issues.

These challenges are exacerbated by the fact that sequencers and proposers are primarily operated by centralized entities, introducing additional risks such as MEV exploitation or sequencer shutdown. Key aspects are not only the use of a decentralized sequencer, but also the successful implementation of fraud and validity proofs, as well as the introduction of an emergency exit mechanism.

In order to solve the problem of sequencer failure, solutions such as "self-ordering" and "queuing through L1" have been introduced. Similarly, for proposer failures, mechanisms such as "emergency exit" and "self-proposal" can be used. Unfortunately, emergency exits and self-sequencing are not sufficiently prioritized in design and implementation, which represents a significant security vulnerability. Additionally, many current L2 solutions lack these critical capabilities, leaving gaps that fail to address potential failure issues.

Information provided by L2beat shows that mechanisms designed to address sequencer and proposer failures are not reliably implemented.

How L2 implements self-ordering and emergency exit mechanisms

self-ordering

The backup policy allows ensuring forced inclusion in the event of a sequencer failure by forcing transactions to be included after a specified interval. This approach ensures that in the event that an L2 sequencer failure may cause transactions to be delayed or affected, these transactions can still be processed and verified on the main blockchain, maintaining the integrity and continuity of the entire transaction processing system.

The implementation interval is a technical safety measure designed to establish a buffer of time before forcing inclusion of transactions through Layer 1 in response to a sequencer failure. This time delay provides a controlled window to identify and resolve potential problems, perform appropriate system checks, and restore operational stability.

When the user wishes to force inclusion of a transaction, a specialized function must be called on the L1 rolling contract, which then relays the transaction to the L2 sequencer's delay queue. This delay queue serves two main purposes: first, as a temporary holding place for transactions waiting to be processed, and second, as a security precaution to prevent potentially malicious actors from engaging in unwarranted attempts to self-order. Transactions must be reviewed and subject to predetermined criteria before being included in the deferred queue. This prevents unauthorized or malicious attempts to modify the ordering process, ensuring the integrity and security of the L2 environment.

After a set time threshold has elapsed, transactions in the delay queue undergo a batch inclusion process that includes a series of mandatory checks. This time limit serves as a controlled tool to regulate the timing of transaction processing. Transactions accumulated in the delay queue during this period are aggregated into a batch and the inclusion process begins, assuming the preset validation tests pass successfully. The technical complexity comes from organizing this batch inclusion, and the system ensures that transactions comply with established standards before being integrated into L2.

EMERGENCY EXIT

The proposer needs to periodically send scheduled messages to the smart contract. This message is a precautionary measure to ensure the continued operational integrity of the proposer. Lack of such communication within the predetermined time frame will result in the proposer being declared non-operational or defective.

In the event that the proposer's operation is stopped or the specified message is not transmitted, an automatic mechanism must be initiated to perform freezing of assets on L2. The freezing process should include securely locking assets within specific smart contracts issued on L2. This step effectively prevents any subsequent transactions involving the frozen assets from occurring until the underlying issues with the proposer are resolved. This upgrade ensures that any attempts to transfer or modify frozen assets are blocked in an orderly manner by the system, reducing the potential hazards associated with faulty proposers.

Users can trigger an emergency exit mechanism, which is designed to allow users to regain ownership of their assets under certain scenarios, especially if the proposer is confirmed to be invalid. This mechanism is designed to be used only when the stated criteria clearly identify the proposer's non-functionality.

In order to regain ownership of their assets, users need to generate Merkel certificates proving their fund holdings. These Merkle proofs serve as cryptographic proof of a specific asset owned by the user at the time the asset was locked. Users then submit these Merkle proofs to the L1 contract, which then verifies the legitimacy and ownership of the presented proofs through a verification process. Only after these proofs have been rigorously verified, the Layer 1 contract is authorized to begin transferring locked assets to the user’s control.

in conclusion

This analysis highlights the importance of overcoming sequencer and proposer failures in L2 blockchains to ensure robust and secure transaction processing. Current issues and weaknesses, including a lack of prioritization in emergency exits and self-ordering, highlight the need for a comprehensive approach across the entire L2 ecosystem. Implementing these solutions can improve the overall reliability and robustness of L2 blockchain systems, giving consumers greater trust in the integrity of their transactions and assets.