属性不在集合合约里：ERC-7508 的公共链上属性仓库

大多数 NFT 的属性写在自己集合合约的内存映射里，或者干脆塞进链下元数据 JSON。ERC-7508 走了第三条路：让代币把属性写进一个对所有人开放、在所有网络部署在同一地址的公共仓库合约里，任何外部合约想读属性都直接读这个仓库。该提案状态为 Draft（草案），创建于 2023 年 8 月 15 日，依赖 ERC-165。本文按规范文本讲结构，不构成任何投资建议。

一个公共合约，替所有集合记账

规范的定位是”公共利益仓库”：任何 ERC-721 或 ERC-1155 兼容代币都可以把属性放进去，放进去之后，属性与代币合约本身解耦——集合合约升级、迁移甚至部署失误，属性记录仍然留在仓库里。这就是文档强调的”属性的永久存储”与”跨集合交互”：两个毫无关系的集合可以共享同一套属性键，条件类应用（比如”属性满足 X 才能进入”）只需对接一个仓库地址。

六类属性与五种谁能写

仓库按数据类型分了六套读写函数：地址型、布尔型、字节型、有符号整数、字符串、无符号整数，每类都有单条与批量版本，并有 getAll 系列查询。谁能动某个属性由访问控制表决定，规范定义了五种类型：仅合约 Owner、协作者（Collaborator）、Owner 或协作者、代币当前持有者（TokenOwner，也就是玩家自己改自己代币的属性），以及指定的特定地址。合约还可以用升级函数替换某个属性的写入规则。

读属性之前，先问三个问题

正因为属性搬进了公共合约，核验逻辑也跟着变了。第一，这个代币集合声明的仓库地址是哪个？规范说仓库”在各链同地址”，但一个项目具体接入的是哪个部署实例，仍然要以链上注册与项目文档为准，地址相近的仿冒仓库理论上存在。第二，某属性键当前的访问控制是哪一档？TokenOwner 意味着持有者能自己改值，作为条件判断依据时要小心刷属性。第三，属性在不在仓库里是一回事，代币合约是否真的把仓库当回事是另一回事——仓库里的键和某个游戏逻辑是否联动，取决于那个应用的代码。

与把属性写进元数据相比

链上属性可被合约即时验证，适合做组合性条件，代价是每次修改都要花 Gas；链下 JSON 属性改起来便宜、随时可变，适合作展示但不适合做安全条件；写死在集合合约里则最稳定，却和合约生死绑定。ERC-7508 属于草案阶段的尝试，采用它的集合数量与工程成熟度都要自行确认，不宜把”标准存在”理解为”生态通用”。

谁在改你的属性：事件与权限留痕

规范为各类属性的写入设计了成对事件（如字符串、整数、地址、布尔、字节各属性设置时发出的对应事件），并配了 getAll 系列一次性读出全部属性。核验某段时期属性有没有被人动过，理论上可以按事件逐条回放；访问控制侧，registerAccessControl 建立规则、manageAccessControl 做后续变更，这类动作同样有链上痕迹。相比之下，链下 JSON 的属性修改完全静默，这也是链上属性派最强的卖点。

评估一个采用 ERC-7508 的项目时，可以把问题问得更具体：属性仓库由谁部署、有没有多签管理？哪些键开放给 TokenOwner、哪些锁在 Owner 档？集合迁移时属性是留在仓库还是要搬迁？三个答案拼起来，才能判断”属性永久在链上”这句宣传的实际含金量。仓库是共用基础设施，共用也意味着共用故障面和共用攻击面：读属性前先确认仓库地址、访问档位与键的含义说明，比看任何宣传页都可靠。本文仅为机制科普，不构成投资建议。