状态正确性的证据，在两类 Rollup 里由不同角色、在不同时点提交。Optimistic Rollup 提交批次时通常不附有效性证明，而是先把状态根作为“断言”发布出去，默认它正确；如果有人反对，就在挑战机制下提交欺诈证明（故障证明），由 L1 上的合约仲裁。ZK Rollup 则把状态根与一份密码学有效性证明一起交给 L1 验证合约，验证通过后新状态根才被接纳。“事后可质疑”与“事前先验证”，是两条路径最直观的分野。
需要先把“证据”拆开。状态正确性至少涉及两层：其一，状态根确实由某批交易按规则执行得出；其二，外界能取得足够数据独立重算。第二层是数据可用性问题，两种 Rollup 都依赖把数据发布到 L1（calldata 或 blob）。第一层才是证明机制要回答的。而且，数据批次和状态证明并不必然同时到达：有的设计分批发布数据，有效性证明可以稍后提交，也可以用递归证明把多个批次的证明聚合成一个再验证。所以判型不能只看“这笔提交交易有没有 proof 字段”，还要看状态根何时被合约确认为规范状态。
| 观察点 | Optimistic 路径 | ZK 路径 |
|---|---|---|
| 状态根提交时 | 通常不附有效性证明，先作为可争议断言 | 附有效性证明，验证通过才更新 |
| 纠错方式 | 挑战期内提交欺诈证明，L1 仲裁争议步骤 | 证明不通过，状态更新不被接纳 |
| 最终性 | 挑战条件解除后逐步稳定，仍受 L1 最终性约束 | 证明经 L1 验证后稳定，同样受 L1 最终性约束 |
| 主要资源开销 | 数据发布、争议与仲裁的潜在开销 | 证明生成算力与 L1 验证开销 |
| 信任依赖 | 挑战机制有效，且有人实际监控与举证 | 密码学假设与证明系统实现正确 |
用一个明确假设的教学算例说明时点差异，数字只用于演示。设某批次把状态从 S0 推到 S1，数据已发布到 L1。Optimistic 部署把争议期设为 D：在 D 内无人成功挑战，S1 才不再因该批次被回退；若有人挑战，L1 按部署规定的程序裁决，可能重放争议步骤。ZK 部署则在证明提交并通过验证合约后接纳 S1；若证明迟迟未生成，S1 同样不能算最终。可见 ZK 的“快”不是无条件快，而是把等待从“争议期”换成“证明生成与提交节奏”；Optimistic 的“慢”也不是固定天数，D 由各部署参数决定。
提款等待要按同一逻辑读。Optimistic 的 L2→L1 提款通常要等相应批次的争议条件解除，具体时长取决于该桥合约的窗口设置与争议状态；流动性提供方可以先垫付，但这属于另一层信用安排，不改变底层最终性。ZK 的提款在证明验证通过、且相关批次被 L1 接纳后执行，延迟取决于证明生成和批次节奏。把两者概括成“Optimistic 固定七天、ZK 零等待”都不准确，桥的实现、资产类型和合约参数都会改变实际等待。
挑战者权限也不能一概而论。有的部署允许较开放的参与者提交欺诈证明，有的把可挑战角色、保证金和仲裁程序限定在特定集合内；这属于部署层面的治理与安全设计，不应写成“任何人都能挑战”的普遍事实。同样，排序器是另一个维度：它负责排序和提交批次，影响顺序与抗审查，但不等于正确性证据本身。Optimistic 的排序器可能提交错误断言，要靠欺诈证明纠正；ZK 的排序器若提交错误状态根却拿不出有效证明，验证合约会拒绝。抗审查则另看用户能否绕过排序器直接向 L1 合约提交交易等机制。
实操上可用四问定位：状态根被合约接纳前，是否要求一份有效性证明通过验证；若没有，是否存在可提交欺诈证明的争议程序及其时限；提款合约的等待条件是时间锁、证明验证，还是两者组合；证明生成或争议仲裁由谁执行、需要什么资源。再补一句：无论哪条路径，L1 验证或挑战结束都不等于绝对终局，还要看 L1 自身的最终确定性。