ERC-1923 证明登记处：给验证密钥上户口为什么比验证本身更难

给零知识证明做链上验证是数学问题，告诉全世界”该用哪个验证器、这份密钥是谁的”则是登记问题。ERC-1923 创建于 2018 年 12 月 22 日，状态 Stagnant，专门处理后者：它设想一个登记合约，验证密钥、验证器地址、证明记录都在这里挂号。标准原文的摘要里甚至留着一个公开的 TODO，询问这一层接口应该暴露哪些功能——这份坦诚恰好说明登记问题比验证问题更难定义。

登记的三级链条

从接口看，登记分三级。第一级是验证密钥：registerVk 把一份密钥存入登记合约，createNewVkId 为其生成编号，getVk 按编号取回，密钥从”一串曲线参数”变成了有编号的链上对象。第二级是验证器合约：registerVerifierContract 把某个以太坊地址登记为特定密钥的验证器，密钥与执行者的绑定关系从此可查。第三级围绕证明实例：submitProof、submitProofAndVerify 记录提交的证明，createNewProofId 分配编号，attestProof 与 attestProofs 允许第三方对某份证明作公证，challengeAttestation 则给质疑留了入口。

三级合起来构成一条信任链：编号化的密钥可追溯，验证器地址可归因，公证行为可被挑战。设计意图是让”这份证明由谁验证、谁为此背书”成为链上可查的事实，而不靠项目方口头声明。

与 ERC-1922 的关系

登记合约本身不做数学运算，验证动作留在 ERC-1922 式验证器里。两份标准是一对配套：验证器返回真假的机制加上登记处提供”该信哪个验证器”的答案。理解这层分工，也就能理解 1923 的困境——登记的价值完全取决于登记机制的可信度。谁有权登记、错误条目怎么清除、密钥换版如何通知存量依赖方，这些治理问题标准里只能给出函数形态，给不出答案。

停在纸面的原因

zk-SNARK 生态后来没有演化出链上登记处，原因在别处已经解决：验证器合约的地址、字节码和验证过的源码本身就是公开记录，开发者用文档与集成白名单完成”该信谁”的分发。把登记表放上链，反而引入新攻击面——登记合约一旦被控制，等于给全体依赖方投毒。链下注册表加代码签名审计，成了成本更低的均衡。1923 停在 Stagnant，与登记价值依赖共识而共识不可得直接相关。

读这份化石标准带走什么

三个关键函数的参数形状可以直接读出协议细节。attestProof 收三个参数：证明编号、验证密钥编号和一个布尔结果，公证人就坐在这三个字段上公开表态，批量版 attestProofs 把三组数组并排传入。challengeAttestation 的参数最重：质疑人必须重新附上完整证明数组、公开输入数组和验证合约地址，由登记合约当场重跑一遍验证。这个参数表等于规定了质疑的举证标准——不许空口翻案，只能重算推翻，谁质疑谁付出数据与 gas 的成本。

一个容易混淆的点也值得在这里说清：登记与验证的分离在密码学上绝不意味着安全可以外包。登记合约只回答”地址与密钥的对应关系”，它一旦被篡改，攻击者把某个验证密钥编号指向恶意验证器，依赖登记表的业务就会信任错误的验证器——登记表提供的是查找便利，不是信任来源，信任始终来自密钥参数自身的数学性质与验证器的公开审计。ERC-1923 设计 challengeAttestation 这种当场重验接口，正是清醒地知道登记可以被怀疑，唯一不可怀疑的是重算结果。

它给读者的校准工具落在”验证器的验证器是谁”这一问。凡涉及桥、证明型身份、隐私通道的产品，可以核对验证者合约是否独立可查、密钥参数有没有版本记录、升级路径是否公示在链上事件里。公证、质疑这些机制的教训同样朴素：登记本身不产生信任，信任来自登记背后那套谁签名、谁担责的安排。本文为机制说明，不构成任何投资建议。