---
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 的退出机制、延迟、费用、合约权限与数据可用性假设各不相同，并可能在升级后改变。

<a id="answer"></a>

## 直接答案

Rollup 逃生机制是一条应急协议路径，旨在 L2 运营者、排序器或常规界面失效或实施审查时，保留用户退出或发起交易的能力。这个名称并没有统一标准。根据设计，它可能是经由 L1 的强制纳入路径、强制提款请求，或冻结状态更新并允许用户凭证明提款的逃生模式。这些机制提供的保证不同，不能互换看待。

逃生机制是在正常状态更新停止时使用的更强应急路径。它可能冻结应用，并让用户根据已承诺的状态根证明余额。这些机制都不保证即时退出、特定资产价值，也不能排除合约漏洞和治理权限风险。真正的保证取决于已部署的合约代码、当前配置、可用的状态数据，以及用户构造并提交所需交易或证明的能力。

<a id="mechanism"></a>

## 工作原理

- **识别基础机制。** 强制纳入、强制提款和逃生模式解决的问题不同。强制纳入绕过实施审查或不可用的排序器。强制提款请求要求协议或运营者处理退出，或证明请求无效。逃生模式通常是最后手段：普通更新停止，用户用状态证明提款。
- **从 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 资金的用户仍可能无法实用。

<a id="example"></a>

## 示例

假设某 Rollup 的排序器和官方界面都不可用，但 L1 仍正常最终确认。用户先根据协议官方文档核对链 ID 和规范 L1 合约。如果系统只提供强制纳入，用户就提交一笔 L1 到 L2 的交易，调用规范桥的 L2 提款函数。随后分别跟踪 L1 提交、强制纳入、L2 执行、状态承诺、适用的挑战或证明阶段，以及 L1 最终确认。L1 提交成功并不能证明提款调用已经成功。

在 StarkEx 风格的系统中，顺序不同：提交文档规定的强制请求，等待配置的宽限期，核验请求是已完成还是已被证明无效，并只在合约条件满足时使用冻结与逃生。所需的保险库标识符、密钥和 Merkle 路径必须与冻结状态匹配。把 Arbitrum 或 OP Stack 的流程照搬到这个系统是错误的，尽管三者有时都被称为“强制提款”。

依赖任一路径前，应在系统健康时用小额演练。记录合约地址、函数签名、预期事件、计时器和交易哈希。使用另一家可信 RPC 或区块浏览器核验状态。绝不要在“紧急提款”网站输入助记词或私钥，也不要向客服账号或私信发送额外的“解锁”款项。

<a id="risks"></a>

## 风险

- 协议有强制纳入，但没有直接的强制提款函数。
- L1 请求已确认，但 L2 调用回滚或尚未执行。
- 挑战期、证明期、宽限期或最终确认期延迟资金到账。
- 状态数据或 Merkle 路径不可用，链下数据可用性设计尤其如此。
- 使用了错误的链、合约、代理实现、函数或保险库标识符。
- 退出合约被暂停、升级、错误冻结或受到漏洞影响。
- 治理、安全委员会或其他特权参与者可以改变退出路径。
- 资产不受支持、不符合标准、缺乏流动性，或受应用层保证金规则约束。
- L1 Gas 暴涨或缺少原生 Gas，导致无法提交或最终确认。
- 官方界面、RPC 服务、索引器或证明工具在需要时不可用。
- 假界面、搜索广告或冒充客服的消息窃取凭证或资金。
- 资金延迟期间市场价值可能下跌；可退出性不等于价格保护。

<a id="misconceptions"></a>

## 常见误区

- **每个 Rollup 都有相同的逃生机制。** 名称、机制和保证因协议而异；应阅读已部署版本的文档与合约。
- **强制纳入会立即把资金返还到 L1。** 它通常只保证交易排序或执行入口，之后桥接提款仍有自己的生命周期。
- **L1 交易哈希证明退出成功。** 它只证明某笔 L1 交易已被纳入；之后的 L2 执行与 L1 最终确认必须分别检查。
- **有效性证明保证退出数据可用。** 证明正确性与数据可用性彼此独立；链下数据设计会引入额外依赖。
- **只要存在某个函数，应急路径就是无需信任的。** 可用性还取决于权限、当前配置、数据、软件、Gas 和密钥。
- **逃生机制消除了财务风险。** 它处理的是活性或审查故障路径，而不是代币价格、流动性、智能合约或密钥泄露风险。

<a id="related"></a>

## 相关主题

- [规范桥](/zh-cn/crypto/canonical-bridge/)
- [乐观 Rollup](/zh-cn/crypto/optimistic-rollup/)
- [L2 强制提款](/zh-cn/crypto/l2-forced-withdrawal/)
- [排序器](/zh-cn/crypto/sequencer/)
- [ZK Rollup](/zh-cn/crypto/zk-rollup/)

<a id="sources"></a>

## 来源

- [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-cn/crypto/rollup-escape-hatch/index.mdx