ERC-7734 去中心化身份验证：链上只存哈希时，身份到底被证明到哪一步

“链上 DID”这个词常被用得太重。ERC-7734（Decentralized Identity Verification）做的事情其实很克制：把一个身份表示成哈希，登记到合约里，再用两个哈希的比对来翻转”已验证”开关，其余细节一概留在链下。按以太坊 ercs 仓库的记录，这份提案状态为 Final，创建于 2024 年 6 月 26 日。理解它的最好方式，是看清它证明了什么、没证明什么。

一个结构体加四个函数

标准里的身份是一个结构体：持有者的地址、身份数据的哈希 identityHash、用于验证的两个哈希 verificationHashes（一个长度为 2 的数组）、布尔值 isVerified，以及创建时间戳。接口一共四个函数。createIdentity 接收 identityHash，为调用者建立一条身份记录，发出 IdentityCreated 事件。verifyIdentity 接收两个验证哈希——它们可以来自第三方验证机构、文件或链下签名——合约把它们与登记值比对，一致就把 isVerified 置真并发出 IdentityVerified。getIdentity 供任何 dApp 免 Gas 查询某地址的验证状态。revokeIdentity 允许持有者撤销身份，发 IdentityRevoked，对应数据被删除或失效应重新验证的情形。

整套设计的关键词是”极简”：标准明确说身份就是地址加哈希，姓名、年龄、证件这些属性是可选的、由链下机制管理。这样做的好处是合约小、通用性强，任何 dApp 都能把验证细节外包给外部证明体系；代价是所有语义都压到了链下。

哈希进链，不等于事实验证

这是全文最需要讲透的一条。链上记录能证明的是”存在某个哈希在某时被登记，且另一个哈希与它相等”。哈希由谁计算、输入数据是否真实、验证机构是否可信，这三件事合约一概不管。一个项目如果自己算了一个”实名哈希”写进合约，它证明的只是这个项目做过一次登记。所以读任何 7734 类系统，先找哈希的生成规则和比对规则写在哪：写在第三方签名文件或权威机构凭证里的，验证链才有支点；只在项目自己数据库里的，那只是给内部记录盖了个链上时间戳。

隐私上的一致性哈希也有泄露面

标准文本专门提到碰撞问题，提醒实现者身份哈希不能天真构造。如果 identityHash 只是对身份证号、手机号这类低熵信息直接哈希，攻击者可以穷举候选值再比对哈希——哈希在此时更像指纹而不是保险箱，谁拿到它就能反推原文。真正稳妥的做法是让哈希掺入只有当事人知道的随机盐，或改用零知识承诺，把”可验证”和”可反推”分开。地址本身作为身份主键同样意味着行为可以被关联：同一个地址在多少个验证合约里登记过，它的链上画像就拼出多少。

对普通用户意味着什么

事件回放：一条身份的完整生命线

把三个事件按地址串起来，就是这份标准留给审计者的全部叙事线：IdentityCreated 标记某人以某个身份哈希入场，IdentityVerified 标记某两个验证哈希通过了比对，IdentityRevoked 标记当事人撤回。时间戳让顺序自证，无需信任任何数据库。值得留意的是状态机的隐含边界：标准允许撤销后再次创建，此时链上会出现两条生命线，轻率的工具若只按地址取最新一条，可能把旧周期里”已验证”的历史误读成当前有效。稳妥的查询姿势永远带时间维度——先 getIdentity 读当前值，再回看事件序列确认中途没有未处理的撤销。对把 7734 当准入门槛的应用，把”验证状态可能随时被持有人单方撤销”写进产品逻辑，比如每次敏感操作前重新查询而不是仅在注册时查一次，才算跟上接口的语义。这份 Final 标准的聪明之处正在于此：功能少，但每一条状态变化都不给”悄悄变更”留余地。

当某个平台说它”用了 ERC-7734 做 DID”，值得追问三件事：验证哈希的来源机构是谁、revokeIdentity 之后历史事件是否还能被拼出旧状态、以及哈希的生成是否带盐。这份 Final 标准提供的是一个可审计的最小骨架——创建、验证、撤销全部有事件可回放——但骨架上的肉长得好不好，取决于链下那套证明体系。本文为机制说明，不构成任何投资建议。