Merge pull request #1488 from ethereum-optimism/gk/downtime

Update forced-transactions

Author: sbvegan

pages/stack/transactions/forced-transaction.mdx

@@ -4,20 +4,24 @@ lang: en-US
 description: Learn the forced transaction flow during sequencer downtime.
 ---
 
-import { Callout } from 'nextra/components'
+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.
+In the OP Stack, forced transactions serve as a mechanism to ensure transaction inclusion, even during sequencer downtime.
+Users are able to force-include 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.
+*   **Forced Transactions**: Transactions that users can submit directly to the L1 chain, ensuring their inclusion in the L2 chain without sequencer intervention.
+    This mechanism is crucial during sequencer downtime.
 
 ## Normal operation
 
@@ -26,29 +30,41 @@ Under normal circumstances:
 1.  Deposit transactions are included within 30 minutes.
 2.  The sequencer processes transactions and produces blocks regularly.
 
-## Sequencer downtime scenarios
+## Forced transaction mechanism
 
-### Short downtime (< 30 minutes)
+1.  **Submission to L1:**
+    Users can send transactions directly to the `OptimismPortal` contract on L1 Ethereum. This bypasses the sequencer, ensuring that the transaction is recorded on L1.
 
-*   Deposits are still included within the 30-minute max time drift.
-*   Regular L2 transactions may be delayed.
+2.  **Inclusion in L2:**
+    Once submitted to L1, these transactions are automatically included in the L2 chain. The timing of their inclusion depends on the duration of the sequencer's downtime:
 
-### Extended downtime (30 minutes to 12 hours)
+    *   **Short Downtime (< 30 minutes):**
+        During short downtime `~ 30 minutes`, transactions may still be included within the usual 30-minute maximum time drift if the sequencer resumes operation within that window.
 
-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.
+    *   **Extended Downtime (30 minutes to 12 hours):**
+        During sequencer downtimes lasting between 30 minutes and 12 hours:
 
-### Prolonged downtime (> 12 hours)
+        *   Deposit Transactions: Users can submit forced transactions directly to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L209) contract on L1. However, these transactions will only be included in the L2 chain once the sequencer resumes or the 12-hour sequencing window expires.
+            Refer to the [Bypassing the Sequencer](/stack/rollup/outages#bypassing-the-sequencer) section for more information about this functionality.
+        *   L2 Chain State: The L2 chain's state remains uncertain until either:
+            The sequencer resumes operations and processes pending transactions, or
+            the 12-hour sequencing window expires (after which nodes begin generating blocks deterministically, incorporating only the forced-included deposit transactions).
+    
+    *   **Sequencer Catch-up Phase:**
+        If the sequencer is offline for more than 30 minutes but less than 12 hours, it enters a **quick catch-up** phase upon restarting. 
+        During this phase:
+        *   The sequencer produces **deposit-only blocks** while moving the L1 origin forward with every block.
+        *   This continues until the L1 origin is back inside the sequencer drift window.
+        *   Normally, L2 blocks are produced at a **6:1 ratio** relative to their L1 origin (12s per L2 block vs. 2s per L1 block). However, during the catch-up phase, this ratio **switches to 1:1**, meaning each L2 block corresponds to a new L1 origin.
 
-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.
+    *   **Prolonged Downtime (> 12 hours):**
+        After 12 hours, nodes begin generating blocks deterministically, incorporating only the forced-included transactions. Regular L2 transactions are deferred until the sequencer is back online and has processed enough blocks to be within the last 12 hours of the L1 state.
 
+## Benefits of forced transactions
 
+*   **Censorship Resistance:** Users can ensure their transactions are processed even if the sequencer attempts to censor them.
+*   **Network Resilience:** The network remains operational, allowing critical transactions to proceed during sequencer downtimes.
+*   **User Autonomy:** Users are not entirely dependent on the sequencer for transaction inclusion, providing an additional layer of trust and reliability.
 
 ## Important considerations
 
@@ -60,14 +76,17 @@ Under normal circumstances:
 
 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).
+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.
+  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.
+The forced transaction mechanism on OP Stack chains provides a robust way to handle [sequencer downtime](/stack/rollup/outages#sequencer-downtime-outages), 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.