---
title: "Rollup 逃生機制"
description: "從協議角度說明 Rollup 逃生機制：這個名稱涵蓋哪些不同機制、各自保證什麼、依賴什麼，以及如何核驗退出路徑。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Rollup 逃生機制
> 僅供教育參考，不構成財務或安全建議。不同 L2 的退出機制、延遲、費用、合約權限與資料可用性假設各不相同，並可能在升級後改變。
## 直接答案
Rollup 逃生機制是一條應急協議路徑，旨在 L2 營運者、排序器或一般介面失效或實施審查時，保留使用者退出或發起交易的能力。這個名稱沒有統一標準。依照設計，它可能是經由 L1 的強制納入路徑、強制提款請求，或凍結狀態更新並允許使用者憑證明提款的逃生模式。這些機制提供的保證不同，不能互換看待。
逃生機制是在正常狀態更新停止時使用的更強應急路徑。它可能凍結應用程式，讓使用者依照已承諾的狀態根證明餘額。這些機制都不保證即時退出、特定資產價值，也無法排除合約漏洞與治理權限風險。真正的保證取決於已部署的合約程式碼、目前設定、可取得的狀態資料，以及使用者建構並提交所需交易或證明的能力。
## 運作方式
- **識別基礎機制。** 強制納入、強制提款與逃生模式解決不同問題。強制納入繞過進行審查或不可用的排序器。強制提款請求要求協議或營運者處理退出，或證明請求無效。逃生模式通常是最後手段：普通更新停止，使用者以狀態證明提款。
- **從 L1 進入。** 使用者向協議文件指定的 L1 收件匣、入口或結算合約發送交易。在 OP Stack 中，L1 存款交易會在排序視窗內被派生至 L2 區塊。在 Arbitrum Nitro 中，訊息可進入 Delayed Inbox；若排序器未納入，經過設定的延遲後即可強制送入主收件匣。
- **等待協議處理。** L1 確認只是第一個檢查點。請求可能還須進入規範 L2 鏈並成功執行，出現在已證明或已確認狀態中，經過挑戰期或寬限期，最後在 L1 完成確認。強制交易仍可能因 nonce 錯誤、Gas 不足、呼叫資料錯誤、代幣限制或 L2 狀態改變而回滾。
- **滿足退出條件。** StarkEx Spot 展示真正的強制提款與逃生流程。使用者提交 `fullWithdrawalRequest`；應用程式必須完成請求或證明其無效。若請求在 `FREEZE_GRACE_PERIOD` 後仍待處理，就可以申請凍結。之後的逃生需要針對凍結保險庫根的 Merkle 路徑、證明驗證、一次 `escape` 呼叫，以及常規的鏈上 `withdraw` 呼叫。
- **檢查資料可用性。** 狀態根是承諾，不是其背後的餘額或 Merkle 路徑。重建狀態所需資料發布在 L1 時，獨立參與者原則上可以建構退出證明。在 Validium 或其他鏈下資料可用性設計中，使用者可能依賴委員會或營運者公布資料。證明有效性與資料可用性是不同的保證。
- **檢查控制權與工具。** 審查暫停、凍結、升級及治理權限；正確的合約位址與代理實作；支援的資產；所需金鑰；L1 與 L2 Gas；證明產生軟體；以及是否有獨立介面。紙面上正確的機制，對缺少資料、工具或足夠 L1 資金的使用者仍可能不實用。
## 範例
假設某 Rollup 的排序器與官方介面都無法使用，但 L1 仍正常完成最終確認。使用者先依協議官方文件核對鏈 ID 與規範 L1 合約。如果系統只提供強制納入，使用者就提交一筆 L1 到 L2 的交易，呼叫規範橋的 L2 提款函式。接著分別追蹤 L1 提交、強制納入、L2 執行、狀態承諾、適用的挑戰或證明階段，以及 L1 最終確認。L1 提交成功不能證明提款呼叫已經成功。
在 StarkEx 類型的系統中，順序不同：提交文件規定的強制請求，等待設定的寬限期，核驗請求已完成還是已被證明無效，並只在合約條件滿足時使用凍結與逃生。所需的保險庫識別碼、金鑰與 Merkle 路徑必須符合凍結狀態。把 Arbitrum 或 OP Stack 的流程直接套用到這個系統是錯誤的，雖然三者有時都被稱為「強制提款」。
依賴任一路徑前，應在系統健康時以小額演練。記錄合約位址、函式簽章、預期事件、計時器與交易雜湊。使用另一個可信 RPC 或區塊瀏覽器核驗狀態。絕不要在「緊急提款」網站輸入助記詞或私鑰，也不要向客服帳號或私訊支付額外的「解鎖」款項。
## 風險
- 協議有強制納入，但沒有直接的強制提款函式。
- L1 請求已確認，但 L2 呼叫回滾或尚未執行。
- 挑戰期、證明期、寬限期或最終確認期延遲資金到帳。
- 狀態資料或 Merkle 路徑無法取得，鏈下資料可用性設計尤其如此。
- 使用錯誤的鏈、合約、代理實作、函式或保險庫識別碼。
- 退出合約被暫停、升級、錯誤凍結或受到漏洞影響。
- 治理、安全委員會或其他特權參與者可以改變退出路徑。
- 資產不受支援、不符合標準、流動性不足，或受應用層保證金規則約束。
- L1 Gas 暴漲或缺少原生 Gas，導致無法提交或最終確認。
- 官方介面、RPC 服務、索引器或證明工具在需要時不可用。
- 假介面、搜尋廣告或冒充客服的訊息竊取憑證或資金。
- 資金延遲期間市場價值可能下跌；可退出性不等於價格保護。
## 常見誤解
- **每個 Rollup 都有相同的逃生機制。** 名稱、機制與保證因協議而異；應閱讀已部署版本的文件與合約。
- **強制納入會立即把資金返還到 L1。** 它通常只保證交易排序或執行入口，之後橋接提款仍有自己的生命週期。
- **L1 交易雜湊證明退出成功。** 它只證明某筆 L1 交易已被納入；後續 L2 執行與 L1 最終確認必須分別檢查。
- **有效性證明保證退出資料可用。** 證明正確性與資料可用性彼此獨立；鏈下資料設計會引入額外依賴。
- **只要存在某個函式，應急路徑就是無須信任的。** 可用性還取決於權限、目前設定、資料、軟體、Gas 與金鑰。
- **逃生機制消除了財務風險。** 它處理的是活性或審查故障路徑，而不是代幣價格、流動性、智慧合約或金鑰洩漏風險。
## 相關主題
- [規範橋](/zh-tw/crypto/canonical-bridge/)
- [樂觀 Rollup](/zh-tw/crypto/optimistic-rollup/)
- [L2 強制提款](/zh-tw/crypto/l2-forced-withdrawal/)
- [排序器](/zh-tw/crypto/sequencer/)
- [ZK Rollup](/zh-tw/crypto/zk-rollup/)
## 來源
- [OP Stack 協議概覽](https://specs.optimism.io/protocol/overview.html) - OP Stack Specification（查閱日期：2026-08-21）
- [Arbitrum Nitro：第二代樂觀 Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs（查閱日期：2026-08-21）
- [未經應用程式核准的提款與逃生](https://docs.starkware.co/starkex/spot/withdrawing_and_escaping_without_app_approval.html) - StarkEx Documentation（查閱日期：2026-08-21）
- [資料可用性](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation（查閱日期：2026-08-21）
Source: https://wiki.fcontext.com/zh-tw/crypto/rollup-escape-hatch/index.mdx