一枚 NFT 挂一串身份：ERC-7231 聚合身份的链上结构

把”这枚 NFT 的主人同时也是某个邮箱、某个社交平台账号的持有者”这类信息带上链，是身份类应用的常见诉求。ERC-7231（Identity-aggregated NFT）给出的方案不是把身份明文写上链，而是把一堆身份哈希汇总成一个根哈希（identitiesRoot）存进 NFT 合约，验证时再出示明细和签名。该提案在以太坊标准体系中的状态为 Final（最终标准），创建于 2023 年 6 月 25 日，依赖 ERC-165、ERC-721 与 ERC-1271。本文只讲机制，不构成任何使用或投资建议。

三个函数各管一段

合约层面只有三个接口。setIdentitiesRoot(id, identitiesRoot) 把某枚代币的身份根写上去，并发出 SetIdentitiesRoot 事件；getIdentitiesRoot(id) 是查询函数，返回当前记录的 bytes32 根哈希；verifyIdentitiesBinding 做验证——传入代币编号、NFT 持有者地址、一组声称的 userID、根哈希和一份 ECDSA 签名，合约按标准规则校验，通过返回真，否则返回假。规范同时给出了配套元数据 JSON 里 MultiIdentities 数组的结构，用于描述这些身份条目的展示信息。

根哈希的设计意图

设计逻辑和默克尔树思路一致：链上只留一个 32 字节的摘要，身份明细留在链下；需要证明”我持有的 NFT 绑定了某个身份”时，出示 userID 加哈希路径，让合约把明细重新聚合成根来比对。这样链上观察者在默认情况下看不到具体身份，只有参与验证的交互方会知道被披露的那几条。

它不能替你解决的隐私问题

要清楚这条边界的另一侧：根哈希不可逆推，但可关联。同一个人管理的多枚 NFT 若使用相同身份结构，行为模式本身就可能被聚类；一旦链下某处的明文身份清单泄露，根哈希就变成”可验证的指认工具”——任何人都能拿它核对猜测。此外，签名的签发方是谁、身份认证在什么条件下做、撤销机制在哪里，这些都不在标准之内，取决于具体实现。把邮箱号、真实姓名关联到公开可查地址上之前，值得先想清楚链上数据的不可删除性。

使用与核验清单

1. 链上调用 getIdentitiesRoot，返回值全零说明从未绑定。
2. 做验证方时核对签名的发证合约与 verifyIdentitiesBinding 所在地址是否官方部署。
3. 作为持有者，写入前先确认该合集是否会同步展示明文身份，元数据 JSON 里的 MultiIdentities 可能比链上字段暴露得更多。
4. 撤销身份在标准里没有专门的函数，通常靠重设根哈希完成——重设是否留事件记录，要看实现。

验证依赖谁：签名从哪来才作数

verifyIdentitiesBinding 里的 ECDSA 签名是关键信任件——它对应的是身份认证服务方对”这些 userID 与这个根哈希绑定”的背书。标准把签名校验写进接口，但没有规定签发方是谁：同一套接口可以挂中心化的认证服务商，也可以挂去中心化身份签发器，信任含义天差地别。核验一枚带身份根哈希的 NFT 时，值得先问三件事：根哈希由哪个合约写入、验证用的合约地址是否与官方部署一致、签名的发证公钥属于哪家认证方。这三个答案决定”绑定成立”这句话到底值多少。

谁在链上读这些身份

把身份根写上链的最大收益是组合性：条件类合约可以调用 verifyIdentitiesBinding 做准入判断，比如”持有该 NFT 且绑定了某类身份凭证的地址才能进入”。这也带来新的暴露面——每一次链上验证都是一笔可被观察的调用，参与验证的合约地址、时间与被校验的(userID) 集合都可能进入他人分析视野。做隐私评估时要把两条线分开：链上静态数据（只有根哈希）与链上交互行为（谁在什么时候向哪个合约证明过什么）。前者保护得好，后者仍可能泄露得多。实践折中是让证明尽量走一次性、离链验证的通道，只在必须被合约强制执行的场合才把验证放上链。

另一面是对持有者的提示：身份绑定是双刃剑——方便核验的一方，永远同时是可能被画像的一方。本文仅为标准机制科普，不构成投资建议。