diff --git a/pages/stack/protocol/rollup/_meta.json b/pages/stack/protocol/rollup/_meta.json index 0e5361de9..bf5f987a5 100644 --- a/pages/stack/protocol/rollup/_meta.json +++ b/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" } \ No newline at end of file diff --git a/pages/stack/protocol/rollup/forced-transaction.mdx b/pages/stack/protocol/rollup/forced-transaction.mdx new file mode 100644 index 000000000..a3b9694d9 --- /dev/null +++ b/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. + + + 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. + + +## 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.