Merge pull request #872 from ethereum-optimism/forced-withdrawal

Added force withdrawal guide

Author: sbvegan

pages/stack/protocol/rollup/_meta.json

@@ -2,5 +2,6 @@
     "overview": "Rollup Overview",
     "deposit-flow": "Deposit Flow",
     "transaction-flow": "Transaction Flow",
-    "withdrawal-flow": "Withdrawal Flow"
+    "withdrawal-flow": "Withdrawal Flow",
+    "forced-transaction": "Forced Transaction"
 }

pages/stack/protocol/rollup/forced-transaction.mdx

@@ -0,0 +1,73 @@
+---
+title: Forced Transaction
+lang: en-US
+description: Learn the forced transaction flow during sequencer downtime.
+---
+
+import { Callout } from 'nextra/components'
+
+## Forced Transaction Flow
+
+This guide explains the nuances of forced transactions during sequencer downtime.
+
+Users are able to force-include deposit transactions, which can initiate withdrawals, at any time.
+However, there are important nuances to understand about the chain derivation pipeline and sequencer behavior.
+
+## Key Concepts
+
+*   **Sequencing Window**: A 12-hour rolling window to include L2 transactions, including native L2 transactions and deposit transactions.
+*   **Max Time Drift**: 30 minutes, the maximum delay for including a deposit transaction, relative to the L2 chain.
+*   **Sequencer Downtime**: Period when the sequencer is offline or not producing blocks.
+
+## Normal Operation
+
+Under normal circumstances:
+
+1.  Deposit transactions are included within 30 minutes.
+2.  The sequencer processes transactions and produces blocks regularly.
+
+## Sequencer Downtime Scenarios
+
+### Short Downtime (< 30 minutes)
+
+*   Deposits are still included within the 30-minute max time drift.
+*   Regular L2 transactions may be delayed.
+
+### Extended Downtime (30 minutes to 12 hours)
+
+1.  Deposits are force-included within 30 minutes.
+2.  The L2 chain state remains uncertain until:
+    *   The sequencer comes back online, or
+    *   The 12-hour sequencing window expires.
+
+### Prolonged Downtime (> 12 hours)
+
+1.  After 12 hours, nodes start generating blocks deterministically.
+2.  These blocks only include deposit transactions.
+3.  When the sequencer returns:
+    *   All deposit transactions are included first.
+    *   No regular L2 transactions are included until the L2 chain is within 12 hours of the chain.
+
+
+
+## Important Considerations
+
+*   Forced transactions, through deposits (no need for deposited value), ensure timely execution of actions, mitigating risks like DEX price divergence during sequencer downtime.
+*   Actions remain speculative for up to 12 hours due to the sequencing window.
+*   The 12-hour window is a balance between operational reliability and minimizing potential L2 reorganizations.
+
+## Example Scenario
+
+If a deposit is initiated after the 30-minute mark but before the sequencing window expires:
+
+1.  The deposit will be effective when the sequencing window expires (up to ~11 hours later).
+2.  Nodes reading data from L1 will produce a block with the deposit after the sequencing window expires.
+3.  The eventual L2 chain will include the deposit in a block with an onchain timestamp close to the L1 block where the deposit originated.
+
+<Callout type="info">
+  The sequencing window is a rolling 12-hour delay from when an L1 block is first known. This design allows the sequencer a grace period to come back online without causing L2 chain reorganizations.
+</Callout>
+
+## Conclusion
+
+The forced transaction mechanism on OP Stack chains provides a robust way to handle sequencer downtime, ensuring that critical transactions are included in a timely manner. While the 12-hour sequencer window introduces a degree of uncertainty during downtime, the system is designed to guarantee eventual consistency and transaction inclusion.