合约怎么验一份 AI 推理的证明：ERC-7992 模型登记与 proofSystemId

链上合约面对机器学习有两个死结：它跑不动大模型，又没法直接采信“模型说是这个答案”的第三方报告。2025 年 7 月 23 日创建的 ERC-7992 想用零知识证明解开这个结： prover 简洁地证明“特定模型、特定输入，得出了这个输出”，合约只验证明、不跑模型。按 ercs 仓库记录，这份标准状态为 Draft，原文把自己定位成把可验证推理做成可复用组件——像 ERC-20 之于资产那样。

登记处先发号

一切的起点是 ModelCommitment：一个把模型权重哈希、架构、证明电路（AIR）与验证键捆在一起的承诺包。合约把承诺登记进注册表，领回一个 modelId（uint256）。此后所有调用都引用这个号，谁也不用再猜“你验的到底是哪一版权重”。注册表通过 ERC-165 对外宣告互通性。这层设计的价值在组合性：DeFi 风控、预测市场、保险理赔引用的 AI 输出，第一次有了统一的“指向哪张模型”的链上句柄。

verifyInference 与三种 ID

验证侧的核心函数是 verifyInference(modelId, inputCommitment, output, proof)：查登记、把验证分派给声明的证明系统、任何不匹配或证明无效即 revert，成功则发 InferenceVerified 事件。参数各有一本账。inputCommitment 是对全部私有输入与声明的公开输入的哈希承诺，标准要求实现必须做域分离，遇到一次性或非确定性场景还应带上 nonce 或盐，这是防重放的硬约束。output 是 ABI 编码的公开输出，消费方要约定好结构。proofSystemId 是证明系统的身份证：取“规范名加版本”小写连字符字符串（例如 groth16-bn254-v1、plonk-bn254-v2）做 keccak256 后的前四个字节。换 Groth16 为 Plonk？登记处里换个 proofSystemId 即可，调用方 ABI 一行不改——可插拔就是这四个字节撑起来的。

可选的留痕扩展

标准还备了一个可选扩展，把已验证的推理记录持久化下来，供审计和确定性结算回看。原文把这条列为 MAY，因为逐条上链的成本不低：验证频率高的场景全存会撑爆存储，只发事件又无法离线复核历史，取舍交回给应用。

边界在哪里

动机清单里的三个现状与防重放的算法规定

动机部分先把现状批了一遍，批评得相当整齐：项目方要么信一个中心化服务器报来的模型输出，要么把模型阉割到能塞上链的规模，要么组一个人类委员会投票裁决——三条路都拿不出密码学层面的保证。零知识机器学习能补这个洞，但原文指出若没有统一接口，每个 dApp 与验证器都是定制品：ABI 互不相同、注册表字段自说自话，组合性归零。ERC-7992 要标准化的是那条链上边界线，收益清单里排第一的是“无需许可、可组合的 AI 预言机”，接着才是隐私输入保护、确定性结算、审计成本下降与证明系统演进时的前向兼容。

proofSystemId 的算法值得逐字读：对“规范名加版本”的小写连字符字符串做 keccak256，取结果的前四个字节；标准给了 groth16-bn254-v1、plonk-bn254-v2、stark-airfoo-v1 三个示例。字符串规范化本身就是防碰撞设计——大家从同一个拼写算出同一个 ID，可插拔性靠哈希而非注册审批。输入侧同样有明文规定：inputCommitment 必须做域分离，在一次性或非确定性场景下应当带 nonce 或盐，这是把重放攻击写进规格而非留给实现自觉。输出那段有个容易漏的从句：output 只是 ABI 编码的字节，schema 由消费方约定，若要上链锁定输出结构，得另用 outputCommitment——而后者被注明不在最小接口里。登记、承诺、验证、可选留痕四件事各归各位，读这份 Draft 时按这四层找函数就不会迷路。

验证成功说明“对登记在册的这份承诺，此证明在密码学上成立”。它不说明模型本身合理、训练数据无害，也不说明输出在现实意义上正确——密码学保证的是推理过程与声明的模型一致，仅此而已。链上引用 AI 结论的程序，仍要自己评估模型风险。本文为机制说明，不构成任何投资建议。