Skip to main content
Mechanisms

Forced transactions

Status

🚧 Forced transactions are not yet live. This documentation describes the intended design.

Forced transactions allow users to submit L2 transactions directly to the L1 with a guaranteed processing deadline on the L2. This manual submission mechanism ensures that users can submit transactions even when the normal L2 path is blocked or delayed.

info

In the case of the Linea public network, the L1 is Ethereum which serves as the finality layer.

What are forced transactions?​

Forced transactions protect users against sequencer censorship or failure. If the sequencer is down or becomes uncooperative, users retain the ability to send transactions and withdraw assets at any time by submitting them directly to L1, bypassing the sequencer entirely. To undertake a forced transaction, the user submits a signed L2 transaction directly to L1.

Forced transactions are guaranteed to be processed by the sequencer within a specified block deadline. Typically, the sequencer will process the transaction well before this deadline — the deadline is the latest acceptable block, not the target block. If the sequencer fails to process the forced transaction before its deadline, the L1 proof verification transaction for that batch will revert. As a result, the batch cannot be finalized on Ethereum. This potential for batch failure effectively forces the sequencer to process the transaction else the rollup cannot make forward progress.

Forced transactions are chained using a rolling hash that commits to the complete ordered sequence of forced transactions, ensuring processing and storage. This mechanism prevents skipped forced transactions, unauthorized inserted transactions, and reordering attacks.

Processing vs. execution​

Note that forced transactions guarantee inclusion not success. For example, while sequencer's role is to process the transaction, the transaction may still execute and revert. This means that a forced transaction successfully processed by the sequencer can still fail on the L2.

After a forced transaction is processed by the sequencer, the prover attempts to generate a zero-knowledge proof attesting to the validity of the state transition for that batch. At this stage, the transaction may fail to execute on the L2 for reasons that include:

Failure reasonDescription
Invalid nonceThe signer's nonce on L2 has changed since the transaction was signed. Another transaction may have executed first.
Insufficient gasThe gasLimit specified is too low for the transaction to complete.
Insufficient balanceThe signer doesn't have enough ETH on L2 to cover value + (gasLimit * maxFeePerGas).
Contract revertThe target contract's logic reverted the call (require failed, custom error, etc.).
Out of gas during executionComplex computation exhausted the gas limit mid-execution.
Invalid signatureEdge cases where the signature is technically valid but doesn't match L2 state.

Forced transaction lifecycle​

When a user submits a forced transaction, the following components validate and process the transaction:

  • ForcedTransactionGateway: Validates and submits the transaction to the LineaRollup, and generates a rolling hash.
  • LineaRollup: The Linea rollup and message service contract that stores the transaction.
  • Coordinator: Forwards the transaction to the sequencer for processing.
  • Sequencer: Processes the transaction before the deadline.
  • Prover: Generates a proof of the transaction and includes it in the finalization proof.

Step 1: Submission​

When a user submits a forced transaction to the ForcedTransactionGateway, the gateway calculates the deadline with a buffer, validates that the gas limit is within the allowed range, validates the currentFinalizedState, and submits the transaction to the LineaRollup contract.

Step 2: Ordering​

The LineaRollup stores the transaction in a queue of forced transactions, generating a Minimal Multiplicative Complexity (MiMC)-based rolling hash.

Step 3: Processing​

The coordinator listens for when the LineaRollup contract emits a ForcedTransactionAdded event and retrieves the corresponding forced transaction. It then forwards the transaction to the sequencer for processing before the deadline.

Once processed, the prover generates a proof of the transaction and the corresponding rolling hash and submits the proof to the finalization layer.

The complete lifecycle of a forced transaction is as follows:

LineaRollup (L1): Refers to the smart contract that provides the Linea rollup and L1 message service. This contract is deployed on Ethereum and stores forced transactions, maintains rolling hashes, enforces deadlines, and verifies zero-knowledge proofs.

Next steps​