Forced Inclusion

Arbitrum's sequencer provides a soft guarantee of transaction inclusion with a forced inclusion fallback. Users can submit transactions directly to the sequencer for fast, ordered inclusion. If the sequencer is unresponsive or censoring, users can force their transaction into the Arbitrum Inbox on Layer 1 after a delay.

• Forced Inclusion Path: Transactions are submitted as delayed inbox messages on Ethereum L1, which the sequencer must process within a challenge period (~1 week).
• Key Feature: This creates a strong censorship resistance guarantee while optimizing for the common case of a honest sequencer.

The Optimism protocol (OP Mainnet) implements forced inclusion through its canonical transaction chain. If the Sequencer is malicious or offline, users can submit transactions directly to a queue on the Ethereum L1 contract. The sequencer is required to include transactions from this queue in the order received, enforced by the protocol's fraud proof or fault proof system.

• Enforcement: The verifier nodes can challenge a sequencer that ignores the L1 queue, making censorship economically irrational.
• Design Goal: Ensures liveness and permissionlessness as foundational properties of the rollup.

Fuel, an optimistic rollup, implements forced inclusion via its parallelized UTXO model. Transactions specify their exact inputs (coins). A block producer cannot exclude a valid transaction that spends specific UTXOs without invalidating the chain's state, as those UTXOs become unspendable. This creates a form of cryptographic forced inclusion.

• Core Mechanism: Relies on stateful validity proofs where transaction validity is independent of order.
• Advantage: Provides strong censorship resistance and enables parallel transaction execution.

While Bitcoin lacks a protocol-level forced inclusion rule, users have two fee-based market mechanisms to compel inclusion: Replace-By-Fee (RBF) and Child-Pays-For-Parent (CPFP).

• RBF: Allows a sender to replace a stuck, low-fee transaction with a new one paying a higher fee, incentivizing miner inclusion.
• CPFP: Allows a receiver of an unconfirmed transaction output to spend it in a new, high-fee transaction, forcing miners to include both to collect the fee.
• Nature: These are economic incentives, not cryptographic guarantees, making them weaker than protocol-enforced methods.

Starknet ensures message inclusion from Ethereum L1 to the Starknet L2 via a forced transaction mechanism. Messages sent to Starknet's L1 messaging contract must be included and processed by the sequencer in the next L2 block. The system's state transition integrity, backed by STARK validity proofs, guarantees that the sequencer cannot ignore these L1 messages without creating an invalid state root.

• Guarantee: Provides strong liveness for cross-chain communication (L1→L2).
• Foundation: Relies on the verifier contract on L1 rejecting state updates that omit mandatory messages.

Forced inclusion is a primary tool for censorship resistance. It allows users to submit transactions directly to block builders via a side channel (like a private RPC), guaranteeing they will be included in the next block, even if all public mempools are censoring them. This is critical for time-sensitive operations like liquidations or governance votes.

• Mechanism: Relies on block builder compliance with protocol rules.
• Limitation: Requires a willing, honest builder; a fully malicious builder coalition could still ignore the transaction.

Transactions submitted via forced inclusion are highly vulnerable to Maximal Extractable Value (MEV) extraction. Because they must be included, searchers and builders can precisely front-run or sandwich them with high predictability.

• Example: A forced-inclusion DEX swap reveals its intent, allowing a searcher to place orders before and after it to profit from the price impact.
• Mitigation: Users must accept potentially worse execution prices as the cost for guaranteed inclusion.

The security of forced inclusion depends on the existence of at least one honest builder. This creates centralization pressure, as users will gravitate towards a few large, reputable builders they trust to honor inclusion commitments.

• Risk: If a single builder dominates the market, it becomes a central point of failure and potential censorship.
• Protocol Design: Systems like Ethereum's PBS (Proposer-Builder Separation) attempt to separate block building from proposing to mitigate this risk.

Implementing forced inclusion requires careful protocol design to prevent Denial-of-Service (DoS) attacks. Malicious users could spam the inclusion channel with low-fee or invalid transactions.

• Common Safeguards:
  • Bonding/Slashing: Requiring a stake or bond that is slashed for invalid submissions.
  • Rate Limiting: Capping the number or size of forced transactions per block.
  • Fee Minimums: Enforcing a base fee to make spam costly.

Forced inclusion often relies on a relayer network (e.g., Flashbots Protect, Taichi Network) to receive and forward transactions to builders. This introduces new trust assumptions.

• User Risks: The relayer could censor, delay, or leak transaction information.
• Privacy: While bypassing public mempools, transactions are still visible to the relayer and the builder, creating a smaller trust set than fully private solutions like zk-SNARKs.

The ultimate strength of forced inclusion is defined by protocol-level enforcement. In Ethereum, this is envisioned through inclusion lists (e.g., EIP-7547), where block proposers must include specified transactions, making censorship a slashable offense.

• Weak Guarantee: Current builder-level inclusion relies on social consensus and reputation.
• Strong Guarantee: Protocol-level lists move the guarantee from the builder market to the consensus layer, significantly enhancing security.

The process by which a block builder or sequencer arranges transactions within a block. Forced inclusion is a specific rule that overrides this ordering to guarantee certain transactions are processed, regardless of typical fee-based priority.

• Central Problem: Without forced inclusion, validators could censor or indefinitely delay specific transactions.
• Contrast: Normal ordering is a First-Price Auction; forced inclusion acts as a priority queue bypass.

The profit a validator can make by including, excluding, or reordering transactions in a block. Forced inclusion directly combats a form of MEV known as censorship.

• Attack Vector: A validator might exclude a profitable arbitrage or liquidation transaction to capture the opportunity themselves later.
• Defense: Forced inclusion ensures user transactions critical to DeFi protocols (like liquidations) cannot be censored for MEV extraction.

A two-step cryptographic technique used to submit information without initially revealing it. This is a common implementation method for forced inclusion to prevent front-running.

• How it works:
  1. Commit: User submits a hash of their transaction data.
  2. Reveal: In a later block, they submit the full data. The protocol forces inclusion of the reveal transaction if the commit was valid.
• Use Case: Essential for fair auctions and voting where the content must be hidden initially.

A fundamental property of decentralized networks ensuring transactions cannot be arbitrarily blocked. Forced inclusion is a protocol-level guarantee that enhances censorship resistance.

• Without it: A single validator or cartel could filter transactions based on origin, contract, or content.
• With it: Users have a cryptoeconomic guarantee that their transaction will eventually be included, as long as they pay a sufficient fee, making active censorship prohibitively expensive.

A competition where users bid via transaction fees to have their transaction included in the next block. Forced inclusion exists outside this auction model.

• Standard Model: Transactions are ordered by gas price (fee) in a PGA.
• Forced Inclusion Model: Transactions are ordered by a protocol rule, not just the highest bid. This protects system-critical operations from being outbid by purely extractive MEV transactions.

Scaling solutions that execute transactions off-chain and post data or proofs to a Layer-1 (e.g., Ethereum). Forced inclusion is critically important in optimistic and validium rollups.

• Challenge Periods: In Optimistic Rollups, a user must be able to force a fraud-proof transaction onto L1 to challenge invalid state.
• Data Availability: In Validiums, users must be able to force inclusion of a data availability challenge to ensure data is published. Failure here compromises security.