把 L2 批次提交到底层链不代表批内每条交易在提交时都已由底层逐笔重算。Optimistic rollup 在规定前提下允许提出执行结果，并给有资格的挑战者机会提交反例或交互争议；最终用户退出依赖争议规则、可用数据、合约配置和挑战窗口。区块链（31）：通道、侧链与 rollup 把哪些责任移出主链的“结算位置”不能简化为“一发批次立即无条件终局”。

sequenceDiagram
  participant S as 排序器/批次提出者
  participant L as 底层结算合约
  participant C as 挑战方
  participant U as 退出用户
  S->>L: 提交批次状态主张与数据关系
  L-->>C: 在挑战期检查主张
  C->>L: 若错误，按协议提交争议证据
  L-->>U: 解决后按退出规则领取

安全需要至少有能取得所需数据、能参与且愿意发起挑战的诚实观察者；活性还需排序器或替代包含/退出路径不会永久受阻。部分系统允许用户在 L2 被审查时向 L1 强制纳入，具体权限与等待期必须依实际部署确认，不能用 OP Stack 或 Arbitrum 的一个文档代表所有 rollup。证明错误不能自动抵消治理升级或桥资产控制权。

一个有问题的批次靠谁拦住

假设排序器声称批次把买家余额减少 70，同时把卖家债权增加 71。L1 收到新状态根及提交，并不等于逐笔执行过批次。如果协议允许挑战，观察者须在期限内取得输入，按冻结的执行规则定位不守恒的那一步，再提交争议合约能识别的证据。少了可用数据、无人监听或费用/身份阻断挑战，即便账面上有“允许争议”接口，也不能推断安全前提成立。若批次正确，挑战机制还要有终止规则，不能让无效挑战永久卡死用户退出。

用户撤回资产时须再分开四个时间点：L2 执行付款，相关批次在 L1 发布，状态主张的争议期按实际部署结束，跨域消息在资产合约上变成可领取的资金。某些部署还允许从 L1 强制包含用户交易，具体队列、最短等待和管理员暂停需查部署配置。若只保存 L2 交易哈希、缺少发布和退出证据，账本应标为“可观察的 L2 执行”，不是“银行资产已经回到买家”。OP Stack 与 Arbitrum 的实际挑战方案不能根据名字互换，本篇不声称运行了其中任何部署。

练习一：批次提交 L1 后用户立刻把账本标“已退出并可兑付”，缺哪几步？答案：需核对是否有挑战窗口、争议解决、消息执行与资产领取规则。练习二：挑战者有执行器但拿不到批次数据，还能稳定指出错在哪里吗？答案：不能假设可以；可用性是执行验证的前提之一。真实 rollup 批次、争议与退出路径 NOT_RUN。

可迁移原则：反驳能力依赖期限、证据与可访问的数据。参考：OP Stack 文档、Arbitrum 文档（分别核具体网络/部署版本，当前待读）；导航：区块链（31）：通道、侧链与 rollup 把哪些责任移出主链 · 32 · 区块链（33）：状态可验证、数据可取得与跨域可领取各有门槛。