证明也有说明书：ERC-8084 零知识证明元数据接口

越来越多 NFT 功能在幕后用到零知识证明：白名单不公开地址名单的资格验证、隐私铸造、跨链桥的轻客户端校验。用户看到的只是“证明通过、铸造成功”，但这份证明由什么系统生成、对应哪份电路、约束了哪些字段，链上一直没有标准问法。ERC-8084 把这份缺失的信息叫 ZKMeta，给依赖零知识证明的合约规定了一份统一说明书。按 ercs 仓库记录，提案状态为 Draft（草稿），创建于 2025 年 11 月 10 日。

六个只读函数

接口 IZKMetadata 全部是 view 函数：proofSystem() 返回四字节标识，声明用的是哪类证明系统；circuitId() 返回 bytes32 的电路标识；circuitVersion() 给出电路版本号；publicInputsSchemaHash() 与 publicInputsSchemaURI() 分别给出公共输入结构定义的哈希和获取地址；verificationKeyURI() 指向验证这份证明所需验证键的下载地址。规范刻意不规定任何具体证明格式——它只统一“怎么问”，不统一“答什么”。

这份说明书解决什么问题

对工具开发者，价值在于免配置：钱包、区块浏览器、中继器不用为每条链每个合约维护一张人工参数表，接上接口就能自动识别电路版本和输入约束，电路升级后也能从 circuitVersion 的变化里察觉。对安全审计，验证键与公共输入结构的哈希可对比，证明“线上跑的电路”与“审计报告里的电路”是不是同一份。普通用户最容易感知的一处是铸造核验：如果资格证明合约暴露了这些字段，钱包可以在你签名之前提示“该证明的公共输入只约束了 Merkle 根，未约束接收地址”这类事实，而不是让你对一个黑盒盲目确认。

说明书不是成绩单

必须把边界说透：元数据只回答“这份证明声称怎么验”，不回答“验得对不对”“电路有没有漏洞”“URI 指向的服务器还归不归项目方管”。publicInputsSchemaURI 和 verificationKeyURI 都是字符串地址，可能是去中心化存储，也可能只是项目方的某个域名——哈希字段能证明内容没被换过，前提是你信任那份哈希被正确发布。换句话说，ERC-8084 把审计线索标准化了，它本身不提供任何保证。

和相近概念怎么分工

零知识证明相关标准各有分工：证明系统本身（如各类 succinct 论证）规范数学层；链上验证合约规范调用层；ERC-8084 规范的是“描述层”，三者互不替代。NFT 语境里也常被混谈的是 ERC-6454 一类的锁定接口与元数据哈希——那些管资产能不能动、内容有没有变，ZKMeta 管的是证明的可解释性。读文档时问清楚对方在讲哪一层，可以避免大量鸡同鸭讲。

使用前的自查清单

解析器的第一行代码

把六个函数接起来之前，工具作者要先回答“这份元数据从哪来”。publicInputsSchemaHash() 是唯一的自校验锚点：链下取回的 schema 文件重算哈希，对得上才继续解析，对不上就当不存在。circuitId() 与 circuitVersion() 的变化应当进监控，电路升级常常先于任何公告发生；proofSystem() 的四字节标识最好落在一个可枚举的白名单里，遇到未知方案宁可降级为“无法核验”，也不要猜。钱包在 ZK 铸造弹窗里能做的增量提示其实很多：把公共输入字段列成一行清单——哪些约束了接收地址、哪些只约束了 Merkle 根——比在帮助页写一万字“我们使用零知识证明”都更能建立信任。接口没有规定证明格式，恰恰把这份诚实留给了读的一方。

草稿状态的提案意味着现实里大多数合约还没实现它。当某个 ZK 铸造或桥接产品声称“符合 ERC-8084”，可以直接在浏览器里调用这几个函数试试：调用不存在的 revert 本身就是答案。读得通之后再核对三件事——proofSystem 是否是你听过的公开系统、schema 哈希与公开文档是否一致、URI 是不是可长期访问的中立存储。说明书缺失不必然代表作恶，但说明书齐全还不敢公开哈希的产品，值得多留一分警惕。本文为机制说明，不构成任何投资建议。