ProveKit证明文件为什么校验不通：核release、产物配对与公开输入
链小知 · 进阶 · 核验 · 依官方文档整理
用既有非敏感构建日志定位v1.0.2/main、路径和递归产物错配，不生成或提交证明。
开始前准备
- 准备原release/commit、Noir/Rust工具链与lockfile、文件名/摘要/大小、命令参数和原错误；私人witness、Prover.toml内容、证明和身份文件不提交。
- 方法依据2026-10-14匿名读取的官方正文；只核已有脱敏材料，不登录、安装、连接钱包、生成证明、请求业务服务、签名或操作资金。
1. 固定release与实际host路径
当前文档以v1.0.2 tag和Noir v1.0.0-beta.26为可复现接口；v1 branch会前进，main可能破坏key/proof/recursive/API格式。CLI/Rust在作者文档检查通过，但WASM交叉验证未通过、iOS/Android仍pending，不能从C ABI/平台表就认定全宿主可用。
检查结果：原release/commit/toolchain/host有记录；未按当前main反推旧包。
2. 按产物角色读原命令路径
prepare产生.pkp及.pkv，prove消费.pkp+Prover.toml产proof.np，verify消费.pkv+proof。核实际输出路径而非仅扩展名。v1.0.2没有prepare --hash/--witness-mode，原参数拒绝不是证明无效。
检查结果：产物生产/消费对应同电路和路径，参数解析错误与验签失败分开。
3. 按改动范围核同一代产物
改变分支、commit、lockfile、工具链、电路或package应重新配对相关keys和proof；仅prover inputs变更通常更新proof而非keys。原.pkv不得配另一.pkp/电路/release的proof。缺文件、错误JSON、ABI/input编码与真正verify false分开保留，未取得原verify记录不能称已验证。
检查结果：产物来源和改动范围明确，缺失/格式错未补成有效或无效证明。
4. 将公开输入与应用授权分别核
对已有show-inputs输出核public input编码及应用期望；proof通过只能证明相应verifier key的约束满足，应用仍需判断输入是否授权该动作。输出文件存在、CLI exit0、HTTP成功和应用已接受不是同层结果；没有相关记录保留未知。
检查结果：原公开输入、密码学校验和应用授权结论分列，不把证明存在当身份/操作许可。
5. 递归导出按版本和实际验证边界收尾
v1.0.2 generate-gnark-inputs消费精确.pkp+proof.np并产params_for_recursive_verifier及r1cs.json；变更proof/key须重新配对。文档检查只生成递归输入，未运行Go proving/verification，server也未端到端验证；不能以“支持Groth16”保证某链合约可接受或所有WHIR承诺可传给wrapper。
检查结果：原recursive输入与来源严格关联，导出、Go验证、链上接受各保留证据边界。
怎样确认完成
- 形成按产品、身份、时点和原状态分列的检查表，缺证保留待核。
- verification=documentation；具体客户端、账户、证明验证、网络状态及资金结果未实测。
常见错误与边界
- 不同分支/版本格式不可自动兼容，public inputs也不能默许改字节。
- 宿主bindings存在、示例benchmark和成功导出不等实际业务验证或链上验收。