正在翻頁。
正在呈現下一章……
此閱讀內容目前僅有英語版。界面使用你選擇的語言。
閱讀英語原文 →A rollup's fast user experience commonly relies on a sequencer ordering transactions. Forced inclusion provides a slower protocol-defined route when that sequencer refuses or fails to process a message. Arbitrum documents a delayed inbox and a mechanism for forcing eligible delayed messages into the chain after the relevant conditions are met. The objective is to limit indefinite exclusion, not to promise immediate execution at the same speed as the normal sequencer service.
Suppose a sequencer repeatedly ignores a user's transaction. The user may need to submit an appropriate message on the parent chain, pay that chain's fee, wait through a specified delay, and invoke the inclusion mechanism. Each step depends on the rollup's actual contracts and configuration. A frontend button called an escape hatch may expose only part of this process, and a successful submission does not necessarily mean a withdrawal has already settled.
Forced inclusion addresses access to ordering; it does not eliminate challenge periods, validity requirements, parent-chain congestion, or bridge accounting. A transaction that violates execution rules can still fail after inclusion. Protocol upgrades can also change operational parameters, so instructions should identify the chain, contract version, and current delay. In a network comparison, inspect whether the route is usable by ordinary users, which actors must cooperate, and whether the settlement layer itself remains available.