English version · 区块链学习导航 · 上一篇
区块链学习 · 文章 BC047
乐观状态断言是一项可以通过指定挑战流程被接受的主张。其保护机制不只是存在一个“挑战”按钮：必须有人能取得相关数据、核对正确规则、及时提交有效争议，并按要求完成整个争议程序。
等待期本身不会计算主张是否正确。没有人回应断言，也不能证明背后每笔交易都有效。机制的安全论证需要明确监测、数据、纳入交易、执行和管理权限等前提。
本篇用一个刻意简化的挑战流程，从断言跟踪到裁决，区分正确计算、及时挑战、状态被接受，以及之后的退出条件。
选择适合你的阅读路线
本篇目录
- 1. 断言必须明确它针对什么
- 2. 计算之前，观察者需要什么
- 3. 计算课堂执行轨迹
- 4. 启动时钟前，先规定挑战状态机
- 5. 跟踪成功挑战
- 6. 检查准确边界
- 7. 无人有效挑战的错误断言，暴露了一个前提
- 8. 发起挑战，不等于挑战必胜
- 9. 数据可用性是前提，不是装饰性链接
- 10. 权限与及时纳入，同发现错误一样重要
- 11. 正确裁决需要准确绑定
- 12. 接受、基础链最终性与退出是不同阶段
- 13. 管理控制也属于证据包
- 14. 练习：为时间线卡片分类
- 15. 常见问题
- 资料来源与后续阅读
先读观察者的证据清单，再计算两步课堂轨迹，跟踪高度120的期限。比较未解决争议、迟到挑战和正确断言胜诉的情况，最后完成练习。
以下整个挑战状态机均为虚构。其区块高度期限和简单算术验证器都是教学规则，不是 OP Mainnet 或其他已部署 rollup 的规则。不发起真实挑战、不提交保证金，也不执行交易、提款或金融操作。
一手资料核对于2026年10月12日。引用具名 OP Stack 规范，是为了说明真实系统有特定的博弈类型、状态、时钟和解决程序。规范页面不能证明每个网络当前部署的配置。
1. 断言必须明确它针对什么
运营者的断言需要比“新结果是14”更多的上下文。虚构断言指明应用 ArchiveCounter、规则版本 AC1、起始状态承诺、有序批次承诺、结束状态承诺，以及相关基础链上下文。
练习在密码学前提下，假定这些承诺与其对象正确绑定。我们用可读数值检查计算，但不把十进制数字当成真实状态根，也不认为一个显示标签能够认证其来源。
改变批次、起始状态或规则版本，就形成另一项主张。观察者证明另一个批次得出13，不一定驳倒关于当前批次的实际断言。
所以第一项任务是对齐：运营者与观察者是否在讨论完全相同的有序输入和规则？只有如此，输出不一致才构成有意义的争议。
2. 计算之前，观察者需要什么
观察者 O 需要经过认证的起始状态、完整相关批次数据、顺序、准确的 AC1 转移规则，以及断言身份。O 还需要知道适用的挑战权限、期限定义和争议程序。
以太坊乐观 rollup 概述介绍发布数据与欺诈挑战的作用。本篇使用这一高层关系，不采纳统一提款期限，也不认为没有挑战就从逻辑上证明执行正确。
主练习中，相关数据确实可取得，并与已发布承诺正确匹配。O 具备准备规定证据所需的资源和权限。明确提供这些条件，是为了先专注于时间线。
后续变化题一次移除一个条件。这比只说机制“无需信任”更有帮助，因为我们明确了谁能诚实行事、必须掌握什么，以及其操作无法被处理时会怎样。
3. 计算课堂执行轨迹
AC1 维护一个非负整数计数器。每条获授权指令加上一个0至3之间的整数，包含0和3。起始计数为10，经过认证的有序批次依次包含 Add(2)、Add(1)。
题目规定，授权和其他有效性检查全部通过。因此正确轨迹是10到12，再到13。在这些输入和规则下，最终值必须为13。
运营者却断言最终值为14，并在争议中提供轨迹10到12，再到14。第一步一致，第二步不一致：12加上指定的1是13，不是14。
这段算术把分歧定位到具体位置，但它本身不是生产系统的欺诈证明。虚构裁决合约仍须验证：争议步骤、前状态、输入和所声称后状态，都属于正在争议的准确已承诺断言。
4. 启动时钟前，先规定挑战状态机
断言在基础链 L 的区块高度100被记录。初始挑战期限是高度120，包含120。格式正确的初始挑战必须在不高于120的高度，被纳入并获相关 L 合约接受；仅在该高度之前广播，并不足够。
虚构状态机使用以下规则：
- 接受之前，断言可能是没有争议的待定状态，也可能处于争议未解决的待定状态。
- 符合条件的初始挑战在高度120或之前被接受，就启动争议。首次在121被纳入的初始挑战，按此规则已经迟到。
- 任何及时发起而尚未解决的争议，都会阻止接受，即使高度已经超过120。
- 挑战成功，断言被拒绝。
- 挑战失败，该争议不再构成障碍，但接受仍要求高度大于120，且其他给定条件满足。
- 接受需要另一次成功的合约操作，仅有高度推进不会自动执行接受。
本练习只考虑各条轨迹中指定的一项相关争议，并假定裁决正确、没有管理员覆盖权限、L 持续提供足够处理能力。每个案例直接给出简化的裁决时间，不模拟生产协议的每一步操作或时钟延长。
5. 跟踪成功挑战
O 取得数据，算出13，发现14的断言错误。正确绑定的挑战在高度118被纳入，合约针对具名断言记录待解决争议。
到高度121，最初的挑战开启窗口已结束，但争议仍未解决。不能仅因121大于120，就认为断言具备接受资格。未解决争议这一条件仍然阻止接受。
到高度125，题目给定的裁决程序正确验证第二步不一致，并判 O 胜诉，断言因此被拒绝。之后不会仅因更多区块经过，就重新接受这个已拒绝断言。
在本玩具流程中，已接受起始状态保持为原状态。一个更正断言需要经过自己的指定提交与接受路径。除非规则确实要求合约如此处理，否则不能悄悄把观察者算出的值直接安装为新接受状态。
6. 检查准确边界
现在把 O 的初始挑战移到高度120。由于虚构规则包含边界，在120正确处理的挑战仍及时。如果到121仍未解决，它会继续阻止接受。
再把首次纳入时间改为121，就已经迟到。发送请求时界面显示119，并不能证明合约在期限前接受了它。相关观察是：操作在相应 L 历史中何时被记录。
真实系统可能使用时间戳、继承时钟、多轮交互、延长机制或其他时间规则。OP Stack Fault Dispute Game 规范包含它自己的博弈时钟与解决机制。本篇单一、含边界的区块高度窗口，有意不替代那些细节。
一般性教训是：读清不等式，以及它衡量哪个事件。如果把准备、广播、纳入、成功处理和所在区块最终确定混为一谈，“期限之前”就会变成含义不同的说法。
7. 无人有效挑战的错误断言，暴露了一个前提
回到错误的14断言。在变化题中，高度120之前没有任何符合条件的挑战被成功处理。到121，假设有效的接受操作执行，其他玩具条件均满足。
按这个乐观状态机，即使独立算术显示断言错误，它仍可能因为未被挑战而获接受。这正是安全论证需要“有效的诚实挑战”，而不只需要抽象上“存在挑战可能性”的原因。
这不意味着每个乐观系统都会接受每项无效主张，而是说明本题机制依赖的某项条件，已被变化题移除。真实协议可能加入其他保护，但必须具体指出，不能凭空假设。
安全摘要应写出完整条件：若符合条件的诚实观察者能够取得数据、发现错误、让必要操作及时被处理，并在其他系统前提下完成可靠争议程序，无效断言才会被阻止接受。
8. 发起挑战，不等于挑战必胜
考虑另一个最终值正确为13的断言。有人在高度118挑战它，但题目给定的125裁决确认所声称轨迹正确，挑战失败。
在121，争议尚未解决，接受仍受阻。到125，失败挑战被解决，高度条件已满足，也没有未解决或成功的挑战。在其他条件满足时，断言此刻具备接受资格。
但它不一定已被接受。如果另一次接受操作在126成功执行，那才是要记录的接受事件。如果没有执行该操作，记录应写“具备资格”，而不是“已接受”。
OP Stack 争议博弈接口区分进行中、挑战方获胜与辩护方获胜等结果。这些真实状态区别支持这种阅读习惯；本篇玩具状态机及额外接受操作，仍由本题另行定义。
9. 数据可用性是前提，不是装饰性链接
假设 O 看得到批次承诺，却拿不到必要批次字节或起始状态数据。承诺帮助辨认什么数据能够匹配，但不会提供重算轨迹所缺失的内容。
如果从未取得实际批次，O 就不能诚实地声称已核对 Add(2)、Add(1)。界面写着“数据已发布”，也需要相应发布和检索上下文。主案例给出的是实际可取得，而不只是运营者声称可取得。
这个变化题移除了有效监测的一项前提，但它本身没有规定合约如何处理缺失数据。如果真实设计有单独的数据可用性规则、超时或备用机制，应按该机制自身条款检查。
同样，观察者后来拿到某些数据，不代表之前就有足够时间。复核时应记录数据何时真正可用，并与相关挑战及响应期限比较。
10. 权限与及时纳入，同发现错误一样重要
O 可能正确计算出错误，却没有权限参加某个许可式博弈；也可能有资格，却无法让必要操作在期限前被纳入。两种情况下，数学上发现问题，与在协议中有效干预，都发生了分离。
主案例明确给予 O 参与资格，并规定其操作成功被处理。去掉任一前提，结论就必须缩小。公开规范介绍挑战程序，不能证明每个部署都允许每位阅读者使用它。
OP Stack 故障证明说明讨论提案、挑战和额外保护，包括特权干预和延迟。这提醒我们检查已安装的博弈及相关控制，不要假定通用标签已经描述全部运行权限。
学习这个区别，不需要进行真实挑战。架构复核可以索取当前博弈类型、获授权参与者、时间规则、软件假设，以及从发现问题到协议操作被纳入的路径证据。
11. 正确裁决需要准确绑定
在算术示例中，复核者需要的不只是“12+1=13”这句话。证据必须把这一步连接到 AC1、经过认证的初始状态、有序批次和争议承诺。
假设挑战者换成 Add(2)、Add(2)。另一个批次确实结束于14，但它不是本题承诺的批次。同样，证明另一规则版本中的步骤，也不能解决关于 AC1 的主张。
真实多轮博弈可能把较大争议缩小到一步，并用承诺及其他证据连接各部分。连接的正确性与最后一步求值器同样重要。本题假定连接正确实现，不假装两行算术就实现了完整系统。
故障记录因此应标明争议断言和程序，而不只是附上意外结果的截图。可复现分歧首先需要共同上下文，然后才谈得上有说服力的表述。
12. 接受、基础链最终性与退出是不同阶段
正确断言的接受操作在 L 上成功之后，所在区块仍可能需要相关 L 最终性证据。应用应分别报告接受发生的分支及最终性上下文，不应假定合约成功就是最后条件。
基于该状态退出还有自身要求。在本概念模型中，需要引用已接受状态，提供与符合条件退出请求正确绑定的证据，满足防重放和授权要求，并符合相关 L 处理与最终性条件。
本篇不规定统一提款时长。真实协议可能有挑战时钟、额外等待期、暂停权限或其他条件。如果某项流动性服务提供更早付款，那是另一个具有自身假设的安排，不能证明底层协议流程提前结束。
本课止于解释这些前提，不提供跨链操作步骤、费用建议或金融服务路径。
13. 管理控制也属于证据包
玩具基准没有覆盖裁决或暂停的管理员。如果变化题增加一个可暂停接受、替换裁决器或改变允许博弈的授权方，先前的时间计算就不再是完整分析。
例如，如果适用暂停状态阻止接受操作，那么到121且没有争议，也不能证明实际能够接受。替换步骤检查器，还可能改变合约认为什么结果正确。
系统有故障证明机制，不会使这些权限失去意义。复核者应说明权限范围、控制主体、等待期，以及正在评估哪个版本的规则。
技术上有某项权力，不代表具有恶意。重点是如实纳入依赖，使安全陈述描述已安装系统真正能够做什么。
14. 练习：为时间线卡片分类
仅应用第4节的虚构规则。除题目说明外，没有其他挑战或管理权限。
- 错误断言14，挑战在120被接受，到121仍未解决。121的接受操作能成功吗？
- 错误断言14，首次尝试挑战在121被纳入，之前没有挑战。该初始挑战及时吗？
- 正确断言13，118发起挑战，125裁决驳回挑战，126接受操作成功。何时具备资格，何时实际接受？
- 错误断言14，没有及时挑战，121接受操作成功。没有挑战是否证明算术正确？
- O 得出正确值13，但拿不到承诺批次，使用了猜测批次。是否已经建立必要争议证据？
- 已接受断言位于某个 L 区块，但缺少所需最终性证据。仅凭合约成功，能否建立最终结算？
答案与推理
- 不能。期限包含120，所以挑战及时；即使开启窗口结束，未解决争议仍阻止接受。
2. 不及时。明确规则要求初始纳入高度不大于120。之前准备或广播，不会改变实际记录的纳入高度。
3. 125裁决后具备资格，因为125大于120，失败争议也不再阻止接受。实际接受发生在126另一次操作成功之时。
4. 不能。有效诚实挑战者前提失败时，玩具状态机可能接受未受挑战的坏断言。计算仍然是10+2+1=13。
5. 没有。猜测或不同批次不是断言经过认证的输入。观察者需要匹配数据和准确绑定，而不只是认为某个输出合理。
6. 不能。仍需建立相关 L 历史与最终性条件，并检查其他独立退出要求。
15. 常见问题
挑战期一定是七天吗？
本篇没有采用通用时长，玩具期限以高度规定。对于具名部署，应检查实际博弈、时钟、配置和额外延迟。
世界上任何地方有一个诚实的人，就能保证安全吗？
这种口号省略了前提。相关参与者必须有必要信息、权限、资源，能够及时完成协议操作，并满足正确验证及其他给定假设。
挑战成功会自动安装挑战者希望的状态吗？
只有协议明确规定才会如此。本题规则拒绝坏断言，替代断言必须走自己的指定路径。不能仅从获胜者身份推导状态更新。
资料来源与后续阅读
以下一手资料核对于2026年10月12日，新加坡时间：
- 以太坊乐观 rollup：链外执行、发布数据和挑战之间的关系。不使用通用时间、性能或无条件安全概括。
- OP Stack 争议博弈接口：具名博弈类型、主张和不同裁决状态。持续变化的规范不是部署认证。
- OP Stack Fault Dispute Game：作为协议特定机制的轨迹承诺、步骤求值、时钟与裁决。课堂规则没有实现这个博弈。
- OP Stack 故障证明说明：提案与挑战角色，以及应针对相关部署核对的额外保护。
上一篇附属系统练习问保证来自哪里，本篇单独分析诚实观察者需要及时作出的干预。接下来将与验证有效性证明比较，同时继续区分证明接受、状态重建和可用退出证据。