一个地址一份属性档案：ERC-1616 属性登记处的扁平账与唯一值约束

合约在决定是否给某个地址放行之前，常常需要先确认关于它的一件事：它是不是审计机构名单里的地址？它有没有被标记为风险地址？ERC-1616 给这类问题定了一套统一问法，标准正文把自己叫作属性登记处。它的文件头记录创建于 2018 年 11 月 23 日，按 ercs 仓库当前记录状态为 Stagnant，声明依赖 ERC-165 接口探测。

把信任抬到登记处一层

标准开篇的动机很直白：验证方通常没有能力逐家核实签发方的说法，与其相信一个个独立的声明来源，不如把信任集中到一个登记处策展人身上。需要验证某个属性的合约只跟登记处打交道，属性从哪儿来、怎么采的，登记处内部自己消化。这就是它把“声明”与“签发方”解耦的理由：声明在链上被抽象成纯粹的键值对，签发者身份不出现在查询路径里。

扁平结构与被刻意保留的简单

规范给每个账户挂的是一张“属性编号到属性值”的映射，键和值都是无符号整数。原文反复强调一个关键性质：同一种属性对同一个地址只允许一个权威值。举例说，如果登记处把“隶属关系”定为一种属性，那么一个地址要么登记为这个值要么登记为那个值，不能同时挂两份互相打架的记录。这个唯一性约束是组合性的地基——多个登记处互相引用时，不必先做一轮“到底信哪条”的仲裁。

接口只有四把查询加一个枚举工具：按地址和属性编号取值、判断地址是否持有某属性、数一数登记处里一共有多少种属性类型、以及由属性名称反查属性编号。标准故意不规定属性的值从哪来、怎么更新、值本身要不要再挂元数据，它赌的是：先把“问”的接口统一，把“写”的自由留给生态，甚至留给后续的独立标准去补。

示例合约里的白帽与黑帽

原文的参考实现定义了一个只有两个成员的枚举：白帽和黑帽，用静态数组记录两种属性类型的编号和各自的签发计数器，再用嵌套映射按地址与属性类型存放已签发的属性编号。这个例子的信息量比看起来大：属性编号是签发时分配的递增序号，而“某地址属于白帽”这种事实被编码成“该地址在某属性类型下的值等于某个编号”。想表达复合判断，标准允许把多个属性编号组合进一个键里，由登记处逻辑自己解析——相当于把布尔表达式塞进键名。

边界与盲区

谁来写这张表

原文对写入侧几乎不作约束，这种留白本身就是设计立场：登记处逻辑可以自己决定属性值随什么事件变化——可以是一次人工签发，也可以是另一个合约的回调结果，接口层面一概看不出来。站在调用方的位置，能确定与不能确定的东西要分得很清。能确定的是：查询返回的是登记处当前的权威值，同一笔交易里重复查询结果一致；不能确定的是值的来路与时效。原文设想的进阶用法——把一个复杂布尔表达式编码进一个属性编号、由登记处逻辑现场解析——意味着返回值甚至可能不是存量数据，而是查询瞬间现算的结论。这类登记处读起来像函数调用而不像数据库，缓存策略、事件订阅（规范本身没定义值变更事件）都得由实现各凭自觉。把 ERC-1616 当组件评估时，问题清单应该包括：登记处合约的写权限归谁、有没有变更事件可供订阅、属性编号表是否公开，三问之后再看它在你的信任模型里能顶替多少人工尽调。

状态是读这份标准时绕不开的一环。Stagnant 意味着提案在仓库记录中已长期停滞，没有形成广泛部署的参考实现，也不构成任何兼容性承诺；把它和活跃标准混为一谈是误读。第二重盲区来自结构本身：一个属性只有一个权威值，登记处要改口只能覆盖写，历史值不在接口能回答的范围里；谁在什么时候写了什么，标准没有给审计视图，调用方只能信登记处当前状态。第三重盲区是值的语义：规范只保证类型是无符号整数，编号对应什么含义完全由登记处自定义，换一个登记处，同一串数字可能是完全不同的意思。读任何自称实现 ERC-1616 的合约时，先用 ERC-165 探测它是否真的申报了这个接口，再去它的文档里核对属性编号表，才能把接口兼容性换成对语义的理解。本文为机制说明，不构成任何投资建议。