机器人也要链上身份：ERC-7777 的双重身份与宪章规则集

大多数链上身份接口默认主语是人。ERC-7777 的出发点是把主语扩到两类：人类与机器人，为它们共同生活的去中心化社会定义身份和规则。文件头记录创建于 2024 年 9 月 29 日，仓库记录状态为 Review，作者信息里同时出现了 OpenMind 与 Nethermind 的工程师。读这份标准最有价值的不是结论，而是它把“身份”拆成了两层。

第一层：我是谁

IUniversalIdentity 负责注册。registerUser 登记一个链上主体，getUserInfo 读回资料，leaveSystem 退出。它的特色在机器人分支：每个机器人同样由一个智能合约代表，登记时除了公钥，还可以提交制造商、操作员、型号、序列号这类硬件身份参数。规范设计了完整的挑战应答流程——generateChallenge 发起、verifyChallenge 验证，硬件侧用安全元件里生成的私钥对挑战签名，任何持有机器物理所有权的人都可以让机器自证身份。getHardwareIdentity 读出登记的身份参数，updateHardwareIdentity 处理密钥轮换。这套设计的意图写得很明白：身份要能在物理世界里被验真，而不只是一个链上声明。

第二层：我们守什么规矩

IUniversalCharter 管理宪章。addRule 与 removeRule 增删规则条目，updateRuleSet 整体更新规则集，getRule 与 getRuleSet 逐条或整体读取，getRuleSetVersion 与 getLatestRuleSetVersion 回答“我现在受哪一版约束”。主体的参与动作有 subscribeAndRegisterToCharter 一步加入、leaveCharter 退出，getSubscribedCharters 列出某个主体报名了哪些宪章。合规检查由 checkCompliance 与 getComplianceStatus 承担，updateCompliance 记录状态变化。宪章可以自己 terminateContract 终止。

怎么读这份提案的现在时

规则集版本与合规状态的分界

接口表里两组函数容易被混读，分清它们才算读懂设计。规则一侧——addRule、removeRule、updateRuleSet 及版本查询——管的是规矩文本本身：宪章要求成员做什么、禁做什么，版本随修订递增。合规一侧——checkCompliance、updateCompliance、getComplianceStatus——管的是每个主体相对规矩的状态：某台机器此刻算不算守规矩、状态何时更新。规矩是公共的，状态是个体的；版本查询给所有人同一个答案，合规查询因人因时而异。机器人的硬件身份验证嵌在这套结构的入口处：_checkRobotCompliance 与 _verifyRobotHardware 在原文参考实现里承担进场前的把关，注册者若声称自己是机器人，就要在挑战应答中用安全元件签名自证，身份参数里的制造商与序列号供物理世界核验。标准没有规定违规的后果——惩罚逻辑属于宪章自身的规则条目——它只提供身份、规则、状态三层可查询的事实底座，让奖惩实现有账可依。这个克制的分层，正是它作为接口标准而非治理产品的位置。

三个注意点。第一，状态是 Review，即仍在评审流里，接口定稿前都可能改动，把它当已生效规范引用是错误的时态。第二，硬件身份的可信度完全押在“安全元件不可导出密钥”这一物理假设上，标准本身不制造可信硬件，它只是给可信硬件的签名一个链上问法；制造商与操作员字段的真实性同样依赖登记环节的治理，合约无法自动分辨一份伪造的序列号声明。第三，规则集的版本链解决的是“当下生效的是哪一版”，历史争议的裁决要回看旧版本，调用方必须自己保存版本快照，规范没有内置历史仲裁。它最终呈现的图景是：治理对象不再只有人和合约，物理机器人也要有可验真的身份证与可查询的规矩本——这两件事各自有接口，合在一起才是这条提案的全部野心。本文为机制说明，不构成任何投资建议。