ERC-1922 验证器接口：让零知识证明在以太坊合约里得到真或假

零知识证明进入区块链的最后一站是合约：证明数据递交给链上验证器，验证器输出一个布尔值。2018 年的以太坊上，各家 zk-SNARK 实现互不兼容，换一个证明系统就得重写调用方。ERC-1922 就是为这个问题写的：创建于 2018 年 9 月 14 日，状态 Stagnant，它规定验证器合约的统一接口，要求调用方只依赖一个函数就能完成验证。这份标准依赖 ERC-165 接口探测和两条配对预编译能力，正文对怎么装载密钥讲得相当具体。

接口只有一个动作

标准的核心是一个 verify 函数：输入一段字节流形式的证明，返回布尔值，真代表证明有效。验证所需的一切参数——椭圆曲线配对运算要用的验证密钥——被要求预装载在验证器合约的存储里，调用时不再传入。这是一个关键取舍：把密钥从参数挪进合约，验证者地址就成了验证密钥的指纹，同一地址的语义必须终生稳定。为此标准要求合约声明自己支持 ERC-165 接口探测，让工具能先问一句”你是不是标准验证器”再发起昂贵调用。

配对的计算本身落在预编译合约上，验证器逻辑围绕预编译组织。标准讨论区里反复出现的担忧是曲线参数更新与密钥演进：验证密钥进了合约存储之后如何升级，被视作这套设计要长期面对的问题。

与 ERC-1923 的分工

同系列还有一份 ERC-1923 处理注册问题，两者构成”验证”与”登记”的分工：1922 管怎么验，1923 管怎么让人找到该用的验证器。理解这个分工能解释 1922 为什么把密钥固化进合约——一旦有注册表能按验证者地址查密钥信息，合约内的密钥就可以当作版本标识来用。

为什么没有统一生态

标准没能跑通的直接原因，是它规范的对象本身变化太快。2018 年前后主流方案围绕配对预编译组织，后来的 Groth16、PLONK、STARK 等系统各有各的验证结构，有些需要预编译之外的哈希与置换原语，一个只返回布尔值的 verify 接口装不下所有形态。更根本的是工程经济：项目方本来就按自己的证明系统设计验证器合约，接口统一带来的收益，抵不上密钥装载模式受限的代价。标准停在 Stagnant 是这个过程的记录。

今天读它的用处

标准用一组符号说清了密钥从哪来：证明密钥与验证密钥由同一个生成函数配对产出，电路与电路参数确定后，这对密钥随之确定。摘要里点出一个不对称：验证密钥比证明密钥小得多，正适合放进链上合约，因此合约里那份验证密钥就成了电路本身的可信代表，验证密钥编号实质上是对电路的紧凑映射。理解了这层”小密钥代表大电路”的关系，才能理解后面注册标准为什么给密钥单独立户——密钥在链上的身份，就是电路在链上的身份。

对普通持有者而言，这套抽象会落到很具体的产品形态上：链上身份核验、隐私钱包的匿名凭证、跨链桥的证明验证，用户界面背后都是同一个模式——你的客户端生成证明，一个验证者合约点头，业务合约放行。此时验证者合约就是整个信任链最沉默也最要紧的一环，它不出现在宣传页上，却决定了”证明有效”这四个字的含金量。ERC-1922 用一个布尔函数就把这环固定下来，恰好提醒读者：看产品时顺着证明提交交易找过去，第一个被调用的合约地址，值得和合约源码一起读完。

这份标准的现实价值在理解链上证明产品的核对方式。一个使用零知识证明的桥、身份或隐私产品，最终都落在一个验证者合约上。读者可以把标准的设计意图转成三份核对动作：先用 ERC-165 探测确认接口身份，再查验证者合约的密钥装载与升级路径由谁控制——密钥若可被单方面替换，之前所有”验证通过”的历史都要重新解读，最后核对验证者地址在交易记录里确实出现在证明提交路径上。看到”零知识”宣传时，真正要看的是那个返回布尔值的合约。本文为机制说明，不构成任何投资建议。