区块链（34）：Validity rollup 的证明到底验证哪条命题把公开 statement 与 witness 分开，验证的是“这个有限订单状态转移存在满足约束的见证”，而不是“现实交付真实”。E03 更进一步：选择特定证明工具时须记录代数/执行约束、公开输入、验证密钥、可信设置（如有）、证明生成内存时间与验证时间；不同构造的成本不能用家族名推导出统一数字。 
flowchart LR
  T[订单输入/旧状态] --> C[约束: 授权/守恒/单次消费]
  C --> P[证明器 + witness]
  P --> PROOF[proof]
  PROOF --> V[验证器 + 固定验证参数]
  T --> V
  V -->|接受或拒绝| S[仅对声明命题有效]

如果约束没写“卖家提现额不得超过余额”，证明系统可以完美证明一个错误需求；如果公开订单 ID 不绑定，证明可能被移用到另一笔订单。某些 SNARK 构造需要可信设置，某些 STARK 设计使用不同的透明性和证明规模权衡；“零知识”是否成立还取决于协议与 witness 暴露，不由简洁证明三个字自动提供。证明合法也不保证用户拿到链下重建数据。

先写 statement，再决定要不要隐藏 witness

为教学托管规定公开元组 (链 ID, 合约版本, 订单 ID, 旧根, 新根, 可提现总额)。见证提供对应订单的授权、旧余额、消费标记及状态路径。约束须逐项检查：授权对应公开订单与版本；旧状态属于公开旧根；订单此前未消费；新状态把同等金额记入待领债权且不凭空增加资产；新根由转移后的记录得到。若故意删去订单 ID 绑定，两笔同额订单可能共享看似有效的证明输入；删去旧根绑定，就可对任意起点计算新根。上述是待实现电路的规格草图，不是已经通过的密码学验证。

最小拒绝对照至少包括改动公开订单 ID、旧根、金额、验证密钥版本，分别证明验证失败；还要提供一组满足约束的真实 witness，记录 proof 字节和生成/验证器退出码。比较 SNARK/STARK 成本时，必须让两个实现证明同一语义（包括公开数据量）、同一安全参数等级，并分开报告设置、证明、链上验证、验证密钥存储和 DA 成本。若只有空电路成功、摘要匹配或人为返回布尔值，无论工具输出多漂亮都不能称为通过。

练习一：哈希比较器返回 True，是否等价真实证明验证成功？答案：不等价，没检查 witness 满足转移约束。练习二：公开输入只含新根不含旧根，允许什么偷换？答案：无法把转移绑定到指定初始状态，须补旧根或相应可验证链接。当前未冻结真实证明工具，生成/验证/篡改拒绝与成本测量 NOT_RUN，不编造性能。

可迁移原则：证明安全性首先取决于完整的语义约束。参考：Ethereum zk-rollup 说明、STARK 论文入口（原文待核）；导航：区块链（E02）：SegWit、Schnorr 与 Taproot 的三个升级维度 · E03 · 区块链（E04）：智能钱包、代付与会话权限怎样收回。