L2排序器停机：区分交易延迟与资产损失

排序器停机首先表示某条交易处理路径中断，本身不能证明已结算资产消失。研究时要拆开请求接收、交易排序、数据发布、结算状态建立和资产提取。每个阶段需要不同证据，也有自己的时间记录，不能只用一个“已确认”标签覆盖。

以太坊乐观Rollup概览介绍排序器以及链外执行与结算的关系。具体实现并不相同。有关强制提交、退出时间或恢复能力的结论，仍需核对目标网络当前文档和部署，不能直接由概览推出。

绘制交易状态时间线

从最后一个已知正常时点开始，记录提交标识、排序器回执、相关L2区块、基础层批次或数据发布，以及结算系统采用的状态承诺。应用显示交易“处理中”，不等于后续各阶段都已发生；服务发来的接收回执也不是最终结算证明。

RPC服务可用性与排序器可用性要分开。钱包可能因自己的RPC端点故障而无法工作，但排序器仍在接收其他来源交易。反过来，RPC也可能响应正常，却只提供旧状态。判断故障位置前，应比较与问题直接相关的多个观察，而不是看到网页加载成功就下结论。

研究的问题是运营连续性：哪些动作延迟、哪些已有状态仍可核验，以及文档列有哪些替代路径。未经测试的应急流程应作为待核依赖，不能暗示读者在事故中立即转移资产，更不能保证某条路径必然及时完成。

假设一个虚构Rollup在十点接收一笔转账，界面也显示了它，但研究者在基础层尚未找到包含它的批次。十点零五分，正常排序服务停止响应。此时回执证明该服务接收过请求，却不能证明交易已经结算。

另有一笔较早交易，已经能在发布数据和对应承诺状态中核对到。它与新请求处于不同研究状态。若把两者都写成“卡住”，会丢失提交延迟与后续退出依赖之间的区别。本例时间仅用于说明阶段，不是恢复时间估计。

再假设文档介绍了带前提的基础层交易纳入路径。工作表应记录入口合约、适用条件、核对该路径所需材料，而不是承诺立刻执行。存在替代入口，也不代表端到端提款时间固定。

每行增加观察时间、来源端点和“已观察”“暂不可访问”“尚不适用”等状态。不能因为运营方安抚文字听起来完整，就补齐缺少的阶段。不同层使用不同标识时，还要保留对应关系，避免把内部请求号误当链上交易哈希。

事故报告可能解释原因与处理过程，应保留为运营方陈述，再与交易时间线比较。它能够解释某种延迟，却未必证明所有用户请求都处于相同阶段。一笔交易恢复成功，也不能当成全部请求完成的统计验证。

服务恢复后，还要检查原有请求是被纳入、替换、拒绝，还是仍然未知。状态页显示健康，不等于最初请求已经全部调节。保留中断期间的观察，才能避免恢复后的叙述重写当时历史。

常见错误是把钱包显示当最终性、把所有停机当资产损失，以及把替代路径当即时恢复。合格的现货研究备忘录应说明阻塞阶段、已核验旧状态和剩余依赖，既不夸大损失，也不凭空填入保证。

不能。端点可能返回历史状态，需要检查新处理证据和被测试的具体服务。

不能。先确认交易所在阶段，再核对目标实现的恢复和提款条件。