English version · 区块链学习导航 · 上一篇
区块链学习 · 文章 BC048
有效证明可以建立一项指定的状态转移主张，却不一定把重建结果状态所需的数据交给每位阅读者。结算合约还必须确认该证明对应正确应用、规则、当前起始状态和数据承诺，才能接受更新。
这些检查彼此不同。“证明通过验证”“合约接受更新”“所在基础链历史已最终确定”“这位阅读者完成状态重建”，不应压缩成一个绿色指示灯。
本篇通过六份证据包跟踪小型状态更新，重点是证明使用者要检查什么，以及重建还需要什么，不重新构建证明系统，也不重复 Merkle 路径计算。
选择适合你的阅读路线
本篇目录
- 1. 从陈述开始，不从证明文件名开始
- 2. 明确证明前提
- 3. 三个键的起始状态
- 4. 重建数据是一份状态差异
- 5. 重建状态，不等于恢复每一条历史指令
- 6. 合约不只做一次独立证明检查
- 7. 证据包 A：证明、结算与重建全部一致
- 8. 证据包 B：接受的证明相同，但现在缺少字节
- 9. 证据包 C：关于过时起始状态的有效证明
- 10. 证据包 D：取得的字节不匹配承诺
- 11. 证据包 E、F：上下文错误，或验证器不明
- 12. 数据模式改变剩余假设
- 13. 基于证明，不意味着私密、即时或永不停机
- 14. 退出证据是状态的另一个使用者
- 15. 练习：精确分类证据
- 16. 常见问题
- 资料来源与后续阅读
先看陈述中的具名字段，计算三个键和两项更新数据，再分类完整证据、缺失数据、起始状态过时和数据不匹配的情况。最后完成复核清单与练习。
所有承诺、账户名和合约标识符都是虚构符号。我们不生成密码学有效性证明，不部署验证器，也不转移资产。证明验证结果和承诺对应关系，均由题目明确给出。
一手资料核对于2026年10月12日。具名 ZKsync 文档提供公共输入绑定与重建数据的具体例子，不用于声称所有链共享同一实现、数据模式或正在运行的软件版本。
1. 从陈述开始，不从证明文件名开始
虚构应用名为 ArchiveAlloc，规则版本为 AV1。其结算合约 S 运行在名为 LabL 的基础链上。合约当前记录应用状态承诺 r0，并期待下一批次为 batch17。
候选陈述指明 LabL 和 S、ArchiveAlloc 和 AV1、旧状态 r0、新状态 r1、batch17，以及公共数据承诺 d17。在玩具设计中，所有这些字段都被绑定到已验证陈述，或者绑定到由合约与该陈述不可分离地关联的检查。
最后这一点很重要。报告里列出某个字段，不代表验证器实际检查了它。练习直接给出绑定成立；真实复核者则需要匹配的规范、验证器身份和合约逻辑。
ZKsync OS 的 L1 集成说明提供具体例子：证明公共输入或其原像中包含前后状态承诺，以及输入、消息和数据相关的其他组成。本篇以此说明为何要检查准确陈述，不把它当成统一字段格式。
2. 明确证明前提
假定证明系统对于指定关系具有可靠性，预期 AV1 检查被正确表达，验证器实现及参数正确，相关承诺方案按预期绑定具名数据。
在这些前提下，验证成功建立的是陈述所表达的关系。如果陈述漏掉某条授权规则，不会仅因设计者希望包含它，就自动证明它成立。
本例 AV1 包含必要授权与计数更新条件，因此给定证明结果针对这些规则。我们不从计数值推断真实托管、法律所有权或实物可用性。
证明也不会认证每个分发证明的服务都诚实。阅读者仍需辨认哪个验证器检查了哪个陈述，以及所得依据是否对应预期合约和网络。
3. 三个键的起始状态
完整玩具应用状态只有三个非负整数计数器。在 r0，A=2、B=5、C=7。这个数值例子没有隐藏应用键、手续费、代码变化或其他更新。
AV1 允许获授权指令把正整数单位从一个具名计数器移到另一个，前提是来源数量足够。这些是虚构分配计数，不是钱。操作保持单位总数不变。
题目提供的 batch17 执行一次获授权的从 B 向 A 移动2单位，结果是 A=4、B=3、C=7。起始和结束总数都为14。
练习给定：完整起始状态的规范承诺为 r0，完整结果状态的规范承诺为 r1。这些标签表示题目给出的承诺关系，不是实际计算出的哈希。不能把 r1 当成生产系统可用的状态根。
4. 重建数据是一份状态差异
在玩具格式中，必要公共重建数据 D17 包含两个最终值赋值：把 A 设为4，再把 B 设为3。未列出的键保留旧值。编码和键顺序由格式固定，禁止重复键。
题目规定 D17 匹配承诺 d17。阅读者如果有经过认证的完整 r0 状态，就能应用两个赋值，保留 C=7，重建完整新状态。在认定重建与证据包一致之前，结果的规范承诺还必须匹配 r1。
这不表示每种 rollup 都发布这个格式。ZKsync 数据可用性文档介绍状态差异，以及在其上下文中用于重建的其他公共数据，包括消息、日志和字节码。
本例刻意只含三个计数器，没有变化中的代码或消息。真实重建程序需要状态模型要求的每一类数据，而不只是应用恰好感兴趣的两个值。
5. 重建状态，不等于恢复每一条历史指令
最终值赋值显示 A=4、B=3，但仅凭它们，无法知道应用是执行了一次移动2，还是两次获授权移动1。两种可能历史都能从给定起始计数到达同一结束计数。
练习中，batch17 及证明陈述已绑定实际批次上下文。这里的重点是：只阅读最终状态差异，无法恢复历史分析者可能关心的每条中间指令、顺序细节或事件。
应区分两个目标：重建已承诺应用状态，或复现完整历史执行过程。它们所需数据可能不同。证明可以支持转移有效性，而公共重建格式有意省略部分中间细节。
研究者要求“全部交易数据”时，这一区分尤其有用。应先问需要当前状态、某条消息、执行轨迹，还是完整有序交易历史，再声称某份数据足够。
6. 合约不只做一次独立证明检查
S 只有在以下条件满足时才接受更新：证明针对正确绑定的陈述验证通过；网络、应用、规则标识匹配；旧根等于当前根；batch17 确实是预期下一批次；指定数据发布条件满足。
基准设计使用固定验证器和应用规则，没有升级或暂停管理员。这些前提让练习保持聚焦，不是所有有效性 rollup 的通用性质。
必要检查全部通过且更新操作成功后，S 记录 r1，并推进预期批次。在报告更新已经最终结算之前，所在 LabL 区块仍需要相关最终性证据。
因此，独立验证器返回 true，不代表可以覆盖 S 当前的任意状态。上下文与顺序检查，把数学陈述变成这个应用有权接受的特定状态更新。
7. 证据包 A：证明、结算与重建全部一致
A 包含正确陈述的真实验证依据、S 从当前 r0 成功更新到 r1、匹配的必要数据发布，以及覆盖更新的已验证 LabL 最终性。阅读者还有经过认证的完整起始状态和匹配的 D17 字节。
阅读者检查数据承诺，按正确格式解码两项赋值，将其应用到 A2/B5/C7，保留 C7，得到 A4/B3/C7。给定的规范承诺检查匹配 r1。
在这些前提下，现在支持三个结论：指定转移经过证明验证；预期结算更新已接受并被所提供最终性覆盖；这位阅读者重建了匹配的完整玩具状态。
即使如此，结论仍需有限。A=4 是 ArchiveAlloc 中的值。证据包没有证明四件实物存在，没有证明用户对其享有法律权利，也没有保证所有未来服务一直可用。
8. 证据包 B：接受的证明相同，但现在缺少字节
B 有与 A 相同的真实已接受更新，以及经过验证的历史数据发布证据。区别在于较晚的阅读者：它拥有起始状态和承诺，但复核时无法从现有来源取得 D17。
阅读者仍可报告题目提供的证明与结算事实，却不能只凭 d17、r1 完成自己的重建。承诺不是解压服务，证明验证成功也不会把缺失赋值交出来。
这并没有说明更新被接受时，协议数据可用性失败。题目明确提供了当时的发布依据。较晚的本地检索缺口、归档缺失或供应方不可用，是另一个需要单独调查的主张。
有用的报告可以写：“已建立接受更新与历史发布依据；这位阅读者目前拿不到 D17，因此重建未完成。”这比“证明坏了”或“验证成功，所以所有数据都可取得”都准确。
9. 证据包 C：关于过时起始状态的有效证明
C 提供同样在数学上有效的 r0 到 r1 陈述，但 S 当前状态已是 r2，因为另一项获授权更新已经接受。该陈述没有从 S 的当前根开始。
独立证明仍可能作为关于 r0 的主张通过验证，但 S 会拒绝把它用作下一次更新，因为旧根相等条件不成立。合约不会为了方便使用证明，就退回 r0。
这是上下文不匹配，不一定是伪造证明。诊断时区分这些失败类别很重要：真实证明也可能不适合它被尝试应用的状态位置。
网络与应用标识同理。针对某一授权上下文的正确依据，不能自动重复用于另一上下文，即使两个界面接受形状相似的对象。
10. 证据包 D：取得的字节不匹配承诺
D 保留原来已接受的 r0 到 r1 更新的真实依据，但供应方返回不同字节 Dbad。其解码结果是 A=4、B=4，题目给定的承诺检查显示 Dbad 不匹配 d17。
应拒绝把这些字节当作所声称的 D17 重建输入。不能因数值接近，或某个键看起来正确，就放宽相等检查。经过认证的陈述指定的是一个明确数据承诺。
把 Dbad 应用到旧状态，会产生总数15，也违反玩具守恒规则。这是有用的第二个警告，但承诺不匹配已经说明，文件不是这份证据包所需的重建数据。
坏文件本身不使关于 D17 的真实证明失效，它说明供应方响应没有提供被绑定对象。应把证明有效性与数据交付正确性分开报告。
11. 证据包 E、F：上下文错误，或验证器不明
E 包含关于另一个应用 ArchiveOther 及其陈述的有效证明，但 S 要求 ArchiveAlloc。即使某些根或计数看起来相似，应用上下文条件仍不满足，S 不能把它应用成 ArchiveAlloc 更新。
F 只提供一张写着“证明有效”的截图，没有验证器、参数、陈述、网络或结算交易标识。因此它根本不足以建立预期的验证结论。
这些情况与 C、D 不同。C 的起点过时，D 的重建字节不匹配，E 的应用错误，F 缺少必要验证来源信息。统一标成“证明无效”，会掩盖实际问题。
精确失败分类也能防止过度指控。如果现有依据只显示文件错误、上下文缺失或界面说法无支持，就不应声称证明系统已经失效。
12. 数据模式改变剩余假设
某些基于证明的系统通过结算链发布重建数据；另一些使用另外规定的数据可用性安排。复核者必须确认选用模式及其验证或信任要求。
ZK Stack validium 文档介绍可配置的外部数据安排与单独的数据检查。存在有效性证明，不会让所有配置都等同于在基础链发布数据的模式。
本篇 B 明确是有历史发布依据、但较晚阅读者检索失败的情况。另一份如果在接受时缺少必要发布证据，问题就不同：接受条件本身尚未建立。不要混淆两条时间线。
同样，委员会对数据的已认证声明，是某种设计下对该声明的依据，不一定证明某位阅读者在较晚时刻拥有全部必要字节。
13. 基于证明，不意味着私密、即时或永不停机
有效性证明建立的是在相应假设下的指定关系。系统是否提供隐私，取决于哪些信息公开、如何处理见证，以及证明系统和应用实际提供哪一种隐私性质。
本例公共状态与赋值有意可见。把机制称为“ZK”，不会让 A4/B3/C7 变成秘密，也不会隐藏陈述有意公开的应用元数据。
有效证明也不能保证持续生成证明、持续排序、数据服务或基础链处理。系统可能停止产生新的接受状态，而没有攻击者生成无效证明。
以太坊有效性 rollup 概述介绍链外计算与证明验证。本篇证据清单将这些优点，与未说明的隐私、最终性时间、管理员和活性保证分开。
14. 退出证据是状态的另一个使用者
假设某应用提供基于特定已接受状态的抽象退出路径，阅读者可能需要状态数据生成必要见证，还需满足独立授权、防重放和基础链处理条件。
重建 A4/B3/C7 可以帮助满足一个前提，却不能单凭重建就证明阅读者有退出资格。反过来，如果必要数据缺失，已接受证明也不能保证它能生成见证。
真实协议的准确退出条件可能包含额外延迟或控制。本篇不声称即时提款，不提供真实退出步骤，只问使用已接受状态的主体还需要哪些依据。
同样推理适用于其他用途：索引器、审计者或应用查询可能需要重建数据包的不同部分。应从使用者的问题出发，而不是假定一个证明回答所有问题。
15. 练习：精确分类证据
使用以上虚构证据包规则。未另行说明的证明系统与合约正确性前提均成立。
- 从 A2/B5/C7 开始，应用 D17 的最终赋值 A4/B3。完整状态与总数是什么？
- B 提供已接受证明和历史发布依据，但阅读者缺少 D17。哪项结论仍未完成？
- C 验证 r0 到 r1，而 S 当前记录 r2。S 应接受它作为下一次更新吗？
- D 返回 A4/B4，且承诺不匹配。这是否单独证明关于 D17 的真实证明为假？
- 仅凭 D17 能区分一次移动2与两次移动1吗？
- E 针对 ArchiveOther 验证通过，界面可以把它重新标成 ArchiveAlloc 吗？
- F 只有绿色验证截图，缺少哪些关键证据？
答案与推理
- A=4、B=3、C=7，总数14。玩具格式保留未列出的键，因此 C 不变。重建的规范承诺还必须匹配 r1，算术不能代替这项检查。
2. 这位阅读者的状态重建未完成。给定证明、接受和历史发布事实并未消失，但不能从承诺推断缺失字节。
3. 不应。当前根条件失败。关于旧起点的数学有效陈述，不是覆盖应用当前状态的权限。
4. 不能。提供的文件不是 d17 绑定的数据。真实证明针对正确绑定的陈述，应报告重建输入错误，而不是已证明证明系统失效。
5. 不能。两种历史都可能产生相同最终赋值。完整历史恢复需要额外适当数据；状态重建与完整历史重放是不同任务。
6. 不能。应用标识符属于必要绑定，界面标签不能改变证明和合约检查实际建立的结论。
7. 缺少验证器和参数、准确陈述、网络与应用上下文，以及相关结算依据。截图本身不能证明预期主张已经检查。
16. 常见问题
使用有效性证明，每位阅读者都必须执行每笔交易吗？
本练习没有这种要求。验证可以在阅读者不重放每条指令的情况下建立指定关系，但重建仍需要所选状态格式要求的数据与起始上下文。
状态差异总是足够吗？
不是。只有具备必要的已认证基准状态，以及具体重建程序要求的所有其他数据类别，才可能足够。本例状态刻意很小，没有变化中的代码或额外消息结构。
证明验证能建立最终结算吗？
单独不能。合约上下文与接受条件、成功更新操作，以及相关基础链最终性证据，仍是独立检查。
资料来源与后续阅读
以下一手资料核对于2026年10月12日，新加坡时间：
- ZKsync OS 概述的 L1 集成部分：前后状态承诺与其他公共输入组成。作为具体架构例子，不作为正在部署的认证。
- ZKsync 数据可用性：状态差异及用于重建的其他公共数据。区分状态恢复与逐笔交易的完整历史。
- ZK Stack 中的 validium：数据模式变化和单独的数据验证要求。不笼统假定所有 ZKsync 链采用同一种发布模式。
- 以太坊零知识 rollup，页面最后更新于2026年9月8日：链外执行与有效性证明验证。不采纳无条件隐私、即时退出或可用性主张。
之前的证明课程解释陈述与见证，包含证明课程解释成员关系依据。本篇的新任务，是把证明、合约上下文和可重建状态连接起来，同时不扩大任何单项结果的含义。下一篇将进一步分析发布时的数据可用性、较晚检索和长期归档责任。