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 through L1 with a guaranteed processing deadline on the L2. This provides a fallback submission path for users when the normal L2 transaction submission route, through L2 RPC providers, is unavailable, unreliable, or censoring.

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 censorship or unavailability of the normal L2 submission path. If L2 RPC providers are unreachable, refusing to relay, or otherwise unreliable, users retain the ability to submit transactions and withdraw assets by sending them through L1. To undertake a forced transaction, the user submits a signed L2 transaction to the ForcedTransactionGateway contract on L1.

Forced transactions do not bypass the sequencer; the sequencer is still required to produce blocks and process them. What they bypass is the normal L2 RPC submission path. Once stored on L1, a forced transaction is guaranteed to be processed by the sequencer within a specified block deadline. Typically, the sequencer will process the transaction well before this deadline, which 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​

Forced transactions guarantee processing, not necessarily inclusion or successful execution. The sequencer is required to process each forced transaction before its deadline, but processing can still result in the transaction being rejected or failing on the L2.

A forced transaction can be rejected outright, and proven invalid rather than included, in cases such as targeting an L2 deny-listed address or calling an invalid or unsupported precompile. In other cases, the transaction is included in a block but reverts during execution.

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​

Was this page helpful?