ERC-7812 ZK 身份登记处：把私密数据的承诺写进稀疏默克尔树再证明

很多人以为隐私证明是把数据加密后存链上。ERC-7812（ZK Identity Registry）走的是另一条路：数据本身不进链，进链的是数据的承诺，日后需要时再用零知识证明”我的承诺在这棵树里”，而树外的人依然看不出承诺背后是什么。按以太坊 ercs 仓库的记录，这份提案状态为 Review，创建于 2024 年 11 月 8 日。

先分清楚三个词

标准给了精确的定义。statement 是抽象证据的结构化表示，可以简单到一个字符串，复杂到另一棵树的根。commitment 是把 statement 用一个私有盐”加盲”后得到的公开值——同一个 statement 配不同的盐会得出不同承诺，盐被称为 commitment key，必须保密，否则承诺就有被穷举反推的风险。整个体系的玩法是：用户把承诺写入链上数据库，向合约证明拥有它时不出示 statement 本身。

两个组件与一棵树

系统分两层。EvidenceDB 是可证明的键值数据库，标准要求它支持增、改、删三类写操作，并且保持幂等——添加后删除应让数据库回到原状——数据结构必须同时支持存在性证明与排除性证明，选型上推荐面向零知识友好的稀疏默克尔树，常用 Poseidon 哈希。写函数只能由注册表调用。EvidenceRegistry 是入口合约，转发写请求并维护树根；每当根变化就发出 RootUpdated 事件，getRoot、getRootTimestamp、getProof、getSize 等函数供查询。标准还给出一份链上单例注册表地址供各项目接入自己的 Registrar——业务层的 Registrar 负责把具体场景（比如某种资格名单）整理成结构化承诺再写进 EvidenceDB。

排除性证明值得多说一句：Merkle 证明不仅能说明”某个承诺在树里”，还能说明”某个位置没有承诺”。这在黑名单场景中很实用——证明”我不在受限名单里”而不暴露自己进了任何名单。

场景视角：它能证明什么，不能证明什么

用一个具体场景理解边界。假设某协议把某项资质的签发记录组织成 Registrar 写进树里，用户可以在提交申请时生成零知识证明：自己的承诺位于当前根之下。合约验证的证明结构里带着 root、siblings、existence 布尔值与键值字段。这条链能严格证明的是”某承诺是该链上集合的成员”。它不能替你证明的是签发那头的事实：Registrar 由谁运营、依据什么把承诺写进树，仍在链下。另一个现实提醒来自树本身：getRootTimestamp 让客户端能发现根太旧——证明若基于明显过期的根，说明同步出了问题。

对新手的使用姿势

根时间戳与同步纪律

零知识承诺体系的日常事故大多不出在密码学，而出在同步。getRootTimestamp 存在的意义就是把”你手里的根多旧”变成一个可查询量：证明电路验证的是某个历史根下的成员关系，若应用拿着一周前的根去做今日的准入判断，一个已被移除的成员依然能通过验证——排除性证明尤其依赖新鲜的根。客户端的纪律因此有两条：验证前先比对根时间戳与业务时间要求，超出窗口就拒绝并要求刷新；把 RootUpdated 事件流接成订阅，而不是定时轮询碰运气。另一个细节来自树的幂等要求：标准规定添加后删除应使数据库回到原状，这意味着同一承诺反复登记不会撑大树或抬高证明成本，但也要求 Registrar 的写入逻辑诚实——删除必须真删，把”软删除”实现成状态位而树内记录仍在的做法，会让排除性证明的语义悄悄失效。对终端用户，可以把这三问当作体检题：证明请求里的 root 是哪一块的？谁有权限写这个 Registrar 的删除？撤销承诺之后旧证明还会被旧根接受吗？三个问题都答得清楚的系统，才配得上”零知识身份”四个字；Review 阶段的接口细节仍可能微调，接入前以合约实现为准。

若某个应用宣称基于 ERC-7812，可以问三个不吃术语的问题：数据到底进没进链（正确答案是没进，进的是承诺）；盐掌握在谁手里（用户自己保管才谈得上选择性披露）；谁有资格往 Registrar 里写（决定这份证明在现实世界的分量）。Review 状态意味着接口仍在讨论中，接入方以合约实现为准。本文为机制说明，不构成任何投资建议。