给藏品画关系网：ERC-7085 的派生关系与可量化属性

大多数 NFT 是孤岛：合约里只有“谁持有哪枚”，一枚代币与其他代币的关系——我是那枚原作的衍生模型、我的强度值按原作比例计算——全靠项目方自定字段或干脆写在网页上。ERC-7085 想把这类关系标准化：在 ERC-721 与 ERC-1155 之上加五个函数，两写三读，登记“谁派生自谁”并给关系和代币挂可查询的数值。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准状态为 Draft，2023 年 5 月 2 日创建。

五个函数的分工

写入端两个。setRelationship 接收原作编号、衍生编号和一个关系属性值（不填默认 1），调用成功即宣告“后者以前者的身份存在为前提”。setAttribute 给任意一枚代币按名字设一个 uint256 数值，比如给一张卡登记“战力 88”。读取端三个：getRelationship(originalID, derivativeID) 查两枚代币之间的关系值，返回 uint256；getAttribute 按代币编号与属性名取值，返回类型是 bytes32；getAttributeNames 列出一枚代币都挂了哪些属性名，返回 bytes32 数组。五个函数拼起来，索引器就能沿边遍历出一张图：谁是根、谁是叶、每条边带什么权重。

与“可引用”类标准差在哪

同样是登记 NFT 之间的关系，容易想到引用型思路——把关系写成链上有向图。差别在数据的挂载位置：引用型标准描述“谁指向谁”，而 ERC-7085 强调关系本身可以携带量化属性，且代币也能挂任意命名数值，属性值本身还能被 setAttribute 覆盖更新。一个直观的试用场景是二创登记：原作 A 铸造出衍生 B 时调用 setRelationship，把授权比例 0.8 记在关系上；之后项目方给 B 的活动积分加成，改 setAttribute 即可，不用重铸也不用改元数据文件。所有写入都会进事件日志，图的历史版本理论上可回放。

建图的代价，标准自己承认

规范文本在动机部分特意提醒两个副作用：复杂度与 Gas。登记一笔关系要写存储，属性越多、图越密，合约状态越大；批量建立成百上千条边时费用可观。对只想做“父集子集”的项目来说，链上属性仓库或嵌套代币可能是更便宜的路径——ERC-7085 的定位是“关系+数值”双登记，只用其中一半功能属于浪费存储。还有一点要注意：这个接口挂在 ERC-721 与 ERC-1155 之上，但没有规定 setRelationship 的权限模型，谁能连边完全由实现者决定，意味着“我的藏品被陌生合约登记了个衍生关系”在某类实现里是可能的，持有人应把这条查询也纳入例行体检。

怎么核实一张关系网

索引与解码的两个实操提醒

实操者最先撞上的是解码墙：setAttribute 用字符串属性名写入、getAttribute 却回吐 bytes32，属性名到键的映射逻辑（原文拼接、哈希、截断）各实现不一，动手前应把参考实现读一遍，或用一个已知写入做探针比对回读值，切勿凭想象把 bytes32 直接转数字。另一个提醒关于建图的入口成本：setRelationship 是无条件写动作，任何有权限的地址连一次边就多一块存储；对做“衍生图谱”看板的项目，把关系源做窄比做全更重要——与其把一切链上互动都记成边，不如只登记有法律与经济含义的那几种派生关系，否则图谱会被噪声淹没，Gas 也白花。判断一个 ERC-7085 项目是否认真，看三个信号：键值口径有没有公开文档、写入函数有没有权限闸门、事件监控是不是做进了运维。三者皆无而PPT里画满关系网的，基本可以归类为讲故事。

先看接口声明与合约是否声明支持 ERC-165 查询；再对重点代币调 getRelationship 与 getAttributeNames，把返回的 bytes32 按实现说明解码（返回类型与写入类型 uint256 的转换口径要在源码里确认）；最后沿 Transfer 与标准事件的时间线核对关系是否与资产流转一致。凡是关系数据被用来发放奖励或计算版税的项目，都值得追问一句：这些数值谁能改、改过几次、事件在哪。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。